Vaš VPN pool nije LAN DHCP raspon: zašto se to lomi

Mamac za prečicu je davati VPN klijentima adrese iz istog raspona koji koristi uredski DHCP server, uz tezu da je ionako sve jedna mreža. Nije. Rutirani tunel prenosi unicast pakete između dvije krajnje točke, dok LAN pool postoji da odgovara na broadcast zahtjeve na fizičkom segmentu. Ponovno korištenje brojeva stavlja dva alokatora zadužena za jedan adresni prostor i ostavlja povratni put nedefiniranim.

Dva alokatora, jedan adresni prostor

LAN DHCP server zna koje je adrese iznajmio i kojem MAC naslovu, i brani ih pomoću ARP-a. VPN server ima vlastiti pool i ne zna ništa o tim najmovima. Nijedan nije u krivu; nikad nisu bili predstavljeni.

Adresa iz LAN poola koju VPN server dodijeli možda već pripada pisaču. Sada dva uređaja traže jednu adresu na istom prefiksu, a switch-ev forwarding table odlučuje koji će odgovoriti.

To je kvar s kojim se ljudi prvi susreću: klijent koji se uspješno poveže i zatim dođe do pogrešnog stroja, ili do pravog dolazi s prekidima.

Zašto router ne dodjeljuje VPN adrese

DHCP otkrivanje je broadcast, a broadcast se zaustavlja na rutiranoj granici. Ako dizajn ne premošćuje tunel ili ne pokreće DHCP relay s odgovarajućim ovlastima, klijentov zahtjev nikada ne stigne do LAN servera.

Zato VPN server sam dodjeljuje adresu: pool u konfiguraciji servera, adresu po peeru u WireGuard postavci, ili adresu koju gura sloj autentifikacije u IKEv2 implementaciji. Ti su mehanizmi neovisni od LAN baze najma, i upravo zato im treba vlastiti raspon.

Ista logika objašnjava zašto promjena DHCP opsega ne popravlja VPN klijent koji nikad ne dobije adresu. Klijent ne pita LAN server, i nikakvo uređivanje opsega neće ga natjerati da pita.

Preklapanje se pojavljuje kao sukob, ne kao spora mreža

Dvije mreže koje dijele prefiks bez podržanog dizajna drugi su problem od dvostrukog vlasništva, i često se miješaju. Ako je VPN pool zaseban prefiks, preklapanje je važno samo kad ruta pošalje promet na pogrešnu stranu. Ako pool sjedi unutar LAN prefiksa, sukob je trenutan i lokalan.

U praksi vidite ARP odgovore s pogrešnog uređaja, veze koje se resetiraju na pola, i klijenta čiju vlastitu adresu traži netko drugi. Ništa od toga ne izgleda kao problem rutiranja, zato se popravak primjenjuje na pogrešnom sloju. Dvostruki najam lako je potvrditi i nezgodno trpjeti. Preživljava i restarte, jer oba alokatora i dalje inzistiraju na istoj adresi.

Povratni put je zaseban problem

Čak i s čistim, zasebnim poolom, LAN hostovi moraju znati kako odgovoriti klijentu. Njihov zadani gateway je router, a routeru treba ruta za pool prema VPN serveru, osim ako dizajn prevodi promet klijenta.

Pročitajte put u oba smjera prije nego što bilo što promijenite. Na gatewayu pitajte koje bi sučelje kernel koristio za adresu klijenta; na klijentu pitajte koju rutu koristi za LAN adresu.

Ove naredbe pokazuju odluku prosljeđivanja na gatewayu i susjedne unose koji otkrivaju 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

Ako prva naredba odgovori tunelskim sučeljem, povratna ruta postoji. Ako odgovori LAN sučeljem, router vjeruje da je klijent na žici i pokušat će ARP za njega.

Premošteni dizajni postoje, ali moraju se odabrati

Premošćivanje tunela na LAN stvaran je dizajn, korišten kad klijenti moraju primati broadcast ili ih moraju otkriti protokoli koji pretpostavljaju jedan segment. Zahtijeva da server posjeduje to ponašanje premošćivanja i rukovanje adresama koje ide s njim.

Ono što ne radi je oponašanje rezultata kopiranjem brojeva. Zajednički pool bez mosta daje vam sukob bez otkrivanja, što je najgore od oba rasporeda.

Odaberite treći sloj sa zasebnim poolom, osim ako aplikaciji stvarno treba segment, i dokumentirajte pool da sljedeći administrator ne iskoristi DHCP raspon ponovno radi urednosti.