Hvilket lag i L2TP-profilen gik egentlig i stykker

Arbejd ned gennem stakken i stedet for på tværs af indstillingssiden: IPsec-forhandling, derefter L2TP-kontrol, derefter PPP-godkendelse, derefter tildeling af adresse og DNS. Hvert lag har sin egen fejlsignatur og sin egen sandsynlige årsag. En profil, der fejler ved brugergodkendelse, har allerede overlevet tre kontroller, som en profil, der timede ud tidligere, aldrig nåede. Den rækkefølge er det første, der skal fastslås.

Det samme protokolnavn skjuler fire forskellige samtaler.

Navngiv laget, før du ændrer indstillinger

Hvis IPsec-opsætningen fejler, peger det på den delte hemmelighed, algoritmerne eller peer-identiteten. Hvis L2TP-kontrollen fejler bagefter, tyder det på selve tunnellaget, hvilket er et snævrere problem. PPP-godkendelsesfejl navngiver kontoen eller godkendelsesmetoden. En adresse- eller DNS-fejl efter godkendelsen betyder, at transporten virkede, og at konfigurationsudvekslingen ikke gjorde.

Notér klientversionen, styresystemversionen og operatørens dokumenterede opsætning. Uden de tre er enhver ændring et gæt, der måske ved et uheld retter noget andet.

Sammenlign profilen med den aktuelle klient

En gemt profil kan indeholde en delt hemmelighed, en godkendelsesindstilling eller et endpoint, som den aktuelle klient ikke længere accepterer. Nogle platforme har helt afviklet eller fjernet understøttelsen af L2TP/IPsec, og en opdateret klient kan droppe gammel IKE-adfærd uden nogen ændring på serveren. Sammenlign dine gemte værdier med operatørens nuværende dokumenterede krav i stedet for med det, der virkede for et år siden. Forskellen mellem de to dokumenter er normalt der, hvor svaret ligger.

En cachet hemmelighed eller en omdøbt konto kræver normalt ikke mere end en almindelig profilopdatering, og begge er værd at kontrollere, før du redesigner noget. Det er de billige rettelser, og de bør udelukkes, før noget arkitektonisk.

Gamle indstillinger kommer ikke tilbage ved at blive aktiveret

At slå validering fra reparerer ikke et problem med tillidskæden, og at aktivere en algoritme blot fordi en forumtråd nævner den, beviser intet om, hvad serveren accepterer. Svage IKE-forslag fjernes normalt fra klienter af gode grunde, og at genaktivere et af dem skaber en forbindelse, der er værre end den, der gik i stykker. En svagere tunnel er ikke en reparation, det er et nyt problem med det samme symptom. Det rigtige spørgsmål er, hvad operatøren nu understøtter.

En reparation, hvor alt aktiveres, ændrer langt mere end den faktiske fejl og efterlader dig ude af stand til at sige, hvad der løste den.

Læg migreringen frem som et projekt

Hvis implementeringen ikke længere understøtter den krævede klient, så planlæg en erstatning sammen med operatøren i stedet for at bevare en udokumenteret undtagelse. Flyt adgangskravet, identiteterne, DNS-posterne og ruterne med over, fordi et nyt håndtryk alene ikke genskaber nogen af de tilladelser. Det er de dele, en fungerende forbindelse stille var afhængig af. Opbevar den gamle profil sikkert, indtil gendannelsen er bekræftet, og udfas derefter de forældede legitimationsoplysninger der, hvor de faktisk administreres. At lade dem blive er måden, hvorpå en gammel vej forbliver brugbar længe efter, at alle tror, den er lukket.

En migrering er også øjeblikket til at skrive ned, hvad profilen var til. Ellers arver den næste person en fungerende forbindelse uden nogen forklaring.

Kontroller laget, klientversionen og operatørens nuværende krav. Beslut derefter, om det er en reparation eller en erstatning.