DHCP over een VPN: de broadcast bruggen of doorsturen?

Een nieuwe laptop aan de andere kant van de tunnel krijgt geen adres, terwijl dezelfde laptop op het hoofdkantoor werkt. De gebruikelijke eerste veronderstelling is dat de tunnel DHCP blokkeert. Vaker heeft de broadcast nooit een pad gehad: een niet-geconfigureerde client stuurt naar 255.255.255.255, en een gewone IP-router stuurt dat pakket niet door. De tunnel doet precies wat een gerouteerde tunnel doet.

Twee ontwerpen kunnen dat veranderen, en ze zijn niet gelijkwaardig. Het ene draagt de broadcast; het andere stuurt het verzoek door.

De broadcast steekt de router nooit over

Een DHCPv4-client zonder adres stuurt van 0.0.0.0 naar het beperkte broadcastadres op UDP-poorten 67 en 68. Dat pakket blijft ontwerptechnisch op zijn eigen link. Een router die het doorstuurde, zou elk segment dat hij bedient overspoelen.

Een gerouteerde site-naar-site-tunnel verbindt dus de relay met een server. Hij breidt het broadcastdomein van de client niet uit, en geen enkele firewallregel zal dat bewerkstelligen.

Wat een gebrugde tunnel werkelijk uitbreidt

Een bewust gebrugde VPN kan Ethernet-broadcast dragen binnen zijn ondersteunde topologie, en dan kan DHCP als lokaal verkeer passeren. Dat is een echte optie, maar het is een ontwerpkeuze op laag 2. Je breidt het foutdomein en de toegangsgrens uit samen met de broadcast.

Bruggen verandert ook wat een broadcaststorm, een ARP-scan of een kwaadwillende DHCP-server kan bereiken. Als je het filiaal niet op dezelfde switch zou aansluiten, brug de tunnel dan niet alleen om adressen uit te delen. Test die impactstraal voordat je het inschakelt.

Het is een grotere beslissing dan het leveren van een adres, en ze moet bewust worden genomen.

Stuur het verzoek in plaats daarvan door

Het gebruikelijke antwoord is een relay op het lokale netwerk van de client. Die ontvangt de broadcast, zet hem om in een unicast-verzoek en zet zijn eigen adres in het gateway-adresveld. De server antwoordt naar dat relayadres.

Voor een illustratief filiaal zit de relay op de LAN van het filiaal en wordt de server bereikt via de site-VPN. Configureer het bereik voor dat filiaal, de identiteiten van relay en server, en het volledige retourpad. UDP 67 door de tunnel toestaan vertelt de server niet welke pool te gebruiken.

Een relay die doorstuurt maar nooit een antwoord ontvangt, is meestal een retourpadprobleem. Controleer de route terug naar het relayadres voordat je het bereik wijzigt.

Scheid DHCP van ARP en van tunneladressering

DHCP loopt over UDP/IP. Op Ethernet kan een host ook ARP gebruiken om te controleren of een kandidaatadres al in gebruik is. Die conflictcontrole is een aparte linklokale bewerking, niet het transport voor DHCP-berichten. Zeggen dat DHCP in wezen ARP is, is onjuist; zeggen dat de twee nooit verband houden, is te breed.

Een VPN-client kan zijn tunneladres ook van het VPN-protocol of uit de eigen pool van de server halen in plaats van uit een DHCP-broadcast. Een optie met DHCP in de naam kan gepushte clientinstellingen beschrijven, niet een doorgestuurd DHCP-pakket. Controleer de pool van de server voordat je aanneemt dat DHCP er überhaupt bij betrokken is.

Noteer het ontvangende netwerk, de eigenaar van de toewijzing, het bereik, of er een relay is en het verwachte gedrag tijdens een storing. Test daarna een nieuwe lease en een vernieuwing via dat model. Als twee sites dezelfde onbeheerde pool kunnen bedienen, heb je een conflict dat op de eerste rondreizende laptop wacht.