DHCP relay agent HSRP mellett IOS-en

Eddig még sosem kellett HSRP-s virtual router groupon (VRG) DHCP-t relayeznem, ma ez is megtörtént. Nem egy bonyolult dolog, de az mégiscsak érdekes, hogy a VRG-ben lévő eszközök közül akkor pontosan melyik fogja ellátni a relay funkciót. Addig ugye világos, hogy semmiképp nem állhatunk meg ott, hogy csupán az elsődleges eszközön konfigurálunk az IOS-ben ip helpert, hiszen akkor nem lesz redundáns a megoldás.

Ha a fenti topológiában mindkét eszközön (R2, R3) beállítjuk az ip helper funkciót a következők szerint:

R2
interface Fa0/1
 ip address 10.10.25.2 255.255.255.0
 ip helper-address 10.10.1.4
 standby 25 ip 10.10.25.1
 standby 25 priority 101
 standby 25 preempt

R3
interface Fa0/1
 ip address 10.10.25.3 255.255.255.0
 ip helper-address 10.10.1.4
 standby 25 ip 10.10.25.1
 standby 25 priority 99
 standby 25 preempt

...akkor arra számíthatunk, hogy a DHCP szerverünk a 10.10.25.0/24-ből érkező DHCP kéréseket duplán fogja kiszolgálni, mert az R2 és az R3 külön ip helper processzei nem tudnak egymásról semmit, csak figyelik az UDP broadcast forgalmat, és teszik a dolgukat süketen és vakon: kétszer fog eljutni minden klienstől minden DHCP üzenet a DHCP szerverre és vissza.

Ahogy az a fenti példában (a kliens szemszögéből) láthatjuk, jámbor kliensünk megpróbálja megújítani a régi IP-jét a 22-es keretben, ám a zord relay agentek egyszerre ráförmednek a DHCP szerver nevében, hogy dobja el, de rögtön (27 és 29), ekkor emberünk belekezd egy új cím igénylésébe (31), amit minden ügynök továbbít a szerver felé, majd a szerver válaszát meg vissza a kliensnek, és így tovább, amíg le nem zárul a folyamat. Ha nem túl háklis a DHCP szerverünk, akkor ezekből a dupla üzenetekből különösebb problémánk nem adódhat.

A Cisco vonatkozó oldalán jelzett szoftververzióktól kezdve azonban véget vethetünk az ip helperek süketelésének, ugyanis a fenti konfigurációt egy-két aprósággal kiegészítve már a VRG állapotától tehetjük függővé az ip helper ténykedését. A relaying kizárólag a VRG-ben éppen aktív eszközön fog működni, azaz megszűnik a fent leírt jelenség, ha minden eszközt hasonlóan konfigurálunk:

R2
interface Fa0/1
 ip address 10.10.25.2 255.255.255.0
 ip helper-address 10.10.1.4 redundancy nemsuket
 standby 25 ip 10.10.25.1
 standby 25 priority 101
 standby 25 preempt
 standby 25 name nemsuket

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.

DHCP relay agent NAT-olt hálózatban: esélytelen

Adott egy telephelyünkön egy több subnetre osztott LAN, minden subnetben a LAN router a DHCP relay agent, ez így eddig tiszta sor, semmi meglepő nincs benne. Na most vannak persze olyan subnetek is ezen a telephelyen, amelyek nincsenek Layer 3 összeköttetésben a telephely egyéb részeivel, ezer oka lehet, a legtöbb persze nem szakmai, mindenesetre ilyesmi dolgot kell elképzelni:

A gondok természetesen akkor kezdődnek, amikor a 192.168.1.0/24-ben mégiscsak akadnak hostok amelyek a többi subnettel kommunikálnának. Persze ilyenkor a network admin kaján vigyorral közli, hogy látjátok-látjátok, nem kellett volna azt a subnetetet így oda tenni, megmondtuk mi annak idején, hogy olyan hálózatot válasszatok, ami illeszkedik a globális címzési rendszerünkbe és a telephelyen használt supernetben benne van.

Aztán a vigyor, meg a címzési tervek gyorsan eltűnnek, amikor kiderül, hogy itt most nem "légből kapott", "ködös" elvekhez kell ragaszkodni, hanem a felmerülő üzleti igényeket kell gyorsan, pontosan kiszolgálni, és nincs apelláta: a 192.168.1.0/24-nek tudnia kell kommunikálni, most, nincs sem idő, sem erőforrás, sem hajlandóság az utált subneten belüli 150+ statikus IP-s hoston címváltásra (vagyis nem lehet belőle semmilyen körülmények közt sem pl. 10.10.15.0), és igazából csak a VLAN99-ből kell elérni egy-két külső dolgot, "hát már ennyit sem lehet rátok bízni?" stb.

Száz szónak is egy a vége, meg kell patkolni, egy végzetes napon a VLAN99 NAT-olva rácsatlakozik a VLAN10-re. Aztán jönnek az újabb és újabb problémák, amelyek fel sem merülnének ugye, ha a VLAN99 rendes subnet lenne, olyanok például, hogy egyik-másik adatbázis szervert a VLAN99-ben mégiscsak el kellene érni kívülről, legyen port forward, ezt ide, azt oda, akkor persze jön a kérdés, hogy miért nem lehet a belső adatbázis-szervereket kívülről pingelni, aztán újabb és újabb port forwardok, persze az egész rögtön biztonsági kérdéseket is felvet, mert természetesen a VLAN99-ben nincs szabványos kliensvédelem, hiszen az úgyis "szeparált", szóval egy-két év alatt ebből egy teljesen dokumentálatlan össze-vissza rugdosott rendszert lehet felépíteni, amihez senki nem nyúl szívesen, akik meg használják, elégedetlenek.

Na, most ott tart a dolog, hogy a VLAN99-ben be kellene vezetni a központi DHCP szolgáltatást, és persze sikerült ráfutni a DHCP relay agent beüzemelése közben egy elég alapvető problémára: NAT-olt hálózat felé nem fog menni a relayezés, hiszen a relay agent még csak kiküldi a VLAN99-ből a DHCP üzeneteket a DHCP szerver felé, azonban a relay agent és a DHCP szerver közt már unicast forgalom zajlik, amely kommunikációban a relay agent a belső, a DHCP szervertől távolabbi lábának az IP-jével vesz részt (pl. 192.168.1.1), így a DHCP szerver hiába küldené vissza a választ a default gatewayen... Persze így vagy úgy folytatódni fog a hályogkovácsolás, át lehet azt a DHCP-t küldeni ezer más módon.

Az egészben a legbosszantóbb, hogy az üzleti oldal még mindig, sok év után sem látja, hogy itt az alapkoncepció hibás, ugyanakkor újabb és újabb dolgokat építene az ingatag alapokra. Erős IT-t szeretnék, ahol nem engedik ki az IT kezéből az IT-ra tartozó döntéseket.