IPSec site-to-site VPN Cisco routerekkel

Sok forrásból meríthetünk, ha Cisco IOS alatti site-to-site VPN példákat szeretnénk látni, az itt bemutatandó természetesen nem különbözik gyökeresen ezen példáktól, szóval különösebb újdonság jellege nem lesz a dolognak. Valójában csak egy referencia konfigurációt szeretnék bemutatni ebben a posztban, amire később bármikor tudok hivatkozni, és amit később majd olyan posztok fognak követni, amelyekben megváltozik ez vagy az a részlet.

Tegyük fel tehát, hogy két telephelyünk van, a telephelyek LAN-jai igen egyszerűek, egyetlen subnetből áll mindkettő. A két telephely összekötésére csak publikus hálózaton keresztül van módunk, a telephelyek közti belső forgalmat természetesen nem tárhatjuk fel az világ számára. Egyszerű site-to-site IPSec VPN-re van tehát szükség Cisco routerek közt, amelyhez az IPSec-es IOS-en kívül egy-egy publikus, fix IPv4 címre van szükség mindkét oldalon. Topológia:

A IPSec VPN beállítások összefoglalása:

	R1	R2
Phase 1
Encryption	AES256	AES256
Authentication	SHA1	SHA1
Diffie–Hellman Group	5	5
Lifetime	28800 sec	28800 sec
Phase 2
Encryption	AES128	AES128
Authentication	MD5	MD5
Diffie–Hellman Group	5	5
Lifetime	3600 sec	3600 sec
Peer IP	10.1.1.2	10.1.1.1
Authentication method	PSK (“TITOK”)	PSK (“TITOK”)
Local interface	FA0/0	FA0/0
Local subnet	10.2.2.0/24	10.3.3.0/24
Remote subnet	10.3.3.0/24	10.2.2.0/24
NAT-T	nincs	nincs
DPD	nincs	nincs
PFS	van	van
Compression	nincs	nincs

A következő IOS parancsokkal húzhatjuk fel az IPSec tunnelt R1-en:

interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no shutdown
exit

interface FastEthernet0/1
ip address 10.2.2.1 255.255.255.0
no shutdown
exit

ip route 10.3.3.0 255.255.255.0 10.1.1.2

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit

crypto isakmp key TITOK address 10.1.1.2

access-list 100 permit ip 10.100.31.0 0.0.0.255 10.100.30.0 0.0.0.255

crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
crypto ipsec security-association lifetime seconds 3600

crypto map TESZTMAP 50 ipsec-isakmp
set peer 10.1.1.2
set pfs group5
set transform-set TESZTSET
match address 100
exit

interface FastEthernet0/0
crypto map TESZTMAP
exit

A kékkel jelzett parancsok egybeesnek az IOS alapértelmezett értékeivel, így a show running-config nem fogja őket mutatni, be sem kell pötyögni, csak a teljesség kedvéért szerepelnek a parancsok közt. Az R1 konfigurációja természetesen ugyanezekkel a parancsokkal történik, az IP címeket és a subneteket éretelemszerűen fel kell cserélni, 10.1.1.1 helyett 10.1.1.2, 10.2.2.0 helyett 10.3.3.0 szerepel az R1-es parancsokban.

NMS host multi-VLAN környezetben

Sok VLAN-os környezetben, különösen ha nincs inter-VLAN routing, vagy ha nem minden VLAN között van layer3-ban kapcsolat, bármikor jól jöhet egy olyan, szigorúan diagnosztikára használt host, amelyik minden VLAN-ba be tud kukucskálni. A komolyabb, szerverekbe való hálózati kártyákon persze már hosszú évek óta ott a VLAN-ok támogatása a Windows Server OS-re, így elvileg Windowsból is készíthetünk ilyen network monitoring hostot, de Windows alatt elég nehézkes már 20 ilyen VLAN interfész kezelése is, különösen ha mondjuk csak 16-ot tud kezelni a windowsos driver. Aztán persze minden VLAN interfészhez külön gondoskodnunk kell a megfelelő route-okról, ügyelnünk kell arra, hogy egyik interfészen se vágja felül egy kósza DHCP-s beállítás a route-okat, és akkor még nem is említettük az átlátható tűzfalazást, szóval Linuxnak kell ennek lennie.

Mostanában Ubuntu/Debian vonalon mozgolódok leginkább, így a konfigurációs példa ilyen rendszerekhez lesz igazítva. Gondolom, azzal nagyjából mindannyian egyetértünk, hogy egy ilyen Linux rendszert kizárólag a legszükségesebb összetevőkkel, X és desktop környezet nélkül kell telepítenünk. Hardver szinten csak a hálókártyát emelném ki, egy megbízható, a VLAN taggelést is kezelni képes kártyára lesz szükségünk (pl. Intel szerver NIC-ek, de a PRO/Desktop sem rossz), a különféle USB-s meg Via, Realtek és hasonló rémségeket viszont felejtsük el, inkább bele se kezdjünk, igen alattomos hibákat tud okozni VLAN környezetben például ha 1500 bájtnál vágják az Ethernet keretet.

Ha sikerült felkonfigurálnunk egy trönk portot valamelyik switchen, akkor a konfiguráció már alapvetően csak az "/etc/network/interfaces" fájl módosítgatásából áll. Különösebb magyarázat helyett jöjjön egy példa, a célunk, hogy egy Linux segítségével az alábbi layer3-as topológia minden egyes VLAN-jába bejárásunk legyen:

A 2-es VLAN az első szervezeti egység publikus hálózata, a 3-as VLAN ugyanezen szervezeti egység belső hálózata, a 4-es VLAN a másik szervezeti egység publikus hálózata, az 5-ös ugyanezen egység belső hálózata, amelyre még közvetlenül becsatlakozik egy távoli telephely. A két szervezet belső hálózata közt nincs semmilyen összeköttetés (viszont ugyanazokon a fizikai switcheken osztoznak). Egy ilyen képzeletbeli topológiához az alábbi beállításokat használhatjuk az "/etc/network/interfaces" fájlban:

auto lo eth0.3
iface lo inet loopback
iface eth0 inet dhcp

