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.