Den L2TP-adressa er IPCP, ikkje ein DHCP-leige på LAN-et

Tilkoplinga kjem opp og adapteren viser ei adresse i området til kontoret, så den naturlege konklusjonen er at VPN-en gav deg ei LAN-adresse og dermed sette deg på LAN-et. Ingen av dei to halvdelane er heilt riktig. L2TP ber ei PPP-økt, og PPP forhandlar den indre IPv4-adressa med IPCP. Den adressa er ein øktparameter som blir avtalt mellom to partar, ikkje ei leige som DHCP-tenaren på kontoret deler ut, og å ha henne gjer deg ikkje til nabo på leidninga på kontoret.

To adresser i éi tilkopling

Det er to uavhengige forhandlingar i ei L2TP-tilkopling. Den ytre etablerer ein verna veg mellom eininga di og VPN-endepunktet over nettverket du allereie har. Den indre er PPP-økta, og det er der øktadressa di og adressa til motparten blir avtalte. Internett-trafikk kan gå ut under ei heilt tredje adresse, den offentlege adressa til endepunktet, og derfor stemmer sjeldan ei VPN-kontrollside og adressa til adapteren overeins.

Å halde desse tre rollene frå kvarandre svarer på dei fleste spørsmåla folk kjem med på dette laget. Eit privat nummer på VPN-grensesnittet er normalt og forventa. Det seier ingenting om endepunktet endra den offentlege utgangen din, og det avgjer ikkje i seg sjølv kva mål trafikken din når.

Kva IPCP faktisk gjer

IPCP er IPv4-kontrollprotokollen for PPP. Kvar side sender Configure-Request-meldingar som skildrar vala ho ønskjer, og adressevalet er eitt av dei. Ein klient utan adresse spør vanlegvis med 0.0.0.0, og tenaren svarar med ein Configure-Nak som ber adressa han vil at klienten skal bruke. Deretter ber klienten om den adressa, og økta kjem opp med ei lokal og ei ekstern adresse.

Den utvekslinga er dokumentert i PPP- og IPCP-spesifikasjonane, og ho forklarer ein detalj som ser ut som ein feil: adressa blir vald av tenaren etter hans eigen politikk, som kan vere ein pool, ei innstilling per brukar eller ei adresse knytt til den autentiserte identiteten. Når poolen er tom, eller politikken strir mot førespurnaden, kan autentiseringa lukkast medan adresseforhandlinga feilar, og klienten rapporterer ei tilkopling som aldri fell til ro.

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

Ei pppd-logline som nemner ei lokal og ei ekstern adresse, er den vellukka slutten på den forhandlinga. At ho manglar ved sida av ei vellukka autentisering, peikar på adressetrinnet og ikkje på påloggingsinformasjonen.

Kvifor LAN-et ikkje kan svare deg

Ei adresse frå området til den fjerne sida skaper ei forventning om at vertar på det LAN-et kan nå deg, og som regel kan dei ikkje, med mindre tenaren ruter øktadressa di tilbake i tunnelen. Å vere inne i ein pool er ei utsegn om tildeling, ikkje om topologi. Filtenaren på kontoret har inga rute til øktadressa di med mindre VPN-tenaren sender henne vidare, og det er kanskje ikkje ein gong tillate sjølv om han gjer det.

Det er også derfor overlappande område skaper problem som er ute av proporsjon med den tilsynelatande storleiken. Viss poolen overlappar eit LAN som klienten allereie brukar, har rutetabellen til klienten no to krav på same prefiks, og det feilaktige vinn ofte av grunnar som ikkje har noko med tunnelen å gjere.

Kontroller økta, deretter ruta

Kontroller grensesnittet først, deretter rutene, deretter eitt mål som betyr noko. Kvart trinn har sin eigen feilmodus, og å teste alle tre samstundes gir ein konklusjon du ikkje kan forsvare seinare.

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

Viss den offentlege kontrollen viser adressa til endepunktet medan eit privat mål går ut på tid, ber tunnelen standardruta di, og den fjerne sida svarar ikkje for det målet. Viss det private målet svarar, men den offentlege kontrollen ikkje endrar seg, brukar profilen delt tunnelering, og berre ein del av trafikken brukar økta.

Hald dei tre trinna frå kvarandre

Autentisering, adresseforhandling og videresending feilar på ulike måtar, og kvar har ein forskjellig eigar. Påloggingsinformasjon er eit identitetsproblem, IPCP-utmattning er eit tenarpolitikkproblem, og ei manglande returrute er eit nettverksdesignproblem. Å rapportere alle tre som «VPN-en er øydelagd» garanterer ei sein retting.

Noter den tildelte adressa, poolen ho kom frå, og om LAN-et er meint å nå henne. Den eine notata hindrar neste person i å anta ei DHCP-leige og leite etter eit område som aldri var involvert.