# Szervezet1 public - VLAN2
iface eth0.2 inet static
hw-mac-address aa:aa:aa:aa:00:02
address 2.2.2.3
netmask 255.255.255.240
gateway 2.2.2.1

# Szervezet1 private - VLAN3
iface eth0.3 inet static
hw-mac-address aa:aa:aa:aa:00:03
address 10.3.3.2
netmask 255.255.255.0

# Szervezet2 public - VLAN4
iface eth0.4 inet static
hw-mac-address aa:aa:aa:aa:00:04
address 4.4.4.3
netmask 255.255.255.240
gateway 4.4.4.1

# Szervezet2 private - VLAN5
iface eth0.5 inet static
hw-mac-address aa:aa:aa:aa:00:05
address 10.5.5.3
netmask 255.255.255.0
up route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.5.5.2
down route del -net 10.10.10.0 netmask 255.255.255.0 gw 10.5.5.2

Mindenképp kiemelt figyelemmel kezeljük, hogy a Linuxon ne legyen engedélyezve az IP forwarding, azaz ne routeoljuk össze a különböző VLAN-okat (/etc/sysctl.conf). A példa első sorában látható, hogy az eth0 fizikai interfészen bootolás után csak az eth0.3 lesz fent, a natív/default VLAN (eth0) be van ugyan állítva DHCP-re, de inaktív, ahogy a többi tagged VLAN interfész is az. Tehát a belső hálózatok közül a VLAN3-ban tudunk feljelentkezni a multi-VLAN hostunkra. Az eth0.2 vagy az eth0.4 felhúzásakor (pl.: ifup eth0.2) beállítódik egy default route az internet felé, így hozzáférünk bármilyen internetes hosthoz a Linuxról direkben, NAT nélkül. Értelemszerűen egyszerre nem érdemes mindkét internetes interfészt up-ban tartani. Amint lekapcsoljuk ezen interfészeket (ifdown eth0.2) újra csak a VLAN3-ból hoazzáférhető a Linux hostunk. A VLAN5 interfész szintén változtat a route-okon, amikor felhúzzuk , ám itt specifikusan csak egyetlen subnetet adunnk a route táblához, csak annyit, amennyi a VLAN5-ön keresztül csatlakozó távoli telephely eléréséhez szükséges. A VLAN interfészek egyedi, a VLAN ID-t is magában foglaló MAC címe természetesen nem kötelező, ha nem állítjuk át, akkor a fizikai interfész MAC-címét fogja használni minden virtuális interfészen.

Mire jó mindez? Diagnosztikai célokra például nem rossz. Bármelyik VLAN-on el tudjuk éri a hostokat konzolból, sőt szükség esetén SSH-val áthozhatunk magunknak ezt-azt más VLAN-okból anélkül, hogy a normál route-olást felborítanánk. Bármikor egyetlen helyről fel tudjuk mérni az egyébként közvetlenül nem összekapcsolt VLAN-okban a hostok számát nmap-pel, tshark-kal belenézhetünk akármelyik VLAN broadcast forgalmába. Meg tudjuk mondani az 5-ös VLAN-ban dolgozó kollegának, hogy vajon azért nem éri el a bérelt vonal túloldalán lévő szervert, mert megszakadt a bérelt vonal vagy csak azért, mert nem dugta be a gépébe a patchkábelt, és még sorolhatnám.

Azt viszont minden körülmények közt érdemes szem előtt tartani, hogy nem megfelelő biztonsági beállításokkal hatalmas réseket lehet nyitni hálózatunk védelmén egy ilyen konfigurációval.

Cisco, HP, 3Com, H3C, Huawei CLI referencia

Gyanítom, az senkinek nem új hír, hogy a HP 2010-ben bekebelezte a 3Com-ot, azt viszont még a networkös szakmán belül sem szokás tudni, hogy a 3Com termékeken futó operációs rendszer, a 3Com OS gyakorlatilag megegyezik a Huawei eszközökön használt "Huawei Versatile Routing Platform Software" (VRP) rendszerrel, illetve a 3Com és a Huawei által még 2003-ban közösen gründolt H3C eszközein futó "H3C Comware Platform Software" (Comware) rendszerrel. Vagyis a 3Com OS, a Huawei VRP és a H3C Comware ugyanannak a network OS-nek változatai, nem különböznek jobban egymástól, mint a Cisco IOS különféle verziói: vannak bennük itt-ott apróbb eltérések, de ha valaki kiismeri magát a mondjuk a Comware-ben, az otthonosan fog mozogni a 3Com OS vagy a VRP alatt is. Sőt, a rokonság még ennél is szorosabb a volt 3Com, a jelenlegi Huawei, illetve a H3C termékek közt, az egyes termékeknek (persze nem mindnek) megvan (vagy volt) a maga testvére a másik két márka termékpalettáján, és ezek a testvérek bizony közös alkatrészeken is osztoznak. A kompatibilitás olyannyira létezik, hogy például e három márka SFP moduljai is csereszabatosak, használhatunk egy 3Com optikai modult Huawei vagy H3C eszközben és persze a dolog fordítva is igaz.

A HP megjelenésével tovább bővült ezt a nagyjából azonos hardver- és szoftverplatformot felhasználó márkák száma, a HP Networking termékek ezt a közös, illetve most már a HP tulajdonában lévő platformot használják. Csupa öröm egy ilyen platformot megtanulni, hiszen egycsapásra lehet bővíteni az önéletrajzunkat 3Com, Huawei, H3C és HP termékek ismeretével :). Ráadásul ebben a HP hatékony segítséget ad, most találtam rá a "HP Networking and Cisco CLI Reference Guide"-ra, amiben funkcióról funkcióra haladva összevetik a régi HP ProCurve termékeken futó ProVision, a 3Com-Huawei-H3C-HPN-féle Comware és a Cisco IOS parancsokat. A doksi kellően alapos, semmi sallang, nem próbálja megmagyarázni a különféle protokollokat, szabványokat, parancsok és példák gyűjteménye kevesebb mint háromszáz oldalon, kötelező minden networkös számára. Jó néhány évig még biztosan hasznát lehet venni, amíg el nem távolodik nagyon egymástól a régi 3Com-féle legacy rendszerek és a legújabb H3C/HPN rendszerek tudása.

