L2TP ansluter, men PPP-förhandlingen misslyckas: vilken fas?

IPsec-tunneln upprättas, klienten visar en skyddad peer och sedan dör anslutningen innan något når det privata subnätet. Den luckan är PPP som gör sitt eget arbete: länkval, användarautentisering och adresstilldelning sker alla efter att den krypterade tunneln finns. Inget i ett lyckat utbyte av första fasen ger ett lösenord eller en inre adress. Läs faserna i ordning och felet namnger oftast sig självt.

Tunneln är bara det första lagret

L2TP bär PPP-ramar inuti en IPsec-skyddad tunnel, vilket betyder att två oberoende förhandlingar måste lyckas innan ett paket kan routas. Den yttre bevisar att båda ändarna är överens om nycklar och identiteter. Den inre avgör länkparametrar, om användaren autentiseras och vilken adress klienten får.

Ett fel inuti PPP ser ut som en trasig tunnel i varje klient som bara visar en statuslampa. Behandlas det som ett tunnelproblem leder det till ny nyckelgenerering, omstart av tjänster och till slut byte av en delad hemlighet som aldrig var fel. Den användbara skillnaden är billig: om utbytet med peeren slutfördes och klienten gick vidare till en begäran om användarnamn eller en autentiseringsfas, är tunneln okej. Allt efter den punkten tillhör PPP.

Läs den senaste fasen som lyckades

Gå genom loggen framåt och stanna vid den första fasen som inte slutfördes. LCP kommer först, sedan autentisering, sedan IPCP för IPv4-parametrarna.

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

En LCP-timeout betyder att de två ändarna aldrig kom överens om de grundläggande länkvalen, vilket är en profil som inte matchar eller ett blockerat inre protokoll, inte ett dåligt lösenord. En uttrycklig autentiseringsavvisning är det motsatta fallet: länken kom upp och ena sidan avvisade inloggningsuppgifterna. En IPCP-timeout efter lyckad autentisering pekar på adresspooler eller serverpolicy. Var och en av dem har en annan ägare och en annan reparation, därför betyder fasen mer än den slutliga feltexten.

Spara loggutdraget tillsammans med fasnamnet i ärendet. En inklistrad svans utan fasgränsen bjuder in nästa läsare att gissa, och gissande kostar en timme här.

Enighet mellan klienten och servern

Båda ändarna måste acceptera samma autentiseringsmetod, och en sparad profil kan begära en som servern avvecklade förra kvartalet. Hanterade utrullningar döljer också serversidan, där orsaken till avvisningen vanligtvis registreras på användaren i stället för enheten.

Aktivera en stödd metod i stället för varje äldre alternativ, eftersom en klient som erbjuder fem metoder döljer vilken som misslyckades. Be administratören om policyn på serversidan och den exakta avvisningen, vilket inte kräver att någon publicerar ett lösenord. En äldre metod som aktiveras för att rädda en klient sprider sig gärna till varje profil som kopierar filen.

Kontrollera adressen, inte inloggningen

En slutförd inloggning är inte en användbar session. IPCP förhandlar den inre adressen, och en uttömd pool eller en policy som nekar klienten kan fortfarande lämna en ansluten tunnel utan något att routa.

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

Kontrollera den inre adressen först, sedan rutten och resolvern för resursen du faktiskt behöver. En inre adress är inte den offentliga utgången som en webbplats rapporterar, och att blanda ihop de två skickar folk att jaga en läcka som inte finns. Testa den privata resursen på adress innan du testar på namn, så att ett DNS-fel inte misstas för ett routningsfel.

Skriv fasen, metoden och adressen i en enda anteckning och datera den. Om samma konto misslyckas igen om en månad är anteckningen skillnaden mellan en femminuterskontroll och en ny utredning. Fel i olika faser är olika incidenter, även när klienten bara visar en dialog.