Din VPN-pulje er ikke LAN'ets DHCP-område: hvorfor det brækker

Den fristende genvej er at give VPN-klienter adresser fra det samme område, som kontorets DHCP-server bruger, ud fra teorien om, at alt alligevel er ét netværk. Det er det ikke. En dirigeret tunnel transporterer unicast-pakker mellem to endepunkter, mens LAN-puljen findes for at besvare broadcast-forespørgsler på et fysisk segment. Genbrug af numrene sætter to tildelere i ansvaret for ét adresserum og efterlader returvejen udefineret.

To tildelere, ét adresserum

LAN'ets DHCP-server ved, hvilke adresser den har udlejet og til hvilken MAC-adresse, og den forsvarer dem med ARP. VPN-serveren har sin egen pulje og ved intet om disse lejemål. Ingen af dem tager fejl; de er bare aldrig blevet præsenteret for hinanden.

En adresse fra LAN-puljen, som VPN-serveren uddeler, kan allerede tilhøre en printer. Nu kræver to enheder én adresse på samme præfiks, og switchens videresendingstabel afgør, hvilken der svarer.

Det er den fejl, folk møder først: en klient, der forbinder fint og derefter når den forkerte maskine, eller når den rigtige af og til.

Hvorfor routeren ikke uddeler VPN-adresser

DHCP-opdagelse er en broadcast, og broadcasts stopper ved en dirigeret grænse. Medmindre designet broer tunnelen eller kører en DHCP-relay med tilsvarende beføjelse, når klientens anmodning aldrig LAN-serveren.

Derfor tildeler VPN-serveren selv adressen: en pulje i serverkonfigurationen, en adresse pr. peer i en WireGuard-opsætning, eller en adresse, der skubbes af godkendelseslaget i en IKEv2-udrulning. Disse mekanismer er uafhængige af LAN'ets lejemålsdatabase, og det er netop derfor, de har brug for deres eget område.

Samme ræsonnement forklarer, hvorfor ændring af DHCP-området ikke retter en VPN-klient, der aldrig får en adresse. Klienten spørger ikke LAN-serveren, og ingen redigering af området får den til at spørge.

Overlapningen viser sig som en konflikt, ikke som et langsomt netværk

To netværk, der deler et præfiks uden et understøttet design, er et andet problem end dobbelt ejerskab, og de forveksles ofte. Hvis VPN-puljen er et separat præfiks, betyder overlapning kun noget, når en rute sender trafik til den forkerte side. Hvis puljen ligger inde i LAN-præfikset, er konflikten øjeblikkelig og lokal.

I praksis ser man ARP-svar fra den forkerte enhed, forbindelser der nulstilles halvvejs, og en klient, hvis egen adresse kræves af en anden. Intet af det ligner et routingproblem, og derfor bliver rettelsen lagt på det forkerte lag. Et dobbelt lejemål er let at bekræfte og irriterende at leve med. Det overlever også genstarter, fordi begge tildelere bliver ved med at insistere på samme adresse.

Returvejen er et separat problem

Selv med en ren, adskilt pulje skal LAN-værter vide, hvordan de svarer en klient. Deres standardgateway er routeren, og routeren har brug for en rute til puljen, der peger på VPN-serveren, medmindre designet oversætter klienttrafik i stedet.

Læs vejen i begge retninger, før du ændrer noget. På gatewayen, spørg hvilken grænseflade kernen ville bruge til en klientadresse; på klienten, spørg hvilken rute den bruger til en LAN-adresse.

Disse kommandoer viser videresendelsesbeslutningen på gatewayen og naboindgangene, der afslører en dublet:

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

Svarer den første kommando med tunnelgrænsefladen, findes returruten. Svarer den med LAN-grænsefladen, mener routeren, at klienten er på ledningen, og vil forsøge ARP for den.

Broede designs findes, men de skal vælges

At bro en tunnel til LAN'et er et rigtigt design, brugt når klienter skal modtage broadcasts eller opdages af protokoller, der antager ét segment. Det kræver, at serveren ejer den bro-adfærd og den adressehåndtering, der følger med.

Det, der ikke virker, er at efterligne resultatet ved at kopiere numre. En delt pulje uden bro giver dig konflikten uden opdagelsen, hvilket er det værste af begge arrangementer.

Vælg lag tre med en adskilt pulje, medmindre applikationen virkelig har brug for segmentet, og dokumentér puljen, så den næste administrator ikke genbruger DHCP-området for ordenens skyld.