Váš pool adres VPN není rozsah DHCP v síti LAN: proč to nefunguje

Lákavou zkratkou je přidělovat klientům VPN adresy ze stejného rozsahu, který používá kancelářský server DHCP, s domněnkou, že je stejně všechno jedna síť. Není. Směrovaný tunel přenáší unicastové pakety mezi dvěma koncovými body, zatímco pool v LAN existuje proto, aby odpovídal na broadcastové požadavky na fyzickém segmentu. Opětovné použití čísel postaví dva alokátory nad jeden adresní prostor a ponechá zpětnou cestu nedefinovanou.

Dva alokátory, jeden adresní prostor

Server DHCP v LAN ví, které adresy pronajal a jaké MAC adrese, a brání je pomocí ARP. Server VPN má vlastní pool a o těchto pronájmech nic neví. Ani jeden se nemýlí; prostě je nikdy nikdo nepředstavil.

Adresa z poolu LAN, kterou server VPN přidělí, může už patřit tiskárně. Nyní si dva přístroje nárokují jednu adresu na stejném prefixu a tabulka přeposílání přepínače rozhodne, který z nich odpoví.

To je porucha, se kterou se lidé setkávají první: klient, který se úspěšně připojí a pak dosáhne špatného stroje, nebo dosáhne správného stroje přerušovaně.

Proč router nepřiděluje adresy VPN

Zjišťování DHCP je broadcast a broadcasty se zastaví na směrované hranici. Pokud návrh tunel nebridguje nebo neprovozuje DHCP relay s odpovídající pravomocí, požadavek klienta se k serveru v LAN nikdy nedostane.

Server VPN proto adresu přiděluje sám: pool v konfiguraci serveru, adresu pro každého partnera v nastavení WireGuard, nebo adresu, kterou protlačí autentizační vrstva při nasazení IKEv2. Tyto mechanismy jsou nezávislé na databázi pronájmů v LAN, a právě proto potřebují vlastní rozsah.

Stejná logika vysvětluje, proč změna rozsahu DHCP nespraví klienta VPN, který adresu nikdy nedostane. Klient se serveru v LAN neptá a žádné úpravy rozsahu ho k tomu nedonutí.

Překryv se projeví jako konflikt, ne jako pomalá síť

Dvě sítě sdílející prefix bez podporovaného návrhu jsou jiný problém než dvojí vlastnictví a často se pletou. Pokud je pool VPN samostatný prefix, překryv záleží jen tehdy, když směrování pošle provoz na špatnou stranu. Pokud pool leží uvnitř prefixu LAN, konflikt je okamžitý a místní.

V praxi vidíte odpovědi ARP od špatného zařízení, spojení, která se v půlce resetují, a klienta, jehož vlastní adresu si nárokuje někdo jiný. Nic z toho nevypadá jako problém směrování, a proto se oprava aplikuje na špatné vrstvě. Dvojí pronájem lze snadno potvrdit a je otravné s ním žít. Přežije i restart, protože oba alokátory dál trvají na stejné adrese.

Zpětná cesta je samostatný problém

I s čistým a odděleným poolem musí hostitelé v LAN vědět, jak klientovi odpovědět. Jejich výchozí brána je router a router potřebuje trasu pro pool směřující na server VPN, pokud návrh místo toho nepřekládá provoz klienta.

Přečtěte si cestu v obou směrech, než cokoli změníte. Na bráně se zeptejte, které rozhraní by jádro použilo pro adresu klienta; na klientovi se zeptejte, kterou trasu používá pro adresu v LAN.

Tyto příkazy ukazují rozhodnutí o přeposílání na bráně a záznamy sousedů, které odhalí duplikát:

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

Pokud první příkaz odpoví tunelovým rozhraním, zpětná trasa existuje. Pokud odpoví rozhraním LAN, router se domnívá, že klient je na drátě, a zkusí pro něj ARP.

Bridgované návrhy existují, ale musí se vybrat

Bridgování tunelu do LAN je skutečný návrh, používaný tehdy, když klienti musí přijímat broadcasty nebo je musí objevit protokoly, které předpokládají jeden segment. Vyžaduje, aby server vlastnil toto bridgování a s ním spojenou správu adres.

Co nefunguje, je napodobení výsledku kopírováním čísel. Sdílený pool bez bridge vám dá konflikt bez objevování, což je to nejhorší z obou uspořádání.

Zvolte třetí vrstvu s odděleným poolem, pokud aplikace skutečně nepotřebuje segment, a zdokumentujte pool, aby příští správce znovu nepoužil rozsah DHCP jen pro pořádek.