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.