Vilket VPN-steg misslyckades: IPsec, L2TP-kontroll eller PPP-autentisering

Du bytte lösenord och ingenting rörde sig, eftersom felet aldrig låg i PPP. L2TP/IPsec rapporterar ett anslutningsfel för fem mycket olika överlämningar, och varje överlämning har sin egen reparation. Arbeta baklänges: hitta det sista steget som lyckades och ändra bara det som kommer efter. Ordningen nedan avgör också vilka bevis du samlar först.

Svara på fyra frågor i ordning

Tvinga fram ett nytt försök, eftersom vissa klienter fortsätter visa det föregående felet tills profilen kopplas från och ansluts igen. Svara sedan på detta: fanns en IPsec-säkerhetsassociation, dök en L2TP-kontrollanslutning och ett samtal upp, nådde PPP en autentiseringsdom, och gav IPCP klienten en adress? Det första nej är steget du reparerar. Allt efter det är otestat, så ett avvisat användarnamn bevisar ingenting när det aldrig fanns någon association.

Synkronisera klockorna i båda ändarna innan du jämför. Ett nytt försök som rensade IPsec och misslyckades vid PPP ser ut som ett enda fel när klienten bara visar det sista meddelandet och serverloggen fortfarande håller det tidigare försöket. Läs efter tidsstämpel, inte efter den mest högljudda raden.

När du bara har användarens skärmbild, luta dig mot den billigaste uppdelningen: en felaktig fördelad nyckel och en xl2tpd som aldrig svarar ger samma text i Windows-dialogen, men den ena kräver en hemlighet ändrad i båda ändar och den andra en startad daemon eller en brandväggsregel på själva servern. En enhet i mitten kan inte släppa den inre 1701 när IPsec i transportläge har packat in den, så leta inte efter ett stifilter som inte finns.

Vad varje lager egentligen äger

IPsec skyddar paket mellan de två parterna; L2TP bär en PPP-session inne i den skyddade vägen, och därför anger RFC 3193 transportläge i stället för en egen tunnel. Klientens etikett säger L2TP, så tunneln och inloggningen känns som en enda mekanism. De är inte det: L2TP-kontrollanslutningen autentiserar tunnelns ändpunkter där en driftsättning slår på det, och PPP autentiserar användaren separat med CHAP, PAP eller MS-CHAPv2 enligt serverns policy.

Den uppdelningen förklarar de två hemligheter folk ständigt blandar ihop. En fördelad nyckel autentiserar IPsec-parterna. Ett användarnamn och ett lösenord identifierar användaren för PPP. Att skriva om Windows delade hemlighet på en profil som autentiserar med certifikat ändrar ingenting i det misslyckade steget, och att redigera PPP-lösenordet kan inte ge en saknad skyddad kanal. Samma återhållsamhet gäller identitetskontrollen: stäng inte av partens identitet eller certifikatvalidering för att få en tunnel, för då är det vägen som ansluts, inte parten.

Inte heller autentisering är slutet på PPP. När användaren har accepterats förhandlar IPCP om klientadressen och de DNS- och WINS-alternativ som servern är villig att dela ut. En klient kan klara CHAP eller MS-CHAPv2 och ändå sluta utan adress, vilket är ett fel inne i PPP och inte ett routingproblem. Vanlig L2TP utan IPsec förblir giltig och oskyddad, så en lyckad anslutning bevisar aldrig att trafiken är skyddad; kontrollera vad servern kräver, inte klientens etikett.

Bestäm utifrån det första saknade steget

Läs tabellen efter det första saknade objektet, från vänster till höger. Den högra kolumnen är det enda arbete som är värt något i det läget; allt till vänster är redan bevisat, och att testa om det bränner avbrottsfönstret utan att tillföra information.

Tre rader förtjänar en varning. Raden 1701 är där Windows-klienter bakom NAT vanligtvis landar: associationen slutförs, sedan kommer ingenting, och orsaken är inkapsling, inte ett dåligt lösenord. Raden IPCP är den som felaktigt läses som ett routingproblem, eftersom Windows packar in den saknade adressen i fel 720 och fältikonen bara säger att anslutningen misslyckades; det felet ligger efter autentiseringen och före routingen. Den sista raden är inte alls ett IPsec-fel, även om ikonen säger frånkopplad.

Kommandon som skiljer lagren

På en Linux-server med strongSwan listar swanctl --list-sas etablerade associationer med partens identitet, och ipsec statusall täcker äldre strongSwan- och libreswan-värdar. Under visar ip xfrm state kernens faktiska associationer, medan ss -lunp | grep 1701 bevisar var xl2tpd är bunden. Kör xl2tpd -D i förgrunden för att se kontrollanslutningar och samtal, och slå på pppd-felsökning i /etc/ppp/options.xl2tpd för att se metoden som erbjuds och svaret.

När loggarna visar lyckad autentisering är nästa fråga om IPCP slutfördes. Kontrollera att ip range i avsnittet [lns default] i /etc/xl2tpd/xl2tpd.conf fortfarande har lediga adresser, och att /etc/ppp/options.xl2tpd faktiskt bär ms-dns och ms-wins om klienten förväntar sig dem. En uttömd pool och ett saknat DNS-alternativ ser olika ut på ledningen: det första lämnar klienten utan adress och med 720, det andra ger en adress men ingen resolver, så namn misslyckas medan ping mot råa adresser fungerar. Ingen av dem repareras genom att skriva in lösenordet igen.

På klienten skriver NetworkManager L2TP-instickningen pppd-samtalet i journalen, så journalctl -u NetworkManager -b skiljer vanligtvis tunnel uppe, autentisering avvisad från ingen tunnel alls. På Windows rapporterar Get-VpnConnection profilens verkliga autentiseringsinställningar, och RasClient-händelserna under Application i Loggboken namnger komponenten som misslyckas. När dialogen är för vag, aktivera netsh ras set tracing * enable.

Insamlingar kräver en försiktighet. Med IPsec i transportläge är den inre UDP 1701 krypterad, så en insamling på det yttre gränssnittet visar ESP, eller UDP 4500 under NAT-T, och ingen L2TP alls. Att 1701 saknas i en insamling är väntat och inte bevis på en blockerad port; följ om ESP- eller 4500-räknarna rör sig.

NAT, MTU och rutter: där stacken vilseleder dig

NAT bryter antaganden innan något är autentiserat. ESP är sitt eget IP-protokoll, så en enhet som översätter kastar det om inte parterna kapslar in; det är vad UDP 4500 ger. På en Windows-server som själv står bakom en hemrouter eller en moln-NAT-gateway misslyckas IPsec-steget med fel 789 tills AssumeUDPEncapsulationContextOnSendRule sätts till 2 under PolicyAgent-nyckeln och maskinen startas om, och felet förblir omöjligt att skilja från en stängd port. Klienter bakom NAT är enklare: med en offentlig adress på servern bär NAT-T på UDP 4500 dem, och det värdet är inte inblandat.

När PPP är uppe imiterar en MTU med svart hål en död tunnel: små paket passerar, ett TLS-handslag eller en sidladdning hänger, och klienten kan fortfarande visa ansluten. Sänk gränssnittets MTU eller kläm MSS vid gatewayen innan du skyller på servern. Routingen för delad tunnel är den andra bedragaren; ett subnät som skickas med fel mask lämnar tunneln frisk och en applikation oåtkomlig. Ett privat värdnamn lägger till sitt eget hopp: om frågan går ut via den lokala resolvern misslyckas namnet innan någon rutt testas.

Checklista innan du rör inloggningsuppgifter

Gå igenom listan i ordning och stanna vid det första objekt som misslyckas. Varje steg är billigt, och varje steg utesluter en hel klass av ändringar.

1. Bekräfta att associationen finns i båda ändar, matchad på partens identitet och inte på en ansluten-etikett.
2. Bekräfta att UDP 1701 når xl2tpd; en association utan samtal är ditt fel.
3. Läs PPP:s dom, och om den autentiserade, IPCP-resultatet, innan du antar att lösenordet är fel.
4. Först nu skriver du in inloggningsuppgifterna igen i det format servern förväntar sig, eftersom ett domänprefix ändrar kontot.
5. Om det fortfarande misslyckas, spela in båda ändar med justerade tidsstämplar och jämför steg för steg.

Att stanna vid steg två betyder ett väg- eller inkapslingsproblem, och ingen lösenordsändring flyttar det. Att stanna vid steg tre betyder att loggen redan namnger metoden eller adresspoolen som ska repareras. Hur som helst är nästa ändring en du kan motivera, och du slutar cirkla genom inställningar som aldrig var inblandade.