Vilket lager i L2TP-profilen som faktiskt gick sönder

Arbeta dig nedåt i stacken i stället för tvärs över inställningssidan: IPsec-förhandling, därefter L2TP-styrning, därefter PPP-autentisering, därefter tilldelning av adress och DNS. Varje lager har sin egen felsignatur och sin egen sannolika orsak. En profil som misslyckas vid användarautentisering har redan klarat tre kontroller som en profil som tog timeout tidigare aldrig nådde. Den ordningen är det första som måste fastställas.

Samma protokollnamn döljer fyra olika samtal.

Namnge lagret innan du ändrar inställningar

Om IPsec-konfigurationen misslyckas pekar det på den delade hemligheten, algoritmerna eller motpartens identitet. Om L2TP-styrningen misslyckas efter det tyder det på själva tunnellagret, vilket är ett snävare problem. PPP-autentiseringsfel namnger kontot eller autentiseringsmetoden. Ett adress- eller DNS-fel efter autentiseringen betyder att transporten fungerade och att konfigurationsutbytet inte gjorde det.

Notera klientversionen, operativsystemversionen och operatörens dokumenterade konfiguration. Utan dessa tre är varje ändring en gissning som av misstag kan laga något annat.

Jämför profilen med den nuvarande klienten

En sparad profil kan innehålla en delad hemlighet, ett autentiseringsalternativ eller en slutpunkt som den nuvarande klienten inte längre accepterar. Vissa plattformar har dragit tillbaka eller tagit bort stödet för L2TP/IPsec helt, och en uppdaterad klient kan överge det gamla IKE-beteendet utan någon ändring på servern. Jämför dina sparade värden med operatörens nuvarande dokumenterade krav, inte med det som fungerade för ett år sedan. Skillnaden mellan de två dokumenten är vanligtvis där svaret finns.

En cachad hemlighet eller ett omdöpt konto kräver vanligtvis inte mer än en vanlig profiluppdatering, och båda är värda att kontrollera innan du designar om något. Det är de billiga åtgärderna, och de bör uteslutas innan något arkitektoniskt görs.

Gamla inställningar kommer inte tillbaka genom att aktiveras

Att stänga av validering reparerar inte ett problem i tillitskedjan, och att aktivera en algoritm bara för att en forumtråd nämner den bevisar ingenting om vad servern accepterar. Svaga IKE-förslag tas vanligtvis bort från klienter av goda skäl, och att återaktivera ett av dem skapar en anslutning som är sämre än den som gick sönder. En svagare tunnel är ingen reparation, det är ett nytt problem med samma symptom. Den rätta frågan är vad operatören stöder nu.

En reparation där allt aktiveras ändrar långt mer än det faktiska felet och lämnar dig oförmögen att säga vad som löste det.

Lägg fram migreringen som ett projekt

Om driftsättningen inte längre stöder den nödvändiga klienten, planera en ersättning tillsammans med operatören i stället för att bevara ett odokumenterat undantag. Flytta över åtkomstkravet, identiteterna, DNS-posterna och rutterna, eftersom ett nytt handskakning ensamt inte återskapar någon av dessa behörigheter. Det är de delar som en fungerande anslutning tyst vilade på. Förvara den gamla profilen säkert tills återställningen är bekräftad, dra sedan tillbaka de inaktuella inloggningsuppgifterna där de faktiskt administreras. Att låta dem ligga kvar är hur en gammal väg förblir användbar länge efter att alla tror att den är stängd.

En migrering är också ögonblicket för att skriva ned vad profilen var till för. Annars ärver nästa person en fungerande anslutning utan någon förklaring.

Kontrollera lagret, klientversionen och operatörens nuvarande krav. Bestäm sedan om detta är en reparation eller en ersättning.