Den L2TP-adressen er IPCP, ikke en DHCP-lease på LAN-et

Tilkoblingen kommer opp og adapteren viser en adresse i kontorets område, så den naturlige konklusjonen er at VPN-en ga deg en LAN-adresse og dermed satte deg på LAN-et. Ingen av de to halvdelene er helt riktig. L2TP bærer en PPP-økt, og PPP forhandler den indre IPv4-adressen med IPCP. Den adressen er en øktparameter som avtales mellom to parter, ikke en lease som kontorets DHCP-server deler ut, og å ha den gjør deg ikke til nabo på kontorets ledning.

To adresser i én tilkobling

Det er to uavhengige forhandlinger i en L2TP-tilkobling. Den ytre etablerer en beskyttet vei mellom enheten din og VPN-endepunktet over nettverket du allerede har. Den indre er PPP-økten, og det er der øktadressen din og motpartens adresse avtales. Internett-trafikk kan gå ut under en helt tredje adresse, endepunktets offentlige adresse, og derfor stemmer sjelden en VPN-kontrollside og adapterens adresse overens.

Å holde disse tre rollene fra hverandre besvarer de fleste spørsmålene folk kommer med på dette laget. Et privat nummer på VPN-grensesnittet er normalt og forventet. Det sier ingenting om hvorvidt endepunktet endret den offentlige utgangen din, og det avgjør ikke i seg selv hvilke mål trafikken din når.

Hva IPCP faktisk gjør

IPCP er IPv4-kontrollprotokollen for PPP. Hver side sender Configure-Request-meldinger som beskriver valgene den ønsker, og adressevalget er ett av dem. En klient uten adresse spør vanligvis med 0.0.0.0, og serveren svarer med en Configure-Nak som bærer adressen den vil at klienten skal bruke. Deretter ber klienten om den adressen, og økten kommer opp med en lokal og en ekstern adresse.

Den utvekslingen er dokumentert i PPP- og IPCP-spesifikasjonene, og den forklarer en detalj som ser ut som en feil: adressen velges av serveren etter dens egen policy, som kan være en pool, en innstilling per bruker eller en adresse knyttet til den autentiserte identiteten. Når poolen er tom, eller policyen strider mot forespørselen, kan autentiseringen lykkes mens adresseforhandlingen feiler, og klienten rapporterer en tilkobling som aldri faller til ro.

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

En pppd-loglinje som nevner en lokal og en ekstern adresse, er den vellykkede slutten på den forhandlingen. At den mangler ved siden av en vellykket autentisering, peker på adressetrinnet og ikke på påloggingsinformasjonen.

Hvorfor LAN-et ikke kan svare deg

En adresse fra den fjerne sidens område skaper en forventning om at verter på det LAN-et kan nå deg, og som regel kan de ikke, med mindre serveren ruter øktadressen din tilbake i tunnelen. Å være inne i en pool er en uttalelse om tildeling, ikke om topologi. Kontorets filserver har ingen rute til øktadressen din med mindre VPN-serveren videresender den, og det er kanskje ikke engang tillatt selv om den gjør det.

Det er også derfor overlappende områder skaper problemer som er ute av proporsjon med den tilsynelatende størrelsen. Hvis poolen overlapper et LAN som klienten allerede bruker, har klientens rutetabell nå to krav på samme prefiks, og det feilaktige vinner ofte av grunner som ikke har noe med tunnelen å gjøre.

Kontroller økten, deretter ruten

Kontroller grensesnittet først, deretter rutene, deretter ett mål som betyr noe. Hvert trinn har sin egen feilmodus, og å teste alle tre samtidig gir en konklusjon du ikke kan forsvare senere.

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

Hvis den offentlige kontrollen viser endepunktets adresse mens et privat mål går ut på tid, bærer tunnelen standardruten din, og den fjerne siden svarer ikke for det målet. Hvis det private målet svarer, men den offentlige kontrollen ikke endres, bruker profilen delt tunnelering, og bare en del av trafikken bruker økten.

Hold de tre trinnene fra hverandre

Autentisering, adresseforhandling og videresending feiler på ulike måter, og hver har en forskjellig eier. Påloggingsinformasjon er et identitetsproblem, IPCP-utmattelse er et serverpolicyproblem, og en manglende returrute er et nettverksdesignproblem. Å rapportere alle tre som «VPN-en er ødelagt» garanterer en langsom rettelse.

Noter den tildelte adressen, poolen den kom fra, og om LAN-et er ment å nå den. Det ene notatet hindrer neste person i å anta en DHCP-lease og lete etter et område som aldri var involvert.