Multi-VLAN bridge site-to-site VPN tunneleken Vyattával és OpenVPN-nel

Többféle megközelítése lehetséges a VLAN-ok telephelyek közötti átvitelének, ebben a posztban egy, a Vyattában nem túl régóta meglévő opcióval, az OpenVPN-nel esek neki a problémának. Alapvetően tesztről van szó, és mivel nem akartam túlságosan elbonyolítani, ezért a tesztkörnyezetben a teljes layer 2 egyetlen switchen lakik, ezen az egy switchen van az egyik telephely két VLAN-ja, a másik telephely két VLAN-ja, és persze a WAN kapcsolatot helyettesítő VLAN is. Layer 3-as funkciók (a tesztklienseket leszámítva) csak a Vyatta hostokon találhatók, ezekben csupán egyetlen NIC van, így minden interfész vagy VLAN interfész lesz vagy valamilyen egyéb virtuális interfész. A cél, hogy a két telephely között a kliensek számára transzparens layer2-es bridge épüljön fel az alábbi topológiával:

A bemutatandó módszer lehetővé teszi a VLAN ID átírást, és mivel a tesztkörnyezet layer 2-ben csupán egyetlen switch, szükség is lesz erre, de éles környezetben természetesen lehet ugyanazokat a VLAN ID-ket használni a kapcsolat mindkét oldalán. V1 és V2 lesz a két Vyatta teszt host, mindkettő egyetlen fizikai interfészen keresztül kapja meg a tagged VLAN-okat. V1 esetében ez a VLAN1, VLAN2, VLAN3, az ezeknek megfelelő interfészek értelemszerűen: eth0.1, eth0.2, eth0.3. A beállítások hasonlóak V2 esetén is, ám itt a VLAN2 átalakul VLAN20-ra a VLAN3 pedig VLAN30-ra.

Mielőtt ténylegesen belekezdenénk a VPN konfigurációba, állítsuk be a legalapvetőbb dolgokat! Szükség lesz egy VLAN1 interfészre, azon IP-re, SSH-ra, és a hostnév beállítása sem árt (a prompt csak egy kijelentkezés-bejelentkezés után vált V1-re az alapértelmezett "vyatta"-ról):

vyatta@vyatta:~$ configure
[edit] 
vyatta@vyatta# set interfaces ethernet eth0 vif 1 address 10.1.1.1/24
[edit]
vyatta@vyatta# set system host-name V1
[edit]
vyatta@vyatta# set service ssh        
[edit]
vyatta@vyatta# commit 
Restarting OpenBSD Secure Shell server: sshd.
[edit]
vyatta@vyatta# save
Saving configuration to '/opt/vyatta/etc/config/config.boot'...
Done

A továbblépés előtt hasonló  alapbeállítást igényel a V2-es Vyatta is. Ha megvagyunk, akkor jöhet a VPN: a site-to-site tunnelek felhúzásához az új OpenVPN-es Vyatta parancsokat fogjuk használni, és az egyszerűség kedvéért PSK-ra építünk. Ha jobban meggondolom, annyira azért nem új az OpenVPN a Vyattában, valamikor tavaly év elején került bele. Akárhogy is, a topológia megvalósításához két külön OpenVPN tunnelre lesz szükségünk, ezért a V1 alapbeállításai után az első feladat két kulcs létrehozása a V1-en, majd e két kulcs eljuttatása V2-re is. A kulcsok generálása a "vpn openvpn-key generate <fájlnév>" paranccsal történik:

vyatta@V1:~$ vpn openvpn-key generate /root/vtun0.key
vyatta@V1:~$ cat /root/vtun0.key  
cat: /root/vtun0.key: Permission denied
vyatta@V1:~$ sudo cat /root/vtun0.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
0cbcd00265518db1fd8b4ded2e721396
2ee1ef306d1163b82df0b478462ae35b
5764e128b8c6f15931c2ad0d94f1a477
c7aab38ca570cc20b0aeb8da8056dd27
d70d4bdf9b705af8cfe2380f57a7c840
ae24f6a9a1f13d5da1ebc18025b8d575
dc4634625c051bfbf976b72a8f35bca5
238bd80f371df2bac0f48ccd26968917
9b86c7067bf6a927c217f81d6f6b6840
7e133cc4fc677175a5702f841b11be4e
8c56c0cfc08497d1e599162757ec848b
26f670842245af40f45670b3ef257adc
784aa1f6b1c27c83e969aab0edca8b6b
dead67a4bad7630f18838cb0871b1449
a686356a001e4d3c34ecc8743f7c6067
95027528e178fb73994241e6348c3977
-----END OpenVPN Static key V1-----
vyatta@V1:~$ 

Az első paranccsal legeneráltuk az OpenVPN PSK-t és azt a "/root/vtun0.key" fájlba mentettük. Tulajdonképpen mindegy is, hogy hová mentjük, a fájl "root:root","600" jogokkal jön létre, tehát kizárólag a root felhasználó tudja írni-olvasni, másoknak semmilyen jogosultsága nincs a fájlra, és ez jól is van így. A példában ezért nem működik elsőre a fájl tartalmának kiírása, másodszorra viszont rootként megyünk, sudo-val, ezért nincs ilyen probléma. A "vtun0.key"-hez hasonlóan generáltassunk egy "vtun1.key"-t is, ez lesz a másik tunnelhez a PSK. Ha megvannak a kulcsok, akkor SCP-vel átmásolhatjuk őket a V2-re (figyelem: a kulcsok csak a root számára olvashatók, viszont az SSH PermitRootLogin no-val fut, "sudo -i"-vel tudunk bash shellt nyitni rootként a megoldáshoz). Persze SCP helyett másolhatjuk vágólapon keresztül is a kulcsokat vagy USB-n, a lényeg, hogy ugyanazok a kulcsok legyenek fent mindkét Vyattán.

Ezek után létrehozhatjuk a V1-en az első site-to-site bridge kapcsolatot. Készítünk egy "br0" nevű bridge interfészt, amelynek a tagjai az "eth0.2" és a "vtun0" lesznek, majd beállítjuk az OpenVPN paramétereket. OpenVPN esetén szeretem kihasználni az IPSec-től eltérő adottságokat, ilyen például a Blowfish kódolás (bf128), ami - ha pusztán a szoftveres implementációkat vizsgáljuk, márpedig a Vyatta esetén csak ilyenünk van - minden létező teszt szerint gyorsabb az AES-nél, az öregecskedő 3DES-t pedig nem is érdemes egy lapon említeni vele. A "br0" és a "vtun0" beállítását a következő parancsokkal végezhetjük el a V1-en:

set interfaces bridge br0
set interfaces ethernet eth0 vif 2
set interfaces ethernet eth0 vif 2 bridge-group bridge br0
set interfaces openvpn vtun0 bridge-group bridge br0
set interfaces openvpn vtun0 encryption bf128
set interfaces openvpn vtun0 hash sha1
set interfaces openvpn vtun0 mode site-to-site
set interfaces openvpn vtun0 remote-host 10.1.1.2
set interfaces openvpn vtun0 shared-secret-key-file /root/vtun0.key

Alapvetően rendkívül hasonló lesz a "br1" és a "vtun1" is, azt az apróságot leszámítva, hogy itt az OpenVPN által alapértelmezetten használt egyetlen portot UDP 1194-ről eggyel feljebb, az UDP 1195-re tesszük mindkét oldalon (így külön datagram socketre épül a vtun1 és a vtun0), és persze az interfész nevek mások lesznek:

set interfaces bridge br1
set interfaces ethernet eth0 vif 3
set interfaces ethernet eth0 vif 3 bridge-group bridge br1
set interfaces openvpn vtun1 bridge-group bridge br1
set interfaces openvpn vtun1 encryption bf128
set interfaces openvpn vtun1 hash sha1
set interfaces openvpn vtun1 local-port 1195
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 remote-host 10.1.1.2
set interfaces openvpn vtun1 remote-port 1195
set interfaces openvpn vtun1 shared-secret-key-file /root/vtun1.key

A sok pötyögés után jöhet a "commit" majd a "save", és a V1-en készen is vagyunk. A V2 konfigurációja alig tér el a V1-től, "vtun0" esetén "vif2" helyett "vif20", "10.1.1.2" helyett pedig "10.1.1.1" szükséges. A V2 "vtun1" pedig "vif3" helyett "vif30"-at használ, illetve itt is 1-re végződik a VPN peer IP-je. Említettem az elején: nem feltétlenül kell átírni a V2-es Vyattán a VLAN ID-ket, a tesztkörnyezet azonban nálam csak egyetlen switchet tartalmazott layer2-ben. Ha készen vagyunk a beállításokkal, a VPN kapcsolatok állapotát a "show interfaces openvpn", illetve a "show interfaces openvpn detail" paranccsal ellenőrizhetjük, A bridge-ek állapotát a "show bridge br0" vagy "show bridge br1" paranccsal kérhetjük le.

Vyatta alapok

Régebben, amikor még úgy gondoltam, hogy ismét felcsapok egy magyar IT portálon munkatársnak, már szemezgettem ezzel a network OS-szel, és többé kevésbé azóta is követem töretlen fejlődését, jómagam viszont mégsem csaptam fel semmilyen IT portálon semmiféle munkatársnak. A Vyattáról akkor leírtak ettől függetlenül természetesen továbbra is érvényben vannak, és a rendszer fejlesztőinek azóta sikerült rengeteg hasznos lehetőséget átemelni a Linux platformról a Vyatta által is támogatott elemek közé.

Nagyon sokat fejlődtek a 4-es verziók óta a VPN képességek, megjelent a WAN load balancing, jelentős átalakítás történt a tűzfal funkciókban, itt is átvették a más termékekben már jól bevált zóna koncepciót, és persze egyre több Vyatta funkció érhető el IPv6-on is. Az éppen aktuális 6.1-es Vyattában rettenetesen tetszik, hogy image-ként is lehet telepíteni, így csak a bootoláshoz szükséges fájlok és egy Squashfs image kerül fel a gépre, nem lesz rajta a hagyományos értelemben telepített Linux. Ezzel ismét egy lépéssel közelebb került a rendszer a hálózati eszközök világában megszokott konvenciókhoz. Több feltelepített image esetén boot menüben választhatunk a rendelkezésre álló "firmware"-ek közül. A rendszerhez egyetlen konfigurációs fájl tartozik, ebben a fájlban van a teljes konfiguráció, beleértve a szolgáltatásokat és azok paramétereit, a VLAN-okat, a userneveket, jelszavakat, tűzfalszabályokat, routeolási, NAT-olási beállításokat stb.

Gyorstalpaló az induláshoz:

• Ha csak próbálgatni, tesztelni szeretnénk, nem kell telepítés, live CD-n terjesztik.
• Bejelentkezés: user: vyatta, password: vyatta.
• Ez nem hagyományos értelemben vett Linux, mindent el tudunk végezni a Vyatta shell saját parancsaival, ne küzdjünk a megszokott bash shellért. Ha ilyesmire vágyunk, egyszerűbb egy rendes Linuxot elővenni. Egyébként a legtöbb alapvető UNIX parancs elérhető a Vyatta shellből, csak nincs meg hozzá a tab-os autocomplete, így olyan, minta nem is létezne (a "help" paranccsal kérhető rövid összefoglaló a támogatott UNIX parancsokról).
• Telepítéskor inkább az image alapú telepítést ("install-image" parancs) válasszuk, a régebbi módszernek ("install-system" parancs) csak akkor van előnye, ha módosítani szeretnénk a rendszer felépítésén, extra csomagokat akarunk használni, de ennyi erővel már telepíthetünk bármilyen Linuxot is, ehhez sem kell Vyatta.
• CLI üzemmódok: operational mode ($ prompt), configuration mode (parancs: "configure", # prompt)
• A konfiguráció hierarchikusan szervezett, node-okból és attribútumokból épül fel, a node-okat mindig kapcsos zárójellel {} határolt szövegrész követi, benne a node részleteivel, ami állhat újabb node-okból vagy attribútumokból. Pl:

  service {
     ssh {
         port 22
     }
 }

• Konfiguráció lekérése operational módban: "show configuration", konfig módban: "show".
• A beállítások tekergetése, módosítása (konfigurációs módban) mindig a "set" paranccsal kezdődik, utána felsoroljuk a node-okat amelyek mentén végül eljutunk a módosítani kívánt attribútumhoz (bizonyos esetekben elég csak a node-ot megadni: pl. "set service ssh"). Egy alap konfighoz, ami már lehetővé teszi a távoli adminisztrációt is SSH-n keresztül, a következő parancsokat kell kiadnunk:

set service ssh
set system host-name TESZT
set interfaces ethernet eth0 address 10.10.10.10/24
set system gateway-address 10.10.10.1

• Konfiguráció törlése: ugyanúgy történik mint a a beállítás, ám "set" helyett "delete" a parancs eleje. Nemcsak attribútumokat, hanem teljes node-okat is törölhetünk egyben.
• Az ilyen környezetben megszokott segítség (nyilak, tab, kérdőjel) itt is rendelkezésre áll, sőt a tab az általunk előzetesen már megadott értékekre, nevek, IP-címek, stb. is tudja az automatikus kiegészítést (sajnos nem minden node-on).
• A módosított beállítások nem jutnak azonnal a parancs kiadása után érvényre. Konfigurálás közben bármikor megnézhetjük a konfigurációs fájl aktuális állapotát a "show" paranccsal. Azon sorok előtt, amelyeket frissen adtunk a konfigurációhoz és még nem részei az éppen futó beállításoknak egy "+" jel áll. Ugyanígy a törölt sorok előtt egy "-" jel áll.
• A "commit" parancs konfigurációs módban aktualizálja a konfigurációs változásokat, és ténylegesen is beállítja a rendszert.
• A "save" parancs menti a konfigurációt (hogy egy újraindítás után is meglegyen).
• Konfigurációs módból való kilépés: "exit".

A szórási tartományok méretéről

Néhány éve, amikor elkezdtem a jelenlegi munkahelyemen dolgozni, egyszerűen sokkolt a gondolat, hogy azon a telephelyen, ahol én is ügyködni fogok, teljesen strukturálatlan a LAN layer3-ban. Az adott telephely legtöbb munkaállomása, a notebookok, a nyomtatók, a szerverek, a termelési gépek, az ilyen-olyan célhardverek, biszbaszok, beágyazott rendszerek, a hálózati eszközök management felülete, a szerverek iLO/RMC portjai, de még a céges wifi is egyetlen nagy /21-es hálózatban élt egymás mellett.

Komolyan azt gondoltam, hogy itt vége a világnak, hogy ez maga a fertő, a networkös pokol. Persze tudtam, hiszen korábban az interjúk során is elmondták, hogy az alkalmazásom egyik oka épp ez, hogy vannak úgymond anomáliák ezen a telephelyen, amiket meg kellene oldani, és hogy addig nem volt teljes állásban hálózatos ember. Mondanom sem kell ugye, minden létező szakkönyv szerint ellenjavallt az ilyen bazi nagyra felhízlalt broadcast domain, amiben még a legcsendesebb éjszakákon is működget nagyjából 1000 host, de volt olyan időszak, amikor a /21-es hálózat 2000-es gépszáma is elérhető távolságba került.

Most már lassan három éve élek együtt ezzel a dinoszaurusszal a munkahelyemen, és persze az évek során számos dolog letisztult, nagyon sok host, sok munkával, szervezéssel külön VLAN-okba került, innen is csippentettünk egy kicsit, onnan is, ezeknek a hostoknak ilyen VLAN, amazoknak amolyan került, de alapvetően a harminc-egynéhány VLAN mellett a  /21-es nagy hálózat ma is létezik, rengeteg benne a gazdátlan, fix IP-s host, melyek adminisztrációjával senki nem akar törődni, egészen addig, míg nincs vele valami baj, szóval a telephely életébe, működésébe szó szerint ezer szállal bele van fűzve a /21-es monstrum.

Azt gondolná az ember, hogy az elképzelhetetlen mennyiségű broadcast forgalom miatt itt nincs egyetlen ép host sem, de a helyzet valójában nem annyira vészes. A broadcast forgalom legnagyobb része egyébként az SMB/CIFS balgaságaiból adódik, rettenetesen szószátyár ez a protkollcsalád, és persze nálunk is SMB/CIFS-et natívan beszélő Microsoft OS-ek vannak leginkább a hostokon. De még ennek ellenére is az átlagos broadcast terhelés nagyából megáll 50-70 kbit/s környékén. Multicastot nem használunk, az egyetlen dolog, ami még rondíthat ezen az 50-70 kbit/s-on, az az elárasztásos (flood) forgalom. Ilyen floodként jelentkezik a switchek által nem ismert MAC-címre történő forgalmazás, amit a broadcast domain minden hostja megkap, mert a switch nem tudja, hogy melyik portjára switchelje, így kiteszi mindegyikre - sajnos vannak olyan "megoldások", amelyek építenek is erre az egyébként nem kívánatos jelenségre.

Hogy mit tapasztalhat az ember 50-70 kbit/s állandó broadcast mellett? Semmit. Nevetségesen kicsi ez a forgalom az elérhető 100 vagy 1000Mbit/s-os sebességhez viszonyítva, nincs érezhető, mérhető hatása a hostok működésére. Sajnos emiatt a döntéshozók sem értik meg az IP szegmentáció mielőbbi szükségességét. Biztos vagyok benne, hogy még csak nem is feszegetjük a technológia határait, és hogy egy hostokkal megpakolt /20-as vagy akár egy /19-es is működőképes lenne.

Azt azért nem állítom, hogy soha nincs gond egy ilyen méretű hálózattal alapvetően magára a méretére visszavezethető okok miatt. Egyszer például néhány kolléga úgy látta jónak, ha Norton Ghosttal, anélkül, hogy bármilyen hálózati támogatás lett volna hozzá, multicast üzemmódban terítenek image-eket néhány gépen. A switchek persze azonnal broadcastba fordították a multicast forgalmat, és tolták minden portjukon, ami csak a csövön kifért. Na, ezt már mindenki megérezte, 80 Mbit/s egy ekkora hálózat minden portján azonnal látványos eredmény ad. De ez egy extrém példa, és nem áll neki bárki multicast Ghost terítésnek, viszont látható, hogy ha a napi rutinfeladatokon nem is vérzik el a nagy szórási tartomány, biztonsági szempontból semmiképp nem javasolt.

Meggyőződésem, hogy amennyiben valaha is megszűnik ezen a telephelyen a /21, az biztonsági problémák miatt lesz. Gondoljunk csak bele, hogy egy ekkora szórási tartomány micsoda lehetőségeket tartogat a különféle layer2-es támadásokra, ARP spoofingra, STP támadásokra, de még egy egyszerű passzív broadcast forgalom gyűjtögetés is rengeteg értékes információval szolgál.Őszintén szólva nem is szeretek rá csatlakozni, inkább megyek wifin, ami azóta külön subnetbe került vagy remote access VPN-en (szintén külön subnet). Csak a kollégáim meg ne tudják... (tudják) :)

Szeretem a Cisco AP-k carrier busy tesztjét

Régóta keresgélek alternatívát az autonóm Cisco AP-k IOS-ében rendelkezésre álló carrier busy tesztre. Na jó, talán még a keresgélek használata is túlzás, mondjuk úgy, hogy időnként elszontyolodom, hogy nincs (vagy nem tudok) hasonló dologról például a notebookomra, vagy mondjuk Androidra. Valami egyszerű kis parancssoros util megtenné, amivel gyorsan, könnyen lehet felmérni a teljes wifi tartomány layer1-es kihasználtságát.

A félreértések elkerülése végett: nem wifi analyzert keresek, ami grafikonokat rajzolgat az elérhető SSID-kről, csatornákról, és azokat tudja ilyen vagy olyan szempontok szerint rendezgetni, nem. A carrier busy teszt az IOS-ben ennél sokkal alapvetőbb, a fizikai rétegre vonatkozó teszt, ami azt vizsgálja meg, hogy van-e bármilyen, az AP rádióvevője számára érzékelhető forgalom a szabad frekvenciatartományban. Ez aztán lehet persze a szomszéd wifije, de lehet mikrosütő, rádiós kamerarendszer, vezeték nélküli telefon, bármi, ami interferálhat a wifi jelekkel. Ezzel a carrier busy teszttel tehát megállapítható, hogy az adott pillanatban van-e az adott AP környékén zavaró jelforrás, ami tönkre vághatja a wifi kommunikációt. Annyira nem részletes mint egy komplett spektrum analízis, de jól használható és a CLI elég hozzá.

Aki esetleg nem ismerné ezt a tesztet: a "dot11 <interfész> carrier busy" paranccsal futtatható, és mindössze néhány másodpercig tart, míg végigszkenneli a frekvenciatartományt. A parancs kiadásakor az AP-n természetesen minden kiépített wifis kapcsolat megszakad, az adott AP-n lógó klienseknek újra kell majd authentikálniuk stb. A lefutás után látszólag nem történik semmi, de a teszt eredményét a "show dot11 carrier busy" paranccsal egyetlen egyszer meg tudjuk jeleníteni. A példában látható, hogy nem egy rádiószmogos környéken lakik a teszt AP, a 6-os channelen valami csordogál (2427-2447), de például az 1-es (2402-2422) vagy a 11-es (2452-2472) nagyjából kihasználatlannak tűnik:

AP#dot11 dot11Radio 0 carrier busy
AP#show dot11 carrier busy       

Frequency  Carrier Busy %
---------  --------------
   2412          0
   2417          1
   2422          1
   2427          3
   2432          6
   2437          4
   2442          2
   2447          2
   2452          0
   2457          0
   2462          1
   2467          0
   2472          0
AP#show dot11 carrier busy
AP#

A "show dot11 carrier busy" ismételt használata semmilyen eredményt nem ad egészen addig, amíg meg nem ismételjük a carrier busy tesztet, ekkor az új eredményt - szintén csak egyszer - listázza. Nem egy spektrum analízis, de legtöbbször ennyi is megteszi. No, valami ilyesmit keresek időnként Linuxra, Windowsra vagy Androidra, és eddig még nem találtam.

Cisco IOS Netflow ingress, egress, v5, v9

Korábban íram már egy postot Netflow ügyben, az egyik MPLS-szolgáltatónk sok-sok vesződség után sem tudta felkonfigurálni a routerét úgy, hogy az a WAN interfészéről mind a bemenő mind a kijövő forgalomról tudjon információt adni. Mennyire bonyolult egy ilyen dolog? Hát, annyira azért nem... Teljes, jól működő beállításra példa:

router(config)#interface FastEthernet 0/0
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#interface FastEthernet 0/1
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#ip flow-export destination 10.10.10.10 9999
router(config)#ip flow-export source FastEthernet 0/0
router(config)#ip flow-export version 5
router(config)#ip flow-cache timeout active 1
router(config)#ip flow-cache timeout inactive 15
router(config)#snmp-server ifindex persist

Az interfészenkénti "ip route-cache flow" parancsot minden olyan interfészen ki kell adnunk, amelyen az általunk figyelni és elemezni kívánt forgalom át fog haladni. Mindegyiken. Ennek az az oka, hogy az alapértelmezett Netflow v5 csak a bejövő adatokról gyűjt és továbbít bizonyos időközönként összesített forgalmi információt (flow-t). Ha tehát a routeremben pl. csak az Fa0/0 és az Fa0/1 interfész forgalmaz, akkor az Fa0/1 bejövő adatairól alapból lesz információm, viszont az Fa0/1 kimenő adatokról csak akkor, ha engedélyezve van a Netflow az Fa0/0-n is, és az Fa0/0 bejövő adatait tudja majd a Netflow collector szoftverem az Fa0/1 kimenő forgalom adatainak előállításához felhasználni. Vagyis minden releváns, a forgalmunk által érintett interfészen engedélyeznünk kell a Netflow-t, különben nem azt fogjuk kapni, amire számítunk.

Az "ip flow-export destination" globális konfigurációs módbeli paranccsal állítható be a Netflow forgalom célja, itt kell megadni azt az IP-t vagy hostnevet és portszámot ahol a Netflow adatokat gyűjtő szoftverünk (collector) fülel. A collectornak küldött csomagokban a forrás IP cím annak az interfésznek az elsődleges IP-je lesz, amelyet az "ip flow-export source" után megadunk.

Az "ip flow-export version" egyértelmű, az általunk használni kívánt Netflow verziót adhatjuk meg vele, a két leggyakrabban használt verzió az 5-ös és a 9-es.

A következő két parancs a router által kezelt flow-cache ürítésére (a flow-k collectorhoz való elküldésére) vonatkozik. Az "ip flow-cache timeout active" egy aktív, azaz rendszeresen frissített flow-cache bejegyzés maximális élettartamát adja percekben. A cégünknél használt Netflow Analyzer nevű collector például a max. egy perces élettartamot preferálja, az IOS alapértelmezett érték egyébként 30. Az "ip flow-cache inactive timeout" az inaktív flow-kra vonatkozó időzítő, amely a nem frissített (befejeződött az adott típusú forgalom) flow-cache bejegyzések esetén megadja, hogy az inaktív státuszba lépés után még meddig maradhat az adott flow-cache bejegyzés a cache-ben.

Mivel a Netflow collectorok általában SNMP-s hozzáférést is igényelnek kiegészítő információk beszerzéséhez, pl. router adatok, hostnév, interfész adatok, ezért érdemes az SNMP-t úgy beállítanunk a routeren, hogy egy esetleges újraindulás után az interfészeink ugyanazokat az SNMP interfész indexeket kapják (snmp-server ifindex persist).

Persze még van egy-két kanyar. Itt van mindjárt az alinterfészek kérdése. A "ip route-cache flow" engedélyezi a flow-k gyűjtését egy adott fizikai interfészen és annak minden alinterfészén. Ha kizárólag egy alinterfész adataira vagyunk csak kíváncsiak, akkor azt az adott alinterfészen az "ip flow ingress" paranccsal aktiválhatjuk.

A Netflow v5 és v9 közötti egyik fontos különbség, hogy a v5 - ahogy arról már volt szó - csak ingress irányt támogat, míg a v9 használata esetén megnyílik a lehetőségünk az egress irányú flow-k gyűjtésére is, vagyis v9 esetén akár elfelejthetjük azt a v5-nél még obligát szabályt, hogy minden interfészen engedélyeznünk kell a Netflow-t. Az egress irányú flow gyűjtéséhez szükséges az "ip flow-export version 9", illetve az interfészen az "ip flow egress" parancs kiadása.

Nem árt továbbá, ha figyelünk az "ip flow-export source" interfész megadásánál. Ha fizikai interfészt adunk meg, számolnunk kell azzal az eshetőséggel, hogy az interfész (bármilyen okból) leesik. Ekkor a Netflow collectorunk hibaüzenetet küldhet, még akkor is, ha egyébként maga az eszköz elérhető marad alternatív útvonalon. Megoldás? Az ip flow-export source is elfogad loopback interfészt.

Végül pedig, visszatérve a szolgáltatónkra: körülbelül három hét levelezés és 5-6 telefonhívás után feladtam. Egy kivételével minden általuk adott routeren jól működik a Netflow, az az egy pedig, ami továbbra is csak az egyik forgalmi irányról ad flow-kat, úgyis csak egy backup router. Egyszerűen belefáradtam, csináltak ők mindent, volt router újraindítás, IOS frissítés, Netflow konfig törlés és újrakonfigurálás, másik mérnök újra ellenőrizte, majd egy harmadik, egyszer még egy fél órára jól is ment a Netflow még ezen az egy routeren is, de mire elért a szolgáltatóhoz a "most jó, ne keressétek tovább a hibát" üzenet, már továbbléptek. Az utolsó állapot az volt, hogy v9 használata mellett a router minden portjáról jön ingress és egress adat, kivéve azt a portot, amit tényleg figyelni szeretnék. Nem tudom, hogy mi lehet vele baj, nincs rálátásom a konfigurációjukra, lehet, hogy én sem tudnám megjavítani. Persze az emberben mindig ott motoszkál ilyenkor az a fura érzés, hogy esetleg nem is próbálták ezt annyira komolyan megoldani. Akárhogy is, nem számít már.

TCP/UDP session timeout értékek beállítása FortiOS-ben

A közelmúltban egy különös problémára sikerült megtalálni a megoldást. Az egyik telephelyünkön az ERP rendszer felhasználói egyik napról a másikra elkezdtek panaszkodni, hogy mindig kidobja őket a rendszer, és hogy naponta hússzor bejelentkezni nem vicces. Persze nem is hozzám került első körben a probléma, megjárta az ERP rendszerünkért felelős outsourcing partnert, és csak utána került a hálózatos csapathoz.

Annyit érdemes tudni az ERP-nkről, hogy egy özönvíz előtti, kb. tizenöt éves Baan verziót (IV) használunk. Az összes Baan szerverünk és adatbázisunk a Global Data Centerünkben van, a szóban forgó telephelyen pedig csak kliensek vannak, így minden ERP-vel kapcsolatos forgalom át kell, hogy menjen a belső WAN-unkon. Ezen kívül pedig volt még két másik tényező is: a kérdéses telephelyen a bérelt vonalat új szolgáltatóhoz vittük, illetve két héttel később belső tűzfal is került a csomagok útjába.

Mivel az adott telephelyen én felügyeltem a bérelt vonal migrációját illetve a tűzfal telepítést, megnyertem a Baan kliensek problémáját is. Az új szolgáltatót, mint problémaforrást viszonylag hamar ki lehetett zárni, hiszen az új vonal üzembe helyezése és a tűzfal telepítése közt eltelt két hétben a Baan kliensek hasítottak, bejelentkeztek reggel, kijelentkeztek délután, nem panaszkodott senki eldobált sessionökre.

Ideiglenes megoldásként a szerveres csapattal összefogva azt a megoldást javasoltuk első körben az adott telephely Baan usereinek, hogy akiket valóban zavar, hogy nem él egész nap a sessionjük, azok használják a Global Data Centerünkben frissen telepített Windows Server 2008 alapú új terminál szerver szolgáltatást, amin fent van a Baan kliens is, kiváló, gyors (LAN) kapcsolatuk lesz az adatbázissal, stb. Közben Baan forgalomra készíttettem az MPLS szolgáltatónkkal QoS-t, hátha... persze ehhez túl sok reményt nem fűztem, de mindenesetre egyértelműen monitorozhatóvá vált, hogy van-e gond az ERP-vel kapcsolatos adatforgalommal az MPLS-ünkben, hát nem volt.

Mondanom sem kell, minden egyéb forgalom tökéletesen rendben volt, nem volt gond a WAN-on keresztül az RDP sessionökkel, CIFS-sel, HTTP-vel, semmivel, csak a Baan4 gyengélkedett. Az adott telephely LAN-jában sem történtek változások, a fizikai réteggel kapcsolatos problémákat (laza patch kábel, vacak optikai kapcsolat LAN gerincen stb.) szintén gyorsan ki lehetett szórni, mint lehetséges problémaforrásokat. Maga a Baan IV kliens program sem egy bonyolult jószág, nincsenek speciális TCP beállításai, amelyek változása esetleg okozhatna hasonló jelenséget. Volt egy zsákutca még a kliensek védelmét ellátó Symantec SEP csomaggal, hátha ott valamilyen félresikerült policy kavar be... de nem, SEP nélkül is hullottak a sessionök, ha magukra hagyták őket a userek.

Időközben a belső tűzfalas projekt futott tovább, és hogy, hogy nem egy másik telephelyen is felmerült ugyanez a gond a Baan kliensekkel nem sokkal az ottani Fortigate tűzfal cluster telepítése után. Innen már viszonylag egyszerű volt a végkövetkeztetést levonni: a Fortigate-eken akadnak fenn a Baan sessionök. Valamiért a Baan IV TCP keepalive kezelése (ha van egyáltalán ilyesmije) nem kerek, és a Fortigate tűzfalak némi inaktivitás után egyszerűen eldobják a sessiont, szegény kliens meg csak áll, és nem érti, hogy ki vette el tőle az ő kis kapcsolatát a szerverhez.

De mit lehet ezzel kezdeni? Van ugyan a FortiOS-ben egy "system session-ttl" parancs, amivel minden (!) TCP és UDP sessionön meg lehet növelni a keepalive értéket, de ezzel ugye viszonylag hamar le lehet térdeltetni a tűzfalat, hiszen annak sem végtelenek az erőforrásai. Kiderült, hogy a FortiOS 4.0-ban viszont már nem csak system szinten, hanem firewall rule-onként lehet TTL-t állítani ("set session-ttl <másodperc>" az adott rule-on belül). Szóval a megoldás mindenhol az lett, hogy a Fortigate-eket frissíteni kell legalább 4.0-ra, majd egy külön rule készült a Baan forgalomra, amelyben a session-ttl értéket be kell lőni 28800-ra (8 óra). A tanulság? A tűzfal még akkor is tud nagy gondot okozni, ha egyébként tisztességgel átengedné a kérdéses forgalmat.

A legjobb szolgáltató

Alapvetően nem szeretném, ha a blog szolgáltatók vagy termékek fikázásáról szólna, de a mai esetet muszáj megírnom. A cégünknél az összes telephely esetén a külső tűzfalak, illetve a s2s VPN hálózat üzemeltetése ki van szervezve. Nos, ettől a cégtől kerestek ma telefonon, hogy nem érik el az egyik telephelyünkön az eszközüket, és hogy tudok-e erről valamit.

A kérdéses telephelyen kizárólag s2s VPN van, semmilyen egyéb bérelt vonali kapcsolat nem áll rendelkezésre. Kicsit furcsálltam azonban a dolgot, mert a telephelyen lévő monitorozott hostok mindegyike elérhető volt, semmilyen riasztást nem kaptunk kapcsolódó problémákról, szóval, semmi jelét nem láttam annak, hogy bármilyen probléma lenne az ottani tűzfallal vagy a VPN tunnellel.

Nem is volt, az egyetlen gond az volt, hogy a szolgáltatás kb. egy hónappal ezelőtti telepítése óta a külső cég nem készített az adott eszközön magának management VPN tunnelt, pedig ezt annak idején a kollégám nyomatékosan kérte tőlük, épp azért, hogy ne legyen probléma a tűzfal általuk történő adminisztrációjával. Ma viszont valamilyen különös okból kifolyólag észrevették ezt problémát.

Ezek után tehát felhívnak telefonon, hogy valószínűleg megállt az adott telephelyen a szolgáltatásuk, és hogy tapasztalunk-e bármilyen problémát? Mondom a servicedeskesüknek, hogy nem, sőt a VPN és a tűzfal szolgáltatás is üzemel a saját monitorozó rendszereink adatai alapján. "Hm... ez igazán jó hír" - jött a válasz - "Elnézést a zavarásért. Annyit még tudna segíteni, hogy mi a külső IP címe az adott telephelyen az eszközünknek?".

No, az hiszem, ennél a pontnál foszlott szét minden kiszervezett szolgáltatásba vetett hitem, ha volt ilyesmim egyáltalán, hiszen a szolgáltató a szolgáltatásával kapcsolatos alapvető adatokat, dokumentációkat nem ismeri (pl. külső IP cím), nem képes monitorozni azt a saját rendszerivel (management VPN tunnel hiánya), ráadásul a saját eszközével kapcsolatos probléma elhárításához tőlem, az ügyféltől kér segítséget... és persze a negyedév végén mindezért benyújtja a számlát is. Ez a tökéletes üzleti modell, valóságos aranybánya, ilyet szeretnék magamnak én is.