VPN-poolen din er ikke LAN-ets DHCP-område: derfor knekker det

Den fristende snarveien er å gi VPN-klienter adresser fra samme område som kontorets DHCP-server bruker, ut fra teorien om at alt tross alt er ett nett. Det er det ikke. En rutet tunnel frakter unicast-pakker mellom to endepunkter, mens LAN-poolen finnes for å svare på broadcast-forespørsler på et fysisk segment. Å gjenbruke numrene setter to tildelere ansvarlige for ett adresserom og lar returveien stå udefinert.

To tildelere, ett adresserom

DHCP-serveren i LAN-et vet hvilke adresser den har leid ut og til hvilken MAC-adresse, og forsvarer dem med ARP. VPN-serveren har sin egen pool og vet ingenting om disse leieforholdene. Ingen av dem tar feil; de ble bare aldri presentert for hverandre.

En adresse fra LAN-poolen som VPN-serveren deler ut, kan allerede tilhøre en skriver. Nå krever to enheter én adresse på samme prefiks, og svitsjens videresendingstabell avgjør hvilken som svarer.

Det er feilen folk møter først: en klient som kobler til med hell og deretter når feil maskin, eller når den riktige med mellomrom.

Hvorfor ruteren ikke deler ut VPN-adresser

DHCP-oppdagelse er en broadcast, og broadcaster stopper ved en rutet grense. Med mindre designet broer tunnelen eller kjører en DHCP-relay med tilsvarende myndighet, når klientens forespørsel aldri LAN-serveren.

Derfor tildeler VPN-serveren adressen selv: en pool i serverkonfigurasjonen, én adresse per peer i et WireGuard-oppsett, eller en adresse som autentiseringslaget skyver gjennom i en IKEv2-utrulling. Disse mekanismene er uavhengige av LAN-ets leiedatabase, og det er nettopp derfor de trenger sitt eget område.

Samme resonnement forklarer hvorfor endring av DHCP-området ikke reparerer en VPN-klient som aldri får en adresse. Klienten spør ikke LAN-serveren, og ingen redigering av området får den til å spørre.

Overlappingen viser seg som en konflikt, ikke som et tregt nett

To nett som deler et prefiks uten et støttet design er et annet problem enn dobbelt eierskap, og de forveksles ofte. Hvis VPN-poolen er et eget prefiks, betyr overlapping bare noe når en rute sender trafikk til feil side. Hvis poolen ligger inne i LAN-prefikset, er konflikten umiddelbar og lokal.

I praksis ser du ARP-svar fra feil enhet, tilkoblinger som nullstilles halvveis, og en klient hvis egen adresse kreves av noen andre. Ingenting av dette ser ut som et ruteproblem, og derfor settes rettelsen inn på feil lag. En dobbel lease er lett å bekrefte og irriterende å leve med. Den overlever også omstarter, fordi begge tildelerne fortsetter å insistere på samme adresse.

Returveien er et eget problem

Selv med en ren og atskilt pool må LAN-verter vite hvordan de svarer en klient. Standardgatewayen deres er ruteren, og ruteren trenger en rute for poolen som peker på VPN-serveren, med mindre designet oversetter klienttrafikken i stedet.

Les veien i begge retninger før du endrer noe. På gatewayen, spør hvilket grensesnitt kjernen ville brukt for en klientadresse; på klienten, spør hvilken rute den bruker for en LAN-adresse.

Disse kommandoene viser videresendingsbeslutningen på gatewayen og naboinnslagene som avslører en duplikat:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Hvis den første kommandoen svarer med tunellgrensesnittet, finnes returruten. Hvis den svarer med LAN-grensesnittet, tror ruteren at klienten er på ledningen og vil forsøke ARP for den.

Broede design finnes, men de må velges

Å bro en tunnel til LAN-et er et reelt design, brukt når klienter må motta broadcasts eller bli oppdaget av protokoller som forutsetter ett segment. Det krever at serveren eier den broatferden og adressehåndteringen som følger med.

Det som ikke virker, er å etterligne resultatet ved å kopiere numre. En delt pool uten bro gir deg konflikten uten oppdagelsen, som er det verste av begge ordningene.

Velg lag tre med en atskilt pool med mindre applikasjonen virkelig trenger segmentet, og dokumenter poolen slik at neste administrator ikke gjenbruker DHCP-området for ordens skyld.