Kva lag i L2TP-profilen som faktisk rauk
IPsec-forhandling, L2TP-kontroll, PPP-autentisering og tildeling av adresser feilar på ulike måtar. Fastslå laget før du aktiverer kvar eldre innstilling.
Arbeid deg nedover stakken i staden for tvers over innstillingssida: IPsec-forhandling, deretter L2TP-kontroll, deretter PPP-autentisering, deretter tildeling av adresse og DNS. Kvart lag har sin eigen feilsignatur og si eiga sannsynlege årsak. Ein profil som feilar ved brukarautentisering har allereie overlevd tre kontrollar som ein profil som tima ut tidlegare aldri nådde. Den rekkjefølgja er det første som må fastslåast.
Det same protokollnamnet skjuler fire ulike samtalar.
Namngi laget før du endrar innstillingar
Viss IPsec-oppsettet feilar, peikar det på den delte løyndomen, algoritmane eller identiteten til motparten. Viss L2TP-kontrollen feilar etterpå, tyder det på sjølve tunnellaget, som er eit snevrare problem. PPP-autentiseringsfeil namngir kontoen eller autentiseringsmetoden. Ein adresse- eller DNS-feil etter autentisering betyr at transporten verka og at konfigurasjonsutvekslinga ikkje gjorde det.
Noter klientversjonen, versjonen av operativsystemet og det dokumenterte oppsettet til operatøren. Utan desse tre er kvar endring eit gjetting som ved eit uhell kan rette noko anna.
Samanlikn profilen med den gjeldande klienten
Ein lagra profil kan innehalde ein delt løyndom, eit autentiseringsval eller eit endepunkt som den gjeldande klienten ikkje lenger godtek. Nokre plattformer har avvikla eller fjerna støtta for L2TP/IPsec heilt, og ein oppdatert klient kan droppe gamal IKE-åtferd utan noka endring på tenaren. Samanlikn dei lagra verdiane dine med dei gjeldande dokumenterte krava til operatøren, ikkje med det som verka for eitt år sidan. Skilnaden mellom dei to dokumenta er vanlegvis der svaret ligg.
Ein bufra løyndom eller ein omdøypt konto krev vanlegvis ikkje meir enn ein vanleg profiloppdatering, og begge er verd å sjekke før du redesignar noko. Det er dei billege rettingane, og dei bør utelukkast før noko arkitektonisk.
Gamle innstillingar kjem ikkje tilbake ved å bli aktiverte
Å slå av validering reparerer ikkje eit problem i tillitskjeda, og å aktivere ein algoritme berre fordi ein forumtråd nemner han, bevisar ingenting om kva tenaren godtek. Svake IKE-forslag blir vanlegvis fjerna frå klientar av gode grunnar, og å aktivere eitt av dei igjen skaper ei tilkopling som er verre enn den som rauk. Ein svakare tunnel er ikkje ein reparasjon, det er eit nytt problem med same symptom. Det rette spørsmålet er kva operatøren støttar no.
Ein reparasjon der alt blir aktivert, endrar langt meir enn den faktiske feilen og lèt deg ikkje seie kva som løyste han.
Legg migreringa fram som eit prosjekt
Viss utrullinga ikkje lenger støttar den naudsynte klienten, planlegg ei erstatning saman med operatøren i staden for å ta vare på eit udokumentert unntak. Flytt tilgangskravet, identitetane, DNS-oppføringane og rutene over, fordi eit nytt handtrykk åleine ikkje attskapar nokon av desse løyva. Det er delane ein fungerande tilkopling stille var avhengig av. Oppbevar den gamle profilen trygt til gjenopprettinga er stadfesta, og trekk deretter tilbake dei utdaterte påloggingsdetaljane der dei faktisk blir administrerte. Å la dei bli ståande er måten ein gamal veg blir brukbar lenge etter at alle trur han er lukka.
Ei migrering er òg augneblinken for å skrive ned kva profilen var til. Elles arvar neste person ei fungerande tilkopling utan noka forklaring.
Sjekk laget, klientversjonen og dei gjeldande krava til operatøren. Bestem deretter om dette er ein reparasjon eller ei erstatning.