Welke VPN-fase is mislukt: IPsec, L2TP-besturing of PPP-authenticatie

Je hebt het wachtwoord gewijzigd en er bewoog niets, omdat de fout nooit in PPP zat. L2TP/IPsec meldt één verbindingsfout voor vijf heel verschillende overdrachten, en elke overdracht heeft zijn eigen reparatie. Werk achterwaarts: zoek de laatste fase die slaagde en wijzig alleen wat daarna komt. De volgorde hieronder bepaalt ook welk bewijs je eerst verzamelt.

Beantwoord vier vragen in volgorde

Forceer een nieuwe poging, want sommige clients blijven de vorige fout tonen tot het profiel wordt losgekoppeld en opnieuw verbonden. Beantwoord dan dit: was er een IPsec-beveiligingsassociatie, verschenen een L2TP-besturingsverbinding en een oproep, bereikte PPP een authenticatieoordeel, en gaf IPCP de client een adres? De eerste nee is de fase die je repareert. Alles daarna is ongetest, dus een geweigerde gebruikersnaam bewijst niets wanneer er nooit een associatie bestond.

Synchroniseer de klokken aan beide kanten voordat je vergelijkt. Een nieuwe poging die IPsec opschoonde en bij PPP mislukte, lijkt één fout wanneer de client alleen het laatste bericht toont en het serverlog nog de eerdere poging bevat. Lees op tijdstempel, niet op de luidste regel.

Wanneer je alleen de schermafbeelding van de gebruiker hebt, leun op de goedkoopste splitsing: een verkeerde vooraf gedeelde sleutel en een xl2tpd die nooit antwoordt produceren dezelfde tekst in de Windows-dialoog, maar de ene vereist een geheim dat aan beide kanten wordt gewijzigd en de andere een gestarte daemon of een firewallregel op de server zelf. Een apparaat in het midden kan de binnenste 1701 niet laten vallen zodra IPsec in transportmodus die heeft ingepakt, dus ga niet zoeken naar een padfilter dat er niet is.

Wat elke laag werkelijk bezit

IPsec beschermt pakketten tussen de twee peers; L2TP draagt een PPP-sessie binnen dat beschermde pad, daarom schrijft RFC 3193 transportmodus voor in plaats van een eigen tunnel. Het clientlabel zegt L2TP, dus de tunnel en de login voelen als één mechanisme. Dat zijn ze niet: de L2TP-besturingsverbinding authenticeert de tunneleinden waar een implementatie dat aanzet, en PPP authenticeert de gebruiker afzonderlijk met CHAP, PAP of MS-CHAPv2 volgens serverbeleid.

Die splitsing verklaart de twee geheimen die mensen blijven verwarren. Een vooraf gedeelde sleutel authenticeert de IPsec-peers. Een gebruikersnaam en wachtwoord identificeren de gebruiker bij PPP. Het Windows-gedeelde geheim opnieuw typen op een profiel dat met certificaten authenticeert, verandert niets in de falende fase, en het PPP-wachtwoord bewerken kan geen ontbrekend beschermd kanaal leveren. Dezelfde terughoudendheid geldt voor de identiteitscontrole: schakel de peer-identiteit of certificaatvalidatie niet uit om een tunnel te krijgen, want dan verbindt het pad, niet de peer.

Authenticatie is ook niet het einde van PPP. Nadat de gebruiker is geaccepteerd, onderhandelt IPCP over het clientadres en de DNS- en WINS-opties die de server wil uitgeven. Een client kan CHAP of MS-CHAPv2 doorstaan en toch zonder adres eindigen, wat een fout binnen PPP is en geen routeringsprobleem. Gewone L2TP zonder IPsec blijft geldig en onbeschermd, dus een geslaagde verbinding bewijst nooit dat het verkeer beschermd is; controleer wat de server afdwingt, niet het label van de client.

Beslis op basis van de eerste ontbrekende fase

Lees de tabel op het eerste ontbrekende item, van links naar rechts. De rechterkolom is het enige werk dat op dat moment de moeite waard is; alles links daarvan is al bewezen, en opnieuw testen verbrandt het storingsvenster zonder informatie toe te voegen.

Drie rijen verdienen een waarschuwing. De 1701-rij is waar Windows-clients achter NAT meestal landen: de associatie voltooit, dan komt er niets aan, en inkapseling is de oorzaak, niet een slecht wachtwoord. De IPCP-rij is degene die verkeerd wordt gelezen als routeringsprobleem, omdat Windows een ontbrekend adres in fout 720 verpakt en het systeemvakpictogram alleen zegt dat de verbinding mislukte; die fout zit na authenticatie en voor routering. De laatste rij is helemaal geen IPsec-fout, ook al zegt het pictogram losgekoppeld.

Commando's die de lagen scheiden

Op een Linux-server met strongSwan somt swanctl --list-sas de opgezette associaties op met hun peer-identiteit, en ipsec statusall dekt oudere strongSwan- en libreswan-hosts. Daaronder toont ip xfrm state de werkelijke associaties van de kernel, terwijl ss -lunp | grep 1701 bewijst waar xl2tpd aan gebonden is. Start xl2tpd -D op de voorgrond om besturingsverbindingen en oproepen te zien verschijnen, en zet pppd-debug aan in /etc/ppp/options.xl2tpd om de aangeboden methode en het antwoord te zien.

Zodra de logboeken een geslaagde authenticatie tonen, is de volgende vraag of IPCP is voltooid. Controleer of ip range in de sectie [lns default] van /etc/xl2tpd/xl2tpd.conf nog vrije adressen heeft, en of /etc/ppp/options.xl2tpd echt ms-dns en ms-wins bevat als de client die verwacht. Een uitgeputte pool en een ontbrekende DNS-optie zien er op de lijn anders uit: de eerste laat de client zonder adres en met een 720 achter, de tweede geeft een adres maar geen resolver, dus namen falen terwijl pings naar ruwe adressen werken. Geen van beide wordt gerepareerd door het wachtwoord opnieuw in te voeren.

Op de client schrijft de NetworkManager L2TP-plug-in het pppd-gesprek naar het journaal, dus journalctl -u NetworkManager -b scheidt meestal tunnel omhoog, authenticatie geweigerd van helemaal geen tunnel. Op Windows rapporteert Get-VpnConnection de werkelijke authenticatie-instellingen van het profiel, en de RasClient-gebeurtenissen onder Application in Logboeken noemen het falende onderdeel. Als de dialoog te vaag is, schakel netsh ras set tracing * enable in.

Opnamen vragen één voorzichtigheid. Met IPsec in transportmodus is de binnenste UDP 1701 versleuteld, dus een opname op de buitenste interface toont ESP, of UDP 4500 onder NAT-T, en helemaal geen L2TP. Ontbrekende 1701 in een opname is te verwachten en geen bewijs van een geblokkeerde poort; kijk of de ESP- of 4500-tellers bewegen.

NAT, MTU en routes: waar de stack je misleidt

NAT breekt aannames voordat er iets is geauthenticeerd. ESP is zijn eigen IP-protocol, dus een vertalend apparaat gooit het weg tenzij de peers inkapselen; dat is wat UDP 4500 levert. Op een Windows-server die zelf achter een thuisrouter of een cloud-NAT-gateway staat, mislukt de IPsec-fase met fout 789 tot AssumeUDPEncapsulationContextOnSendRule onder de PolicyAgent-sleutel op 2 wordt gezet en de machine opnieuw start, en de fout blijft niet te onderscheiden van een gesloten poort. Clients achter NAT zijn eenvoudiger: met een openbaar adres op de server draagt NAT-T op UDP 4500 hen en die waarde is niet betrokken.

Zodra PPP staat, imiteert een MTU met zwart gat een dode tunnel: kleine pakketten passeren, een TLS-handdruk of een paginalading blijft hangen, en de client kan nog steeds verbonden tonen. Verlaag de MTU van de interface of knijp MSS af op de gateway voordat je de server de schuld geeft. Routering van gesplitste tunnels is de andere bedrieger; een subnet dat met het verkeerde masker wordt gepusht, laat de tunnel gezond en één toepassing onbereikbaar. Een privé-hostnaam voegt zijn eigen hop toe: als de query via de lokale resolver naar buiten gaat, mislukt de naamresolutie voordat een route wordt getest.

Checklist voordat je inloggegevens aanraakt

Werk de lijst in volgorde af en stop bij het eerste item dat mislukt. Elke stap is goedkoop, en elk sluit een hele klasse wijzigingen uit.

1. Bevestig dat de associatie aan beide kanten bestaat, gematcht op peer-identiteit en niet op een verbonden-label.
2. Bevestig dat UDP 1701 xl2tpd bereikt; een associatie zonder oproep is jouw fout.
3. Lees het oordeel van PPP en, als het authenticeerde, het IPCP-resultaat, voordat je aanneemt dat het wachtwoord verkeerd is.
4. Pas nu voer je de inloggegevens opnieuw in in het formaat dat de server verwacht, want een domeinprefix verandert het account.
5. Als het nog steeds mislukt, leg beide kanten vast met uitgelijnde tijdstempels en vergelijk fase voor fase.

Stoppen bij stap twee betekent een pad- of inkapselingsprobleem, en geen wachtwoordwijziging zal dat verplaatsen. Stoppen bij stap drie betekent dat het log al de methode of de adrespool noemt die moet worden gerepareerd. Hoe dan ook is de volgende wijziging er een die je kunt rechtvaardigen, en je stopt met rondjes draaien door instellingen die nooit betrokken waren.