Egymásba ágyazott ismétlődések kezelése TShark field print opciókkal

Tegyük fel, hogy szkriptet kell írnunk, ami valamiféle statisztikát készít mondjuk IPIP vagy GRE tunnelezett forgalomról. Mintának egyből használhatjuk a packetlife.net-ről a GRE.cap-ot. A tunnel ebben az esetben a 10.0.0.1 és a 10.0.0.2 közt van kihúzva, a tunnelen belül pedig az 1.1.1.1 és a 2.2.2.2 kommunikál egymással:

Ha mindezt CLI-ben szeretnénk feldolgozni, akkor persze TSharkra lesz szükség, és egy kicsit állítgatni kell az alapértelmezett outputon. Egyszerűsítsük le a végletekig a dolgot, csak a forrás, illetve a cél IP-ket jelenítsük meg:

karsair@betazed:~$ tshark -r GRE.cap -T fields -e ip.src -e ip.dst -E separator=\;
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1

Nos, ez nem egészen az, amire szükség van, hiszen itt csak a GRE payload IP-k látszanak, azaz az ip.src és az ip.dst mezők utolsó előfordulásai minden egyes keretben. Ettől többet sajnos nem is várhatunk egészen a Wireshark 1.6-os verziójáig. Az új stabil Wireshark ágban azonban már gondoltak a rekurzivitás barátaira, új opciók vannak ugyanis a hasonló esetek kezelésére. Egyrészt megváltozott az alapértelmezett viselkedés a TShark-ban, -e után megadott mező összes előfordulását kilistázza a program vesszővel elválasztva:

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\;
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1

Másrészt vadonatúj field print opcióként itt az "occurrence". Az eddigi field print opciókkal be lehetett állítani, hogy legyen-e az outputban fejléc (-E header=y), a fenti példákban már bemutatott separator opcióval megadhattunk mezőelválasztó karaktert (-E separator=\;), illetve kérhettünk idézőjeleket a mező tartalma köré (pl. -E quote=d). Most viszont azt is megadhatjuk az occurrence opcióval, hogy az adott nevű mező első (f), utolsó (l) vagy összes (a) előfordulását szeretnénk látni, így akár imitálhatjuk az 1.6-os verziók előtti viselkedést (-E occurrence=l):

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\; -E header=y -E quote=d -E occurrence=l
ip.src;ip.dst
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"

Ami még ide tartozik, mégis kimaradt az eddigi példákból, az az aggregator field print opció, ami az -e után megadott nevű mező(k)nek az adott keretben való előfordulásait elválasztó karaktert definiálja, az alábbi példában ez a kettőspont:

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\; -E quote=d -E occurrence=a -E aggregator=:
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"

Eljutottunk tehát odáig, hogy a TShark egy jól konfigurálható kimentet ad a poszt elején vázolt szkript számára, az IP-ket pakolgathatjuk tömbökbe, ide-oda, számolgathatjuk, hogy melyik hányszor fordult elő ilyen külső IP, amolyan belső IP mellett, de az már egy másik történet.

NAT connection tracking naplózás Linuxon

Gyakran felmerülő probléma, hogy miképp lehet azonosítani linuxos SRC NAT mögötti gépeket megbízhatóan. Az ugye viszonylag egyértelmű, hogy címfordítást végző rendszeren valamit kezdenünk kell a kernel által vezetett conntrack táblával, amihez van egy sztenderd interfész minden Linuxon: a /proc/net/ip_conntrack-ből mindig ki lehet olvasni az éppen aktuális bejegyzéseket. Ez azonban igencsak behatárolt lehetőség. Tegyük fel, hogy percenként mentjük a táblázatot! Még így is igen könnyen lehetnek olyan NAT-olt kapcsolatok, amelyek az előző lekérdezés óta épültek ki, de azóta már kikerültek a conntrack táblázatból, ezért a percenkénti logjainkban semmilyen nyomuk nem marad, arról nem is beszélve, hogy rengeteg felesleges információt is eltárolunk, mert a conntrack bejegyzések jelentős része - a megnyitott, kiépített TCP sessionök - tipikusan több percen át élnek, és ezeket mindig újra és újra tárolgatjuk a percenkénti logokban.

Jobb lenne az eseményalapú megközelítés, csak akkor naplózni a conntrack bejegyzéseket, ha új kapcsolat épül ki, vagy ha az adott conntrack bejegyzés kikerül a conntrack táblázatból. Szerencsére ilyesmi létezik Linuxra, a szoftvercsomag neve conntrack-tools, a benne lévő eszközök pedig kiváló, dinamikus, userspace interfészt biztosítanak a kernel conntrack táblájához. A csomag két fontos eleme a conntrack és a conntrackd nevű program. Az előbbivel listázni, naplózni, létrehozni, módosítani, törölni lehet conntrack bejegyzéseket, az utóbbi (a démon) pedig redundáns NAT rendszerek közt képes a conntrack információk szinkronizálására. A conntrack naplózás tesztjéhez az alábbi topológiát használtam:

A "denobula" beállításait nem vittem túlzásba, egy teljesen alap Ubuntu 10.04 LTS telepítést kell elképzelni, ahol két paranccsal beállítható a 10.1.1.0/24 subnetből érkező csomagok forráscímeinek NAT-olása az eth0-ra aggatott külső IP-re, feltételezve, hogy az alapértelmezett ACCEPT iptables policy-ket senki és semmi nem állította át:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.1.0/24 -j MASQUERADE

Az interfészeket kell még beállítani, az /etc/network/interfaces fájlba kerüljenek a következők:

auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
address 10.0.2.15
netmask 255.255.255.0
gateway 10.0.2.2

iface eth1 inet static
address 10.1.1.1
netmask 255.255.255.0

Majd állítsuk be a DNS-t, végül húzzuk fel az interfészeket (újraindítás után ez már az init alatt megtörténik az előbbi auto bejegyzés miatt):

echo "nameserver 8.8.8.8" > /etc/resolv.conf
ifup eth0
ifup eth1

Következik a lényeg, a conntrack-tools telepítése (valójában csak a conntrack csomag szükséges ahhoz, amiről ebben a posztban szó lesz):

apt-get update
apt-get install conntrack conntrackd

A "denobula" beállítása ezzel meg is van, a tesztkörnyezetből még hiányzik a NAT mögötti kliens, az "andoria", ez bármi lehet, Live CD-s Linux, akármi, a lényeg, hogy konfiguráljunk rajta egy 10.1.1.2/24-es IP-t, majd a 10.1.1.1-et gatewaynek, valamint egy DNS szervert (pl. 8.8.8.8). Ezek után nincs más hátra, mint beröffenteni a NAT-os gépen a connttrack programot, a sok opció közül most a -E lesz az, amire szükségünk lesz, további opcióként megadtam a -o id,timestamp-et, így az egyes bejegyzések pontos időbélyege és az adott NAT-olt kacsolat belső ID-je is látszani fog a kimenetben:

root@denobula:~# conntrack -E -o id,timestamp,extended
[1331710267.511683]        [NEW] ipv4     2 tcp      6 120 SYN_SENT src=10.1.1.2 dst=74.125.232.247 sport=39059 dport=80 [UNREPLIED] src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39059 id=3607679456
[1331710267.513939]        [NEW] ipv4     2 tcp      6 120 SYN_SENT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 [UNREPLIED] src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 id=3607679216
[1331710267.513992]     [UPDATE] ipv4     2 tcp      6 60 SYN_RECV src=10.1.1.2 dst=74.125.232.247 sport=39059 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39059 id=3607679456
[1331710267.514021]     [UPDATE] ipv4     2 tcp      6 60 SYN_RECV src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 id=3607679216
[1331710267.514047]     [UPDATE] ipv4     2 tcp      6 432000 ESTABLISHED src=10.1.1.2 dst=74.125.232.247 sport=39059 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39059 [ASSURED] id=3607679456
[1331710267.514076]     [UPDATE] ipv4     2 tcp      6 432000 ESTABLISHED src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.506759]     [UPDATE] ipv4     2 tcp      6 120 FIN_WAIT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.507065]     [UPDATE] ipv4     2 tcp      6 60 CLOSE_WAIT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.507135]     [UPDATE] ipv4     2 tcp      6 30 LAST_ACK src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216
[1331710272.507208]     [UPDATE] ipv4     2 tcp      6 120 TIME_WAIT src=10.1.1.2 dst=74.125.232.247 sport=39060 dport=80 src=74.125.232.247 dst=10.0.2.15 sport=80 dport=39060 [ASSURED] id=3607679216

A kimenetben megtalálhatók a kért paraméterek, az első mező a timestamp, az utolsó mező a conntrack ID, a sorok egyébként elég beszédesek, minden sorban a második mező a conntrack esemény, amiből összesen három létezik, a NEW értelemszerűen egy új conntrack bejegyzés létrejöttekor generálódik, az UPDATE egy már létező bejegyzésben valamiféle változást jelez, például az UPDATE bejegyzésekben a TCP állapotátmenet-változások kiválóan követhetők. A harmadik, DESTROY nevű esemény pedig azt jelzi (a fenti példában épp nincs ilyen), hogy egy bejegyzés kikerül a conntrack táblából.

Ez a fajta eseményvezérelt kimenet már egészen közel van ahhoz, hogy használható legyen, két apróságra térnék még ki. Az első, hogy az STDOUT-ra küldött log nem tekinthető valódi log-nak, valahova át kell irányítanunk, a következő példában a tee-t használom, amivel így, ahogy van, ott lehet hagyni egy ötös vagy hatos szöveges terminálon, úgysem nyúl hozzá soha senki ;). A másik dolog, hogy általában az UPDATE eseményekre nincs szükség, hiszen az ilyesfajta logoknak az a lényege, hogy ki lehessen hámozni belőlük, hogy egy SRC NAT mögötti gép mettől meddig, milyen külső IP-vel, hová kommunikált, ehhez pedig elég a bejegyzés létrejöttét (NEW) és a bejegyzés végét (DESTROY) naplózni, ami közben történt a bejegyzéssel, nem érdekes. A "végső" NAT naplózó parancs tehát, amit természetesen ezer módon tovább lehet még fejlesztgetni, így néz ki:

conntrack -E -o id,timestamp,extended -e NEW,DESTROY | tee /var/log/ctrack.log

Alapvető biztonsági beállítások MikroTiken

Néhány poszttal ezelőtt volt szó a Mikrotik eszközök ISR routerként történő használatáról, akkor egy-két teljesen szokványos lehetőséget (SNAT, DNAT, DHCP kliens WAN oldalon, DHCP szerver LAN oldalon, NTP kliens, WPA2 PSK wifi) vettünk elő CLI-ben, viszont tárva-nyitva hagytuk a rendszert, így valószínűleg nem élne túl a konfigurációnk pár napnál hosszabb időt érintetlenül publikus interneten. A biztonságosabb működés érdekében a legelső lépés az alapértelmezett admin jelszó megváltoztatása:

[admin@Tik] > /password
old password: password
new password: *************
retype new password: *************

Ez már önmagában sokat jelent, itt azonban semmiképp se pihenjünk még le, következhet a nem használt szolgáltatások kikapcsolása. Amire ténylegesen is szükség lehet, az az SSH, a többit bátran le lehet tiltani:

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set www-ssl disabled=yes
set api disabled=yes
set winbox disabled=yes

Akár le is ellenőrizhetjük, hogy mindent sikerült-e kikapcsolni:

[admin@Tik] > /ip service print Flags: X - disabled, I - invalid 
#   NAME        PORT ADDRESS            CERTIFICATE                                     
0 X telnet                23
1 X ftp                   21
2 X www                   80
3   ssh                   22
4 X www-ssl              443                   none
5 X api                 8728
6 X winbox              8291

A RouterOS-en alapértelmezésben figyel UDP-n a bandwidth-server. Ez az IPerf-hez hasonló eszköz, amivel sávszélesség teszteket végezhetünk, érdemes ezt is addig pihentetni, amíg nincs rá ténylegesen szükség. A bandwidth-server szolgáltatás beállítása nem az IP service-ek közt található:

/tool bandwidth-server
set enabled=no

Végül tanácsos legalább a WAN és a WLAN interfészen letiltani a MikroTik Neighbor Discovery protocolt (MNDP) és a CDP-t, hogy ne szivárogtassunk feleslegesen információkat a rendszerről:

/ip neighbor discovery
set wlan1 disabled=yes
set ether1 disabled=yes

Ezzel az alapvető biztonsági beállításokon túl is vagyunk, a környezettől függően természetesen sok egyéb lehetőségünk van még a RouterOS alatt: tűzfalszabályok beállítása, központi RADIUS authentikáció, SNMPv3, BGP MD5 authentikáció, stb. ebben a posztban csupán a legáltalánosabb lehetőségeket vettük sorra.

VLAN-ok kezelése MikroTiken

Vannak bizonyos megoldások a MikroTik RouterOS-en, amelyek, hát... legalábbis furcsának tűnnek egyéb network OS-ekhez képest, az egyik ilyen a VLAN-ok kezelése. Nem létezik olyasmi RouterOS alatt, hogy access port vagy trunk port, az van, amit összedrótozgatunk. Az alábbi parancsok például VLAN 1-3-ig, tagged VLAN kezelést biztosítanak az ether1 interfészen:

/interface vlan
add name="VLAN1" vlan-id=1 interface=ether1 disabled=no
add name="VLAN2" vlan-id=2 interface=ether1 disabled=no
add name="VLAN3" vlan-id=3 interface=ether1 disabled=no

Persze ezzel önmagában sokra nem megyünk, hiszen valahová tovább is kell kapcsolni ezeket a VLAN-okat, mondjuk access portokra. A következő döbbenet akkor éri a kezdő mikrotikest (például engem is), amikor kiderül, hogy amit mindenhol máshol access portnak hívnak, az itt tulajdonképpen nincs, de amit tehetünk, hogy mégis legyen, az sem az, hogy VLAN-okba tesszük a portokat, hanem:

/interface bridge
add name="BR1" disabled=no
add name="BR2" disabled=no
add name="BR3" disabled=no
/interface bridge port
add bridge=BR1 interface=ether2 disabled=no
add bridge=BR1 interface=ether3 disabled=no
add bridge=BR2 interface=ether4 disabled=no
add bridge=BR2 interface=ether5 disabled=no
add bridge=BR3 interface=ether6 disabled=no
add bridge=BR3 interface=ether7 disabled=no

Amint az a példából látható, a BR1 nevű bridge-hez az ether2-3, illetve a wlan1 port tartozik, a BR2-höz a ether4-5, a BR3-hoz pedig az ether6-7. Az itt definiált portcsoportok különálló VLAN-okként viselkednek, de természetesen az égvilágon semmi közük nincs az ether1 interfészen létrehozott trönkhöz, és az azon élő három tagged VLAN-hoz (némiképp emlékeztet egyébként mindez az autonóm Cisco AP-ken használatos BVI bridge group interfészekre). Az uplinken bejövő tagged VLAN-ok és a BR1, BR2, BR3 bridge-ek között úgy hozhatunk létre kapcsolatot, hogy a VLAN neveinkhez tartozó virtuális interfészeket szintén bepakoljuk a bridge-ekbe:

/interface bridge port
add bridge=BR1 interface=VLAN1  disabled=no
add bridge=BR2 interface=VLAN2  disabled=no
add bridge=BR3 interface=VLAN3  disabled=no

Ezzel eljutottunk oda, hogy az ether1-en bejövő tagged adatok megtalálják az útjukat az adott VLAN-on belül a MikroTik eszközre kapcsolt hostokig. De itt még nincs vége, ez csak az a módszer, ami minden MikroTik-en működik, egyes RouterBOARD-oknál ettől eltérő megoldást is lehet használni, attól függően, hogy milyen switch chip található a NYÁK-on. A RouterOS ugyanis nem fedi el a hardveres lehetőségeket, vannak hardverspecifikus parancsok a VLAN-ok kezelésére. A wiki.mikrotik.com-on található egy táblázat, ebből ki kell keresni, hogy a MikroTik eszközünkben milyen switch chip található, hogy támogatja-e a chip a port tükrözést, mekkora CAM táblát tud kezelni (MikroTik esetén ezt host table-nek hívják), vagy éppen azt, hogy hány VLAN-nal képes megbirkózni, és utána készíthetünk az adott switch chipre szabott VLAN konfigurációt, ami más RouterBOARD-on működésképtelen lehet. Beteges, nem igaz?

Link Layer Discovery protokollok használata (5.) - CDP MikroTiken és Vyattán

Tulajdonképpen egész könnyen meg lehet szokni a MikroTik szoftverplatformját, a RouterOS-t, valójában igazi MikroTik eszköz sem kell ahhoz, hogy kipróbálhassuk, ugyanis van belőle x86-osra fordított változat, így akár virtuális gépre is telepíthető. A legfrissebb, 5.12-es kiadás IPSec-kel, MPLS-sel, NetFlow v9 exporttal, SNMP v3-mal és még számtalan lehetőséggel együtt sem több ~20MB-nál, ami bizony igen kevés, bármilyen mércével mérve, így aztán ideális választásnak tűnik nagyobb virtuális infrastruktúrák hálózati igényeinek kielégítésére.

De nem is erről szólna ez a poszt, hanem a MikroTik és a Vyatta CDP-kompatibilitásáról. A jó hír az, hogy mindkettőn működik, valódi Cisco eszközökkel tesztelve is, szerintem a Mikrotik megoldása a jobb, ugyanis a RouterOS alatt nagyon egyértelműen lehet kezelni a CDP-be bevont interfészeket, míg a Vyattán csak globálisan lehet ki- és bekapcsolni a CDP támogatást, bár állítólag dolgoznak az interfészenkénti ki- és bekapcsoláson. Ugyanakkor a Vyatta ismeri a CDP v2-t is, míg a RouterOS kizárólag CDP v1-et tud. A parancsok részletes leírogatása helyett ezúttal néhány beszédes képernyőképet készítettem, a képekre kattintva nagyobb felbontású változat is elérhető.

A Cisco eszköz látja mindkét CDP-s versenyzőt, a platform információk, a szoftververzió, a kapcsolódó fizikai portok teljesen korrekt módon jelennek meg az IOS-ben:

A MikroTik-es virtuális gép szintén hibátlanul teszi a dolgát, a gyártónál alapértelmezésben minden interfészen aktív a CDP, kivéve a vezeték-nélküli interfészeket, és mintha tunnel interfészeken sem kapcsolná be alapból a CDP-t a RouterOS; a lényeg, hogy vegyük a CDP-t is számításba (elsősorban biztonsági szempontból), amikor MikroTiket teszünk be a hálózatba. A képernyőképen a szomszédok listázása után példa látható arra is, hogyan kapcsolható ki egy adott interfészen a CDP, illetve arra, hogyan listázható az interfészek aktuális CDP-s állapota.

A CDP alapból nem fut a Vyattán, külön be kell kapcsolni (configure > set service lldp legacy-protocols cdp > commit > save). Az IOS CDP kereteitől a rendszer egy kissé megilletődött, kétszer is betette a neighbor táblázatba a Cisco AP-t, egyszer CDP v1-es, egyszer pedig CDP v2-es eszközként, ezt a kis botlást, valamint a többihez képest rendkívüli szószátyárságot leszámítva azonban nagyjából itt is minden rendben van:

Ugyanebben a témában a korábbi írásaim a Nortel, a 3Com (új HP) majd a HP (ProCurve, régi HP) Layer 2-es discovery protokolljainak alapvető használatát mutatták be, illetve az IOS-es LLDP-t.

MikroTik wifi rulez: spektrum analízis CLI-ben

Minden WiFi eszközben helye lenne egy olyan tesztlehetőségnek, mint amilyet a MikroTik RouterOS-ben találtam. A szomorú valóság ezzel szemben az, hogy ilyesmi az Aruba cuccokon van, meg valami hasonló a Cisco AP-ken, de a legtöbb gyártó nem büszkélkedhet azzal, hogy a szabad felhasználású 2,4 Ghz-es illetve 5GHz-es tartományban spektrum analízist biztosítana.

Hogy mire jó ez? WiFi hibakeresésnél kiválóan használható az ugyanezekben a frekvenciatartományokban jelen lévő bármilyen fizikai jel kimutatására, aminek az egyéb WiFi eszközökön kívül lehet a forrása mikohullámú sütő, DECT telefon, autós riasztórendszer, rádiós kamerarendszer stb.

A MikroTik eszközökben - már amelyik támogatja ezt a lehetőséget, a RouterBoard 493-as történetesen ilyen - roppant egyszerű ennek a használata: interface wireless spectral-history wlan1:

Az itt látható rádiós környezetben például kiválóan megfigyelhető, hogy a 2437 MHz-es center frekvenciájú 6-os WiFi csatornára (2427-2447 MHz) nem érdemes jelet kitenni, sokkal jobbak a fizikai jel interferencia nélküli túlélésének esélyei az 1-es vagy a 11-es csatornán, igazán jól pedig a 13-as, vagy ha támogatják eszözeink, akkor 14-es csatornán érezné magát.

ISR router funkciók MikroTiken

Tesztelésre nálam van egy MikroTik eszköz (RouterBoard 493-as), 5.11-es RouterOS-szel, 9 darab tetszés szerint konfigurálható (Layer 2 / Layer 3) Ethernet interfésszel és egy WiFi interfésszel. Soha nem használtam még MikroTiket meg RouterOS-t korábban, egy picit irigykedve olvasgattam mások tapasztalatairól fórumokon, erre-arra, hogy ez linuxos cucc, mennyire megbízható, olcsóbb, mint a Cisco, ezt is tudja, azt is tudja.

Azért be kell vallanom, nem volt túl rózsás a kezdet, ugye a webes GUI meg a WinBox nevű windowsos konfiguráló csodák eleve nem is nagyon izgattak, hiszen ha használni fogunk MikroTiket, akkor az olyan környezetben lesz, ahol csak CLI jöhet szóba, és a CLI-t azt bizony szokni kell mondjuk egy IOS vagy bármi hasonló után. A hivatalos CLI dokumentáció sincs túl bő lére eresztve, úgyhogy MikroTik vonalon  sokat segít, ha az ember konzolkábelt ragad, és megpróbál mindenféle konfigurációkat összerakosgatni. Meglehet, hogy lesz még néhány hasonló poszt.

Elsőre arra gondoltam, hogy egy viszonylag általános ISR (Integrated Services Router) konfigurációt dobok össze: bridge a LAN portokon, SRC NAT, esetleg egy DNAT, WiFi (WPA2-PSK), WAN oldalon DHCP kliens, LAN oldalon DHCP szerver, NTP kliens... De még mielőtt belekezdenénk: a soros konzolport sebességét toljuk fel a terminálkliensünkön a sztenderd 9600-ról 115200-ra, ennél a típusnál ugyanis ez az alapértelmezés (gyors- és gépírók előnyben :)). A első dolog, amit érdemes beállítani, az a hostnév, itt persze véletlenül sem hostnévnek hívják:

/system identity
set name=TESZTROUTER

Jöhet a bridge interfész létrehozása. Fontos tudni, hogy ezen a boardon switch chip is van, így nem szoftverből történik a kapcsolás, hanem ASIC alapon megy, ami mindenképp dicséretes. A portok tetszőleges csoportját össze lehet bridge-elni, ebben a konfigurációban az ether1 porton kívül minden egyéb port a LAN oldali bridge groupban lesz:

/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 disabled=no interface=ether2
add bridge=bridge1 disabled=no interface=ether3
add bridge=bridge1 disabled=no interface=ether4
add bridge=bridge1 disabled=no interface=ether5
add bridge=bridge1 disabled=no interface=ether6
add bridge=bridge1 disabled=no interface=ether7
add bridge=bridge1 disabled=no interface=ether8
add bridge=bridge1 disabled=no interface=ether9
add bridge=bridge1 disabled=no interface=wlan1

Adjunk a WAN és LAN oldali interfészeinknek címet, a WAN port az ether1 lesz, a LAN oldalon pedig a bridge1 interfész fogja kiszolgálni a klienseket:

/ip dhcp-client
add default-route-distance=1 disabled=no interface=ether1
/ip address
add address=10.100.202.1/24 disabled=no interface=bridge1

A következő lépés a DHCP szerver beállítása LAN oldalon. Ehhez létre kell hozni egy IP poolt, azt hozzárendelni egy DHCP szerverhez (TEST_DHCP_SRV), illetve egy interfészhez (bridge1). Csak alapinformációkat adunk át a klienseknek, a default gw és egy Google DNS IP minden, amit az IP címen kívül megkapnak egy félórára. Egy pici csavart azért vittem bele, hogy megnézzem a static (v. reserved) DHCP funkciót is, a 00:0C:42:B5:8C:48-as MAC című kliensünk mindig a 10.100.202.200-as IP címet fogja megkapni:

/ip pool
add name=TEST_DHCP_POOL ranges=10.100.202.200-10.100.202.254
/ip dhcp-server
add name=TEST_DHCP_SRV address-pool=TEST_DHCP_POOL disabled=no interface=bridge1 lease-time=30m
/ip dhcp-server network
add address=10.100.202.0/24 dns-server=8.8.8.8 gateway=10.100.202.1
/ip dhcp-server lease
add address=10.100.202.200 disabled=no mac-address=00:0C:42:B5:8C:48


Következzék a NAT beállítása: egyrészt szeretnénk a 10.100.202.0/24-ben lévő LAN oldali klienseket betenni SRC NAT mögé, másrészt a WAN IP-re érkező TCP 2323 kapcsolatokat DNAT-tal áttesszük az imént static DHCP-re állított LAN oldali host 23-as TCP portjára. Itt mind a SRC, mind a DST NAT esetében olyan parancsváltozatokat használtam, amelyekkel el lehet kerülni a külső IP-re való hivatkozást (mivel ebben a konfigurációban dinamikus a WAN IP-cím), de természetesen a RouterOS kelléktárában vannak ennél komolyabb NAT szabályokat is lehetővé tevő eszközök:

/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1
add action=dst-nat chain=dstnat disabled=no protocol=tcp dst-port=2323 to-port=23 to-addresses=10.100.202.200

Érdemes szinkronizálni a rendszer óráját valami közeli NTP szerverrel:

/system clock
set time-zone-name=Europe/Budapest
/system ntp client
set enabled=yes mode=unicast primary-ntp=148.6.0.1

Végül következhet a WiFi beállítása. Először egy biztonsági profilt kell létrehoznunk, amit utána rá lehet aggatni az SSID-nkre. A "TEST_PROFILE_WIFI" profil WPA2-PSK authentikációt használ és AES titkosítást, a profilt használó "TEST_MIKROTIK" SSID-t 802.11b, g és n szabványt ismerő klienseknek szórjuk az 1-es csatornán (2412 MHz):

/interface wireless security-profiles
add name=TEST_PROFILE_WIFI authentication-types=wpa2-psk group-ciphers=aes-ccm group-key-update=5m mode=dynamic-keys wpa2-pre-shared-key=12345678
/interface wireless
enable wlan1
set name=wlan1 mode=ap-bridge band=2ghz-b/g/n bridge-mode=enabled frequency=2412 hide-ssid=no security-profile=TEST_PROFILE_WIFI ssid=TEST_MIKROTIK

Ebben a formában a konfigurációnk még nem igazán internetképes, mindenféle biztonsági problémák lehetnek vele, alapból például fut a RouterOS-en a telnet szolgáltatás, tűzfalat is kellene konfigurálni, jelszót beállítani az admin usernek stb. de kezdetnek megteszi, a többit talán majd egy másik alkalommal.

Interfész információk Vyattán

Elképzelni is nehéz, mit össze nem keresgéltem a múltkor, hogy miképp lehet Vyatta alatt megnézni egy Ethernet interfészen a hozzá tartozó speed és duplex beállításokat. A legtöbb network OS alatt ugye ez eléggé egyértelmű, egy sima show interface vagy mondjuk 3Com/HP/Huawei vonalon egy display interface parancs kiírja, hogy 10, 100 vagy 1000 M, full vagy half duplex, auto, nem auto. A Vyatta OS azonban nem követi ezt a konvenciót, úgyhogy eddig, ha szükségem volt ilyen jellegű információra, mindig "kiléptem" a Vyatta shellből sudo -i-vel és vagy a mii-tool vagy az ethtool parancsot használtam:

root@Vyatta:~# mii-tool eth1
eth1: negotiated 1000baseT-FD flow-control, link ok


root@Vyatta:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes


Szép, szép, de ezek mégiscsak linuxos parancsok, tulajdonképpen mindig is bosszantott, hogy miért nem lehet ezt a sima Vyatta shellben megnézni. Aztán persze tök véletlenül kiderült, hogy a user a béna, természetesen  benne van ez a Vyatta shellben is, csak nem egészen ott kerestem eddig, ahol kellett volna; az ethtool kimenetét adja a a következő parancs:


admin@Vyatta:~$ show interfaces ethernet eth1 physical
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes
driver: tg3
version: 3.115
firmware-version: 5703-v2.22
bus-info: 0000:02:02.0

DNAT szabályok tűzfalazása Vyatta alatt

Rég nem volt már teljes egészében Vyattának szentelt írás az oldalon, a napokban épp szóba is került a rendszernek egy érdekesebb tulajdonsága a munkahelyemen, így most semmi sem tarthat vissza attól, hogy mindazt, amiről ott szó volt, közzé ne tegyem. Alapvetően egyszerű dologról van szó, a Vyatta port forwarding vagy DNAT lehetőségéről, ami kombinálva némi szűréssel, könnyen káromkodásba fordulhat (megjegyzem, minden Linux rendszeren ugyanezen szisztéma szerint működik a DNAT). Mi is ez az egész pontosan? Íme a Vyatta dokumentációból kiollózott ábra, mely az egyes NAT alrendszerek, a routing folyamat és a tűzfalazás viszonyát szemlélteti:

Az ábrán a témánk szempontjából két fontos dolgot láthatunk, az egyik az, hogy a DNAT (destination NAT, avagy port forwarding, esetleg szolgáltatás publikálás) minden egyéb feldolgozási folyamat, routeolás, szűrés előtt történik meg egy beérkező csomagon. Ezzel szemben az SNAT (source NAT) a legutolsó lépés, ami csak a routeolás és a tűzfalazás után történik. A szűrés szempontjából az SNAT sima ügy, bejön a klienstől a csomag mondjuk a 192.168.0.100-as forrás IP-vel, a célcím nem a Vyatta rendszer (Dest=local? No), a tűzfal szépen átkergeti az IN, majd az OUT irányú szabályokon, végül az SNAT dobozkában leszerelik róla a 192.168.0.100-as feladói címet és ráhegesztik mondjuk feladóként az 1.2.3.4 publikus címet, illetve ezt fel is jegyzik egy táblázatba, hogy a visszatérő forgalmat le lehessen kezelni és eljusson az eredeti feladóhoz.

A DNAT egy kicsit más, arról van ugye szó, hogy az 1.2.3.4-re irányuló, pl. TCP 80-as forgalmat valójában nem a Vyatta webszervere emésztgeti, hanem a mögötte lévő NAT-olt hálóban mondjuk a 192.168.0.101-es host. Bemegy a DNAT dobozba a 1.2.3.4:80-ra küldött üzenet, odabent átalakul, és ami kijön, annak már 192.168.0.101:80 lesz a célja. Persze a dobozban ezt a csereberét megintcsak jól feljegyzik. Ezek után a routing megmondja, hogy ez a 192.168.0.101 a Vyatta LAN oldalán található cím (Dest=local? No), átmegy az IN, majd az OUT szűrőn, és kimegy a LAN-ba.

Mindez azért érdekes, mert az ember - főképp, ha vállalati tűzfalak GUI-jához szokott - a tűzfalszabályok írásakor alapból nincs NAT üzemmódban, és egy ilyen DNAT-olt 80-as portot simán úgy vesz fel a Vyatta tűzfalszabályokban, hogy a külső IP címmel számol, az 1.2.3.4:80-ra engedi be a népeket, pedig mire a tűzfalhoz eljut az 1.2.3.4:80-as csomag, addigra az már keresztülverekedte magát a DNAT-on, és 192.168.0.101:80 van benne.

Következzék egy konkrét konfig példa, ami kívülről elérhetővé teszi az 1.2.3.4:22-es és 1.2.3.4:80-as TCP portokat, a különbség annyi, hogy az SSH a Vyattán fut, a HTTP viszont NAT mögött, másik hoston. A Vyatta külső interfészének (eth0) bejövő szűrőjében mégis egy privát, belső IP cím szerepel:

firewall {
    name INET_to_INTERNAL {
        default-action drop
        rule 100 {
            action accept
            description "Allowing HTTP traffic to internal host 101"
            destination {
                address 192.168.0.101
                port 80
            }
            protocol tcp
        }
    }
    name INET_to_LOCAL {
        default-action drop
        rule 100 {
            action accept
            protocol icmp
        }
        rule 200 {
            action accept
            description "SSH access on port 22"
            destination {
                address 1.2.3.4
                port 22
            }
            protocol tcp
        }
    }
}
interfaces {
    ethernet eth0 {
        address 1.2.3.4/24
        firewall {
            in {
                name INET_to_INTERNAL
            }
            local {
                name INET_to_LOCAL
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.1/24
    }
    loopback lo {
    }
}
protocols {
    static {
        route 0.0.0.0/0 {
            next-hop 1.2.3.1 {
            }
        }
    }
}
service {
    nat {
        rule 100 {
            description "DNAT for HTTP on 192.168.0.101"
            destination {
                address 1.2.3.4
                port 80
            }
            inbound-interface eth0
            inside-address {
                address 192.168.0.101
            }
            protocol tcp
            type destination
        }
        rule 200 {
            description "SNAT for internal subnet"
            outbound-interface eth0
            outside-address {
                address 1.2.3.4
            }
            source {
                address 192.168.0.0/24
            }
            type source
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
}

Link Layer Discovery protokollok használata (4.) - LLDP Cisco IOS-en

A korábbiakban a Nortel, a 3Com (új HP) majd a HP (ProCurve, régi HP) layer2-es discovery protokolljainak alapvető használatát vizsgáltuk. A HP-s posztban a korábbi gyártóspecifikus protokollok után előkerült az LLDP, az egyéb hasonló protokollokat felváltó nemzetközi szabvány. A mai poszt egy többgyártós rém egyszerű kis teszthálózatban mutatja meg az LLDP fontosabb képességeit Cisco oldalról. Nem fogunk túlságosan belemászni az LLDP konfigurációjába, így az olyan lehetőségeket, mint hogy a szomszédokról begyűjtött információt mennyi ideig tárolja a hostunk (LLDP holdtime), vagy éppen azt, hogy milyen időközönként szórjuk meg a szomszédos eszközöket LLDP PDU-kkal (LLDP update frequency), vagy hogy egyáltalán milyen TLV (Type-Lenght-Value) rekordokkal foglalkozzon az LLDP-s eszközünk, most átugorjuk, az alapértelmezésekre hagyatkozunk, ami egyébként az esetek túlnyomó részében tökéletesen elegendő is.

Cisco eszközökön az LLDP nagyjából a CDP-hez hasonlóan kezelhető, sőt egyszerre mindkettő futhat, az más kérdés, hogy van-e ilyesminek értelme, evidens, hogy amennyiben lehetséges, nem érdemes keverni a kettőt, vegyes környezetben várhatóan az LLDP lesz a favorit, homogén Cisco környezetben pedig a CDP.

A LLDP-vel kapcsolatos fontosabb konfigurációs parancsok IOS-en: globális konfig módban a (no) lldp run ki- vagy bekapcsolja az LLDP-t, illetve interfész konfigurációs módban hasznos lehet a no lldp transmit, továbbá a no lldp receive, ezekkel interfészenként tilthatjuk az LLDP küldést és fogadást, amit mindig érdemes legalább a hálózatunk külső csatlakozási pontjain megtenni. Az LLDP-s információs parancsokat az alábbi példák mutatják be:

CiscoSW#show lldp

Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds

CiscoSW#show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
3Com-SW             Fa0/1          120        B,R             Ethernet5/0/14
HP-SW               Gi0/1          120        B               24
Vyatta1             Fa0/48         120        R               001e.3734.d09c

Total entries displayed: 3

CiscoSW#show lldp neighbors detail
------------------------------------------------
Chassis id: 001a.c156.1040
Port id: Ethernet5/0/14
Port Description: Ethernet5/0/14
System Name: 3Com-SW

System Description:
Switch 5500-EI

Time remaining: 91 seconds
System Capabilities: B,R
Enabled Capabilities: B,R
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseX(FD)
    1000baseX(HD)
    Symm Pause(FD)
    Asym Pause(FD)
    100base-T4
    10base-T(FD)
    10base-T(HD)
    Other/unknown
Media Attachment Unit type: 16
Vlan ID: 1

------------------------------------------------
Chassis id: 0016.b90b.e8a0
Port id: 24
Port Description: 24
System Name: HP-SW

System Description:
ProCurve J4903A Switch 2824, revision I.10.77, ROM I.08.07 (/sw/code/build/mako(mkfs))

Time remaining: 115 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses:
    IP: 172.17.136.247
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: - not advertised
         
------------------------------------------------
Chassis id: 001e.3734.d09c
Port id: 001e.3734.d09c
Port Description: eth0
System Name: Vyatta1

System Description:
Vyatta Router running on Vyatta Core 6.3 2011.07.21

Time remaining: 111 seconds
System Capabilities: B,W,R
Enabled Capabilities: R
Management Addresses:
    IP: 172.17.136.253
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseT(FD)
    100base-TX(FD)
    100base-TX(HD)
    10base-T(FD)
    10base-T(HD)
Media Attachment Unit type: 16
Vlan ID: - not advertised

MED Information:

    MED Codes:
          (NP) Network Policy, (LI) Location Identification
          (PS) Power Source Entity, (PD) Power Device
          (IN) Inventory

    H/W revision: ThinkCentre M57
    F/W revision: 2RKT41AUS
    S/W revision: 2.6.37-1-586-vyatta
    Serial number: LMBKVN2
    Manufacturer: LENOVO
    Model: 6089W25
    Asset id:
    Capabilities: LI, IN
    Device type: Network connectivity
    Network Policies - not advertised
    Power requirements - not advertised
    Location - not advertised

Total entries displayed: 3

Látható, hogy a Cisco eszközünknek három LLDP-s szomszédja van, egy 3Com 5500-EI, egy HP 2824, valamint egy Lenovo ThinkCentre M57 PC, amin Vyatta 6.3 fut. A figyelmesebbeknek az is feltűnhet, hogy mindegyik LLDP implementáció másféle TLV készlettel dolgozik, így nincsenek, nem is lehetnek egységesen kitöltve a megjelenő mezők a részletes nézetben.