VPN-poolen din er ikkje DHCP-området til LAN-et: difor knekk det

Den freistande snarvvegen er å gje VPN-klientar adresser frå same område som DHCP-tenaren på kontoret brukar, ut frå teorien om at alt trass alt er eitt nett. Det er det ikkje. Ein ruta tunnel fraktar unicast-pakkar mellom to endepunkt, medan LAN-poolen finst for å svare på broadcast-førespurnader på eit fysisk segment. Å bruke nummera om att set to tildelarar ansvarlege for eitt adresserom og lèt returvegen stå udefinert.

To tildelarar, eitt adresserom

DHCP-tenaren i LAN-et veit kva adresser han har leigt ut og til kva MAC-adresse, og forsvarar dei med ARP. VPN-tenaren har sin eigen pool og veit ingenting om desse leigeforholda. Ingen av dei tek feil; dei vart berre aldri presenterte for kvarandre.

Ei adresse frå LAN-poolen som VPN-tenaren deler ut, kan alt vere til ein skrivar. No krev to einingar éi adresse på same prefiks, og videresendingstabellen til switsjen avgjer kven som svarar.

Det er feilen folk møter fyrst: ein klient som koplar til med hell og deretter når feil maskin, eller når den rette med mellomrom.

Kvifor ruteren ikkje deler ut VPN-adresser

DHCP-oppdaging er ein broadcast, og broadcastar stoppar ved ei ruta grense. Med mindre designet bruar tunnelen eller køyrer ein DHCP-relay med tilsvarande myndigheit, når førespurnaden til klienten aldri LAN-tenaren.

Difor tildeler VPN-tenaren adressa sjølv: ein pool i tenarkonfigurasjonen, éi adresse per peer i eit WireGuard-oppsett, eller ei adresse som autentiseringslaget skyt gjennom i ein IKEv2-utrulling. Desse mekanismane er uavhengige av leigedatabasen til LAN-et, og det er nettopp difor dei treng eige område.

Same resonnementet forklarar kvifor endring av DHCP-området ikkje reparerer ein VPN-klient som aldri får ei adresse. Klienten spør ikkje LAN-tenaren, og inga redigering av området får han til å spørje.

Overlappen syner seg som ein konflikt, ikkje som eit tregt nett

To nett som deler eit prefiks utan eit støtta design er eit anna problem enn dobbelt eigarskap, og dei vert ofte forveksla. Viss VPN-poolen er eit eige prefiks, betyr overlap noko berre når ei rute sender trafikk til feil side. Viss poolen ligg inne i LAN-prefikset, er konflikten umiddelbar og lokal.

I praksis ser du ARP-svar frå feil eining, tilkoplingar som nullstiller halvvegs, og ein klient der nokon andre krev den eigne adressa hans. Ingenting av dette ser ut som eit ruteproblem, og difor vert rettinga sett inn på feil lag. Ein dobbel lease er lett å stadfeste og irriterande å leve med. Han overlever også omstartar, fordi begge tildelarane held fram med å insistere på same adresse.

Returvegen er eit eige problem

Sjølv med ein rein og skild pool må LAN-vertar vite korleis dei svarar ein klient. Standardgatewayen deira er ruteren, og ruteren treng ei rute for poolen som peikar på VPN-tenaren, med mindre designet omset klienttrafikken i staden.

Les vegen i båe retningar før du endrar noko. På gatewayen, spør kva grensesnitt kjernen ville bruke for ei klientadresse; på klienten, spør kva rute han brukar for ei LAN-adresse.

Desse kommandoane syner videresendingsavgjerda på gatewayen og naboinnslaga som avdekkjer ein 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

Viss den fyrste kommandoen svarar med tunellgrensesnittet, finst returruta. Viss han svarar med LAN-grensesnittet, trur ruteren at klienten er på leidninga og vil freiste ARP for han.

Brua design finst, men dei må veljast

Å brua ein tunnel til LAN-et er eit reelt design, brukt når klientar må ta imot broadcastar eller verta oppdaga av protokollar som føreset eitt segment. Det krev at tenaren eig den bru-åtferda og adressehandteringa som følgjer med.

Det som ikkje verkar, er å etterlikne resultatet ved å kopiere nummer. Ein delt pool utan bru gjev deg konflikten utan oppdaginga, som er det verste av båe ordningane.

Vel lag tre med ein skild pool med mindre applikasjonen verkeleg treng segmentet, og dokumenter poolen slik at neste administrator ikkje brukar DHCP-området om att for ordens skuld.