Dat L2TP-adres is IPCP, geen DHCP-lease op de LAN

De verbinding komt op en de adapter toont een adres binnen het bereik van kantoor, dus de natuurlijke conclusie is dat de VPN je een LAN-adres gaf en je daarmee op de LAN zette. Geen van beide helften klopt helemaal. L2TP draagt een PPP-sessie, en PPP onderhandelt het interne IPv4-adres met IPCP. Dat adres is een sessieparameter die tussen twee partijen wordt afgesproken, geen lease die de DHCP-server van kantoor uitgeeft, en het hebben ervan maakt je geen buur op de kabel van kantoor.

Twee adressen in één verbinding

Er zijn twee onafhankelijke onderhandelingen in een L2TP-verbinding. De buitenste legt een beschermd pad aan tussen je apparaat en het VPN-eindpunt over welk netwerk je al hebt dan ook. De binnenste is de PPP-sessie, en daar worden je sessieadres en het adres van de andere kant afgesproken. Internetverkeer kan volledig onder een derde adres naar buiten gaan, het openbare adres van het eindpunt, en daarom komen een VPN-controlepagina en het adapteradres zelden overeen.

Die drie rollen gescheiden houden beantwoordt de meeste vragen die mensen naar deze laag brengen. Een privénummer op de VPN-interface is normaal en verwacht. Het zegt niets over of het eindpunt je openbare uitgang heeft veranderd, en het beslist op zichzelf niet welke bestemmingen je verkeer bereikt.

Wat IPCP precies doet

IPCP is het IPv4-besturingsprotocol voor PPP. Elke kant stuurt Configure-Request-berichten die de gewenste opties beschrijven, en de adresoptie is er daar één van. Een client zonder adres vraagt meestal met 0.0.0.0, en de server antwoordt met een Configure-Nak die het adres draagt dat de client moet gebruiken. Daarna vraagt de client dat adres aan, en de sessie komt op met een lokaal en een extern adres.

Die uitwisseling is gedocumenteerd in de PPP- en IPCP-specificaties, en ze verklaart een detail dat op een bug lijkt: het adres wordt door de server gekozen volgens zijn eigen beleid, dat een pool, een instelling per gebruiker of een adres gekoppeld aan de geauthenticeerde identiteit kan zijn. Wanneer de pool uitgeput is, of het beleid met het verzoek botst, kan de authenticatie slagen terwijl de adresonderhandeling mislukt, en de client meldt een verbinding die nooit tot rust komt.

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

Een pppd-logregel die een lokaal en een extern adres noemt, is het succesvolle einde van die onderhandeling. Het ontbreken daarvan, naast een geslaagde authenticatie, wijst op de adresfase en niet op de inloggegevens.

Waarom de LAN je niet kan antwoorden

Een adres uit het bereik van de andere kant schept de verwachting dat hosts op die LAN je kunnen bereiken, en meestal kunnen ze dat niet, tenzij de server je sessieadres terug de tunnel in routeert. Binnen een pool zitten is een uitspraak over toewijzing, niet over topologie. De bestandsserver van kantoor heeft geen route naar je sessieadres tenzij de VPN-server het doorstuurt, en het is misschien niet eens toegestaan ook al doet hij het.

Daarom veroorzaken overlappende bereiken problemen die buiten verhouding staan tot hun schijnbare grootte. Als de pool overlapt met een LAN die de client al gebruikt, heeft de routetabel van de client nu twee claims op hetzelfde prefix, en de verkeerde wint vaak om redenen die niets met de tunnel te maken hebben.

Controleer de sessie en dan de route

Controleer eerst de interface, dan de routes, dan één bestemming die ertoe doet. Elke stap heeft zijn eigen faalmodus, en alle drie tegelijk testen levert een conclusie op die je later niet kunt verdedigen.

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

Als de openbare controle het adres van het eindpunt toont terwijl een privébestemming een time-out geeft, draagt de tunnel je standaardroute en antwoordt de andere kant niet voor die bestemming. Als de privébestemming antwoordt maar de openbare controle niet verandert, gebruikt het profiel split-tunneling en gebruikt slechts een deel van het verkeer de sessie.

Houd de drie stappen gescheiden

Authenticatie, adresonderhandeling en doorsturen falen op verschillende manieren, en elk heeft een andere eigenaar. Inloggegevens zijn een identiteitsprobleem, IPCP-uitputting is een probleem van serverbeleid, en een ontbrekende retourroute is een probleem van netwerkontwerp. Alle drie melden als „de VPN is kapot” garandeert een trage oplossing.

Noteer het toegewezen adres, de pool waar het vandaan kwam en of de LAN het hoort te bereiken. Die ene notitie voorkomt dat de volgende persoon een DHCP-lease aanneemt en zoekt naar een bereik dat er nooit bij betrokken was.