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

Forbindelsen kommer op, og adapteren viser en adresse i kontorets område, så den naturlige konklusion er, at VPN gav dig en LAN-adresse og dermed satte dig på LAN. Ingen af de to halvdele er helt rigtig. L2TP bærer en PPP-session, og PPP forhandler den indre IPv4-adresse med IPCP. Den adresse er en sessionsparameter, der aftales mellem to parter, ikke en lease udstedt af kontorets DHCP-server, og at holde den gør dig ikke til nabo på kontorets ledning.

To adresser i én forbindelse

Der er to uafhængige forhandlinger i en L2TP-forbindelse. Den ydre etablerer en beskyttet vej mellem din enhed og VPN-endepunktet over det netværk, du nu har. Den indre er PPP-sessionen, og det er der, din sessionsadresse og modpartens adresse aftales. Internettrafik kan helt forlade under en tredje adresse, endepunktets offentlige adresse, og derfor stemmer en VPN-kontrolside og adapterens adresse sjældent overens.

At holde de tre roller adskilt besvarer de fleste af de spørgsmål, folk bringer til dette lag. Et privat nummer på VPN-interfacet er normalt og forventeligt. Det siger intet om, hvorvidt endepunktet ændrede din offentlige udgang, og det afgør ikke i sig selv, hvilke destinationer din trafik når.

Hvad IPCP præcis gør

IPCP er IPv4-kontrolprotokollen til PPP. Hver side sender Configure-Request-beskeder, der beskriver de muligheder, den ønsker, og adressemuligheden er en af dem. En klient uden adresse endnu spørger typisk med 0.0.0.0, og serveren svarer med en Configure-Nak, der bærer den adresse, den vil have klienten til at bruge. Derefter anmoder klienten om den adresse, og sessionen kommer op med en lokal og en fjern adresse.

Den udveksling er dokumenteret i PPP- og IPCP-specifikationerne, og den forklarer en detalje, der ser ud som en fejl: adressen vælges af serveren efter dens egen politik, som kan være en pulje, en indstilling pr. bruger eller en adresse knyttet til den godkendte identitet. Når puljen er opbrugt, eller politikken strider mod anmodningen, kan godkendelsen lykkes, mens adresseforhandlingen fejler, og klienten rapporterer en forbindelse, der aldrig falder til ro.

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

En pppd-loglinje, der nævner en lokal og en fjern adresse, er den vellykkede afslutning på den forhandling. Dens fravær ved siden af en vellykket godkendelse peger på adressetrinnet frem for på legitimationsoplysningerne.

Hvorfor LAN ikke kan svare dig

En adresse fra den fjerne sides område skaber en forventning om, at værter på det LAN kan nå dig, og det kan de oftest ikke, medmindre serveren ruter din sessionsadresse tilbage i tunnelen. At være inde i en pulje er en udtalelse om tildeling, ikke om topologi. Kontorets filserver har ingen rute til din sessionsadresse, medmindre VPN-serveren videresender den, og det er måske ikke engang tilladt, selv om den gør.

Det er også derfor overlappende områder skaber problemer, der er ude af proportion med deres tilsyneladende størrelse. Hvis puljen overlapper et LAN, som klienten allerede bruger, har klientens rutetabel nu to krav på samme præfiks, og det forkerte vinder ofte af grunde, der intet har med tunnelen at gøre.

Kontrollér sessionen, derefter ruten

Kontrollér først interfacet, derefter ruterne, derefter én destination, der betyder noget. Hvert trin har sin egen fejltilstand, og test af alle tre på én gang giver en konklusion, 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 kontrol viser endepunktets adresse, mens en privat destination løber tør for tid, bærer tunnelen din standardrute, og den fjerne side svarer ikke for den destination. Hvis den private destination svarer, men den offentlige kontrol ikke ændrer sig, kører profilen med split-tunneling, og kun en del af trafikken bruger sessionen.

Hold de tre trin adskilt

Godkendelse, adresseforhandling og videresendelse fejler forskelligt, og hver har en forskellig ejer. Legitimationsoplysninger er et identitetsproblem, IPCP-udtømning er et serverpolitikproblem, og en manglende returrute er et netværksdesignproblem. At rapportere alle tre som “VPN’en er i stykker” garanterer en langsom rettelse.

Notér den tildelte adresse, den pulje, den kom fra, og om LAN er ment at nå den. Den ene note forhindrer den næste person i at antage en DHCP-lease og lede efter et område, der aldrig var involveret.