L2TP verbindt, maar de PPP-onderhandeling mislukt: welke fase?

De IPsec-tunnel komt tot stand, de client toont een beschermde peer en dan sterft de verbinding voordat er iets het private subnet bereikt. Die leemte is PPP dat zijn eigen werk doet: linkopties, gebruikersauthenticatie en adres toewijzen gebeuren allemaal nadat de versleutelde tunnel bestaat. Niets aan een geslaagde eerste-fase-uitwisseling levert een wachtwoord of een intern adres. Lees de fasen op volgorde en de fout benoemt zich meestal zelf.

De tunnel is alleen de eerste laag

L2TP draagt PPP-frames in een door IPsec beschermde tunnel, wat betekent dat twee onafhankelijke onderhandelingen moeten slagen voordat een pakket kan worden gerouteerd. De buitenste bewijst dat beide uiteinden het eens zijn over sleutels en identiteiten. De binnenste bepaalt de linkparameters, of de gebruiker zich authenticeert en welk adres de client krijgt.

Een fout binnen PPP ziet er in elke client die maar één statuslampje toont uit als een kapotte tunnel. Wie het als tunnelprobleem behandelt, komt uit bij het opnieuw genereren van sleutels, het herstarten van diensten en uiteindelijk het vervangen van een gedeeld geheim dat nooit fout was. Het nuttige onderscheid is goedkoop: als de uitwisseling met de peer is voltooid en de client doorging naar een gebruikersnaamvraag of een authenticatiefase, is de tunnel in orde. Alles na dat punt hoort bij PPP.

Lees de laatste fase die slaagde

Loop de log vooruit door en stop bij de eerste fase die niet werd voltooid. Eerst komt LCP, dan authenticatie, dan IPCP voor de IPv4-parameters.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Een LCP-time-out betekent dat de twee uiteinden het nooit eens zijn geworden over de basislinkopties, wat een niet-passend profiel of een geblokkeerd innerlijk protocol is en geen slecht wachtwoord. Een uitdrukkelijke authenticatie-afwijzing is het omgekeerde geval: de link kwam op en één kant weigerde de inloggegevens. Een IPCP-time-out na geslaagde authenticatie wijst op adrespoelen of serverbeleid. Elk daarvan heeft een andere eigenaar en een andere reparatie, daarom is de fase belangrijker dan de uiteindelijke fouttekst.

Bewaar het logfragment samen met de fasenaam in het ticket. Een geplakte staart zonder de fasegrens nodigt de volgende lezer uit tot gissen, en gissen kost hier een uur.

Overeenstemming tussen de client en de server

Beide uiteinden moeten dezelfde authenticatiemethode accepteren, en een opgeslagen profiel kan er een vragen die de server vorig kwartaal heeft afgeschaft. Beheerde uitrollen verbergen ook de serverkant, waar de reden van afwijzing meestal op de gebruiker wordt vastgelegd en niet op het apparaat.

Schakel één ondersteunde methode in in plaats van elke oude optie, want een client die vijf methoden aanbiedt, verbergt welke heeft gefaald. Vraag de beheerder om het beleid aan serverkant en de exacte afwijzing, wat niet vereist dat iemand een wachtwoord publiceert. Een oude methode die wordt ingeschakeld om één client te redden, verspreidt zich graag naar elk profiel dat het bestand kopieert.

Controleer het adres, niet de aanmelding

Een voltooide aanmelding is geen bruikbare sessie. IPCP onderhandelt het interne adres, en een uitgeputte poel of een beleid dat de client weigert kan nog steeds een verbonden tunnel achterlaten zonder iets om te routeren.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Controleer eerst het interne adres, dan de route en de resolver voor de bron die u echt nodig hebt. Een intern adres is niet de openbare uitgang die een website meldt, en de twee verwarren stuurt mensen op jacht naar een lek dat er niet is. Test de privébron op adres voordat u op naam test, zodat een DNS-fout niet voor een routefout wordt aangezien.

Schrijf de fase, de methode en het adres in één notitie en dateer die. Als hetzelfde account over een maand weer faalt, is die notitie het verschil tussen een controle van vijf minuten en een nieuw onderzoek. Fouten in verschillende fasen zijn verschillende incidenten, ook wanneer de client maar één dialoog toont.