Daardie L2TP-adres is IPCP, nie ’n DHCP-leas op die LAN nie

Die verbinding kom op en die adapter wys ’n adres in die kantoor se reeks, so die natuurlike gevolgtrekking is dat die VPN vir jou ’n LAN-adres gegee het en jou dus op die LAN gesit het. Nie een van die twee helftes is heeltemal reg nie. L2TP dra ’n PPP-sessie, en PPP onderhandel die binne-IPv4-adres met IPCP. Daardie adres is ’n sessieparameter wat tussen twee eweknieë ooreengekom word, nie ’n leas wat die kantoor se DHCP-bediener uitdeel nie, en om dit te hou maak jou nie ’n buur op die kantoor se draad nie.

Twee adresse in een verbinding

Daar is twee onafhanklike onderhandelinge in ’n L2TP-verbinding. Die buitenste een vestig ’n beskermde pad tussen jou toestel en die VPN-eindpunt oor watter netwerk jy ook al het. Die binneste een is die PPP-sessie, en dit is waar jou sessie-adres en die eweknie se adres ooreengekom word. Internetverkeer kan heeltemal onder ’n derde adres uitgaan, die eindpunt se openbare adres, en daarom stem ’n VPN-kontrolebladsy en die adapter se adres selde ooreen.

Om daardie drie rolle apart te hou, beantwoord die meeste vrae wat mense na hierdie laag bring. ’n Privaat nommer op die VPN-koppelvlak is normaal en verwag. Dit sê niks oor of die eindpunt jou openbare uitgang verander het nie, en dit bepaal nie op sigself watter bestemmings jou verkeer bereik nie.

Wat IPCP presies doen

IPCP is die IPv4-beheerprotokol vir PPP. Elke kant stuur Configure-Request-boodskappe wat die opsies beskryf wat hy wil hê, en die adresopsie is een van hulle. ’n Kliënt wat nog geen adres het nie, vra gewoonlik met 0.0.0.0, en die bediener antwoord met ’n Configure-Nak wat die adres dra wat hy wil hê die kliënt moet gebruik. Die kliënt vra dan daardie adres aan, en die sessie kom op met ’n plaaslike en ’n afgeleë adres.

Daardie uitruiling word in die PPP- en IPCP-spesifikasies gedokumenteer, en dit verduidelik ’n detail wat soos ’n fout lyk: die adres word deur die bediener uit sy eie beleid gekies, wat ’n poel, ’n instelling per gebruiker of ’n adres wat aan die geauthentiseerde identiteit gekoppel is, kan wees. Wanneer die poel uitgeput is, of die beleid met die versoek bots, kan verifikasie slaag terwyl adresonderhandeling misluk, en die kliënt rapporteer ’n verbinding wat nooit tot rus kom nie.

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

’n pppd-logreël wat ’n plaaslike en ’n afgeleë adres noem, is die suksesvolle einde van daardie onderhandeling. Die afwesigheid daarvan, langs ’n suksesvolle verifikasie, wys na die adresstadium eerder as na geloofsbriewe.

Waarom die LAN nie vir jou kan antwoord nie

’n Adres uit die verre kant se reeks skep die verwagting dat gashere op daardie LAN jou kan bereik, en meestal kan hulle nie, tensy die bediener jou sessie-adres terug in die tonnel instuur. Om binne ’n poel te wees, is ’n stelling oor toekenning, nie oor topologie nie. Die kantoor se lêerbediener het geen roete na jou sessie-adres nie, tensy die VPN-bediener dit aanstuur, en dit mag dalk nie toegelaat word nie, selfs al doen hy dit.

Dit is ook waarom oorvleuelende reekse probleme veroorsaak wat buite verhouding tot hul oënskynlike grootte is. As die poel oorvleuel met ’n LAN wat die kliënt al gebruik, het die kliënt se roetertabel nou twee aansprake op dieselfde voorvoegsel, en die verkeerde een wen dikwels om redes wat niks met die tonnel te doen het nie.

Verifieer die sessie, dan die roete

Kontroleer eers die koppelvlak, dan die roetes, dan een bestemming wat saak maak. Elke stap het sy eie foutmodus, en om al drie gelyk te toets lewer ’n gevolgtrekking wat jy later nie kan verdedig nie.

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

As die openbare kontrole die eindpunt se adres wys terwyl ’n private bestemming uittyd, dra die tonnel jou verstekroete en antwoord die verre kant nie vir daardie bestemming nie. As die private bestemming antwoord maar die openbare kontrole verander nie, is die profiel aan gesplete tonneling, en net sommige verkeer gebruik die sessie.

Hou die drie stadiums apart

Verifikasie, adresonderhandeling en aanstuur misluk verskillend, en elkeen het ’n ander eienaar. Geloofsbriewe is ’n identiteitsprobleem, IPCP-uitputting is ’n bedienerbeleidsprobleem, en ’n ontbrekende terugroete is ’n netwerkontwerp-probleem. Om al drie as “die VPN is stukkend” aan te meld, waarborg ’n stadige oplossing.

Teken die toegewysde adres aan, die poel waaruit dit gekom het en of die LAN veronderstel is om dit te bereik. Daardie enkele aantekening verhoed die volgende persoon om ’n DHCP-leas te veronderstel en te soek na ’n bereik wat nooit betrokke was nie.