Den L2TP-adressen är IPCP, inte en DHCP-lease på LAN:et

Anslutningen kommer upp och adaptern visar en adress i kontorets intervall, så den naturliga slutsatsen är att VPN:en gav dig en LAN-adress och därmed satte dig på LAN:et. Ingen av de två halvorna är helt rätt. L2TP bär en PPP-session, och PPP förhandlar den inre IPv4-adressen med IPCP. Den adressen är en sessionsparameter som avtalas mellan två parter, inte en lease som kontorets DHCP-server delar ut, och att ha den gör dig inte till granne på kontorets kabel.

Två adresser i en anslutning

Det finns två oberoende förhandlingar i en L2TP-anslutning. Den yttre etablerar en skyddad väg mellan din enhet och VPN-slutpunkten över vilket nätverk du än redan har. Den inre är PPP-sessionen, och det är där din sessionsadress och motpartens adress avtalas. Internettrafik kan gå ut under en helt tredje adress, slutpunktens offentliga adress, och därför stämmer sällan en VPN-kontrollsida och adapterns adress överens.

Att hålla de tre rollerna åtskilda besvarar de flesta frågor folk kommer med på det här lagret. Ett privat nummer på VPN-gränssnittet är normalt och förväntat. Det säger ingenting om huruvida slutpunkten ändrade din offentliga utgång, och det avgör inte i sig vilka destinationer din trafik når.

Vad IPCP faktiskt gör

IPCP är IPv4-kontrollprotokollet för PPP. Varje sida skickar Configure-Request-meddelanden som beskriver de alternativ den vill ha, och adressalternativet är ett av dem. En klient utan adress frågar vanligtvis med 0.0.0.0, och servern svarar med en Configure-Nak som bär den adress den vill att klienten ska använda. Därefter begär klienten den adressen, och sessionen kommer upp med en lokal och en fjärradress.

Det utbytet är dokumenterat i PPP- och IPCP-specifikationerna, och det förklarar en detalj som ser ut som en bugg: adressen väljs av servern enligt dess egen policy, som kan vara en pool, en inställning per användare eller en adress knuten till den autentiserade identiteten. När poolen är slut, eller policyn står i strid med begäran, kan autentiseringen lyckas medan adressförhandlingen misslyckas, och klienten rapporterar en anslutning som aldrig faller till ro.

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

En pppd-loggrad som namnger en lokal och en fjärradress är det lyckade slutet på den förhandlingen. Att den saknas bredvid en lyckad autentisering pekar på adresssteget och inte på inloggningsuppgifterna.

Varför LAN:et inte kan svara dig

En adress från den andra sidans intervall skapar en förväntan att värdar på det LAN:et kan nå dig, och oftast kan de inte, om inte servern routar din sessionsadress tillbaka in i tunneln. Att vara inne i en pool är ett påstående om tilldelning, inte om topologi. Kontorets filserver har ingen rout till din sessionsadress om inte VPN-servern vidarebefordrar den, och det är kanske inte ens tillåtet även om den gör det.

Det är också därför överlappande intervall orsakar problem som är oproportionerliga mot deras skenbara storlek. Om poolen överlappar ett LAN som klienten redan använder har klientens routingtabell nu två anspråk på samma prefix, och det felaktiga vinner ofta av skäl som inte har något med tunneln att göra.

Kontrollera sessionen, sedan routen

Kontrollera gränssnittet först, sedan routarna, sedan en destination som spelar roll. Varje steg har sitt eget felläge, och att testa alla tre samtidigt ger en slutsats du inte kan försvara senare.

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

Om den offentliga kontrollen visar slutpunktens adress medan en privat destination tar timeout, bär tunneln din standardrout och den andra sidan svarar inte för den destinationen. Om den privata destinationen svarar men den offentliga kontrollen inte ändras, använder profilen delad tunnel och bara en del av trafiken använder sessionen.

Håll de tre stegen åtskilda

Autentisering, adressförhandling och vidarebefordran misslyckas på olika sätt, och varje har en egen ägare. Inloggningsuppgifter är ett identitetsproblem, IPCP-utmattning är ett serverpolicyproblem, och en saknad returrout är ett nätverksdesignproblem. Att rapportera alla tre som ”VPN:en är trasig” garanterar en långsam åtgärd.

Notera den tilldelade adressen, poolen den kom från och om LAN:et är tänkt att nå den. Den enda anteckningen hindrar nästa person från att anta en DHCP-lease och leta efter ett intervall som aldrig var inblandat.