Ta adresa L2TP je IPCP, ne DHCP lease v síti LAN

Spojení se naváže a adaptér ukazuje adresu z kancelářského rozsahu, takže přirozený závěr je, že vám VPN dala adresu LAN, a tím vás postavila do LAN. Ani jedna z těch dvou polovin není tak docela pravda. L2TP přenáší relaci PPP a PPP vyjednává vnitřní adresu IPv4 pomocí IPCP. Ta adresa je parametr relace dohodnutý mezi dvěma protistranami, ne lease přidělený DHCP serverem kanceláře, a její držení z vás nedělá souseda v kancelářském kabelu.

Dvě adresy v jednom spojení

V jednom spojení L2TP probíhají dvě nezávislá vyjednávání. Vnější vytváří chráněnou cestu mezi vaším zařízením a koncovým bodem VPN přes jakoukoli síť, kterou už máte. Vnitřní je relace PPP a právě v ní se dohodne adresa vaší relace a adresa protistrany. Internetový provoz může odcházet pod úplně třetí adresou, veřejnou adresou koncového bodu, a proto se stránka pro kontrolu VPN a adresa adaptéru málokdy shodují.

Oddělení těchto tří rolí zodpoví většinu otázek, které lidé k této vrstvě přinášejí. Soukromé číslo na rozhraní VPN je normální a očekávané. Neříká nic o tom, zda koncový bod změnil váš veřejný výstup, a samo o sobě nerozhoduje, kterých cílů váš provoz dosáhne.

Co IPCP přesně dělá

IPCP je řídicí protokol IPv4 pro PPP. Každá strana posílá zprávy Configure-Request popisující možnosti, které chce, a možnost adresy je jednou z nich. Klient, který ještě adresu nemá, se obvykle ptá s 0.0.0.0 a server odpoví zprávou Configure-Nak nesoucí adresu, kterou chce, aby klient použil. Klient pak o tuto adresu požádá a relace se naváže s místní a vzdálenou adresou.

Tato výměna je popsána ve specifikacích PPP a IPCP a vysvětluje detail, který vypadá jako chyba: adresu vybírá server podle své vlastní politiky, což může být pool, nastavení pro jednotlivého uživatele nebo adresa vázaná na ověřenou identitu. Když se pool vyčerpá nebo se politika střetne s požadavkem, ověření může uspět, zatímco vyjednávání adresy selže, a klient hlásí spojení, které se nikdy neustálí.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Řádek v logu pppd s místní a vzdálenou adresou je úspěšným koncem tohoto vyjednávání. Jeho nepřítomnost vedle úspěšného ověření ukazuje na fázi adresy, nikoli na přihlašovací údaje.

Proč vám LAN nemůže odpovědět

Adresa z rozsahu vzdálené strany vytváří očekávání, že vás hostitelé v této LAN mohou dosáhnout, a většinou nemohou, pokud server neposílá adresu vaší relace zpět do tunelu. Být uvnitř poolu je tvrzení o přidělování, ne o topologii. Kancelářský souborový server nemá trasu k adrese vaší relace, pokud ji server VPN nepředává, a možná to ani není povoleno, i kdyby ji předával.

Proto také překrývající se rozsahy působí problémy nepřiměřené své zdánlivé velikosti. Pokud se pool překrývá s LAN, kterou klient už používá, má klientská směrovací tabulka nyní dva nároky na stejný prefix a špatný často vyhraje z důvodů, které s tunelem nemají nic společného.

Ověřte relaci, pak trasu

Nejprve zkontrolujte rozhraní, pak trasy, pak jeden cíl, na kterém záleží. Každý krok má svůj vlastní způsob selhání a testování všech tří najednou dává závěr, který později neobhájíte.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Pokud veřejná kontrola ukazuje adresu koncového bodu, zatímco soukromý cíl vyprší, tunel nese vaši výchozí trasu a vzdálená strana na tento cíl neodpovídá. Pokud soukromý cíl odpovídá, ale veřejná kontrola se nemění, profil používá rozdělené tunelování a relaci využívá jen část provozu.

Držte ty tři fáze oddělené

Ověření, vyjednávání adresy a předávání selhávají různě, a každá má jiného vlastníka. Přihlašovací údaje jsou problém identity, vyčerpání IPCP je problém serverové politiky a chybějící zpětná trasa je problém návrhu sítě. Nahlásit všechny tři jako “VPN je rozbitá” zaručí pomalou opravu.

Zapište přidělenou adresu, pool, ze kterého přišla, a zda ji má LAN dosáhnout. Tahle jediná poznámka zabrání dalšímu člověku předpokládat DHCP lease a hledat rozsah, který nikdy nebyl zapojený.