Hvilket lag i L2TP-profilen som faktisk røk

Arbeid deg nedover stakken i stedet for tvers over innstillingssiden: IPsec-forhandling, deretter L2TP-kontroll, deretter PPP-autentisering, deretter tildeling av adresse og DNS. Hvert lag har sin egen feilsignatur og sin egen sannsynlige årsak. En profil som feiler ved brukerautentisering har allerede overlevd tre kontroller som en profil som timet ut tidligere aldri nådde. Den rekkefølgen er det første som må fastslås.

Det samme protokollnavnet skjuler fire forskjellige samtaler.

Navngi laget før du endrer innstillinger

Hvis IPsec-oppsettet feiler, peker det på den delte hemmeligheten, algoritmene eller peer-identiteten. Hvis L2TP-kontrollen feiler etterpå, tyder det på selve tunnellaget, som er et snevrere problem. PPP-autentiseringsfeil navngir kontoen eller autentiseringsmetoden. En adresse- eller DNS-feil etter autentisering betyr at transporten virket og at konfigurasjonsutvekslingen ikke gjorde det.

Noter klientversjonen, operativsystemversjonen og operatørens dokumenterte oppsett. Uten disse tre er enhver endring en gjetning som ved et uhell kan rette noe annet.

Sammenlign profilen med den gjeldende klienten

En lagret profil kan inneholde en delt hemmelighet, et autentiseringsvalg eller et endepunkt som den gjeldende klienten ikke lenger godtar. Noen plattformer har avviklet eller fjernet støtten for L2TP/IPsec helt, og en oppdatert klient kan droppe gammel IKE-atferd uten noen endring på serveren. Sammenlign de lagrede verdiene dine med operatørens gjeldende dokumenterte krav, ikke med det som virket for et år siden. Forskjellen mellom de to dokumentene er vanligvis der svaret ligger.

En bufret hemmelighet eller en omdøpt konto krever vanligvis ikke mer enn en vanlig profiloppdatering, og begge er verdt å sjekke før du redesigner noe. Det er de billige rettelsene, og de bør utelukkes før noe arkitektonisk.

Gamle innstillinger kommer ikke tilbake ved å bli aktivert

Å slå av validering reparerer ikke et problem i tillitskjeden, og å aktivere en algoritme bare fordi en forumtråd nevner den, beviser ingenting om hva serveren godtar. Svake IKE-forslag fjernes vanligvis fra klienter av gode grunner, og å aktivere et av dem igjen skaper en forbindelse som er verre enn den som røk. En svakere tunnel er ikke en reparasjon, det er et nytt problem med samme symptom. Det riktige spørsmålet er hva operatøren støtter nå.

En reparasjon der alt aktiveres, endrer langt mer enn den faktiske feilen og etterlater deg uten å kunne si hva som løste den.

Legg migreringen fram som et prosjekt

Hvis utrullingen ikke lenger støtter den nødvendige klienten, planlegg en erstatning sammen med operatøren i stedet for å bevare et udokumentert unntak. Flytt tilgangskravet, identitetene, DNS-oppføringene og rutene over, fordi et nytt håndtrykk alene ikke gjenoppretter noen av disse tillatelsene. Det er delene en fungerende forbindelse stille var avhengig av. Oppbevar den gamle profilen trygt til gjenopprettingen er bekreftet, og trekk deretter tilbake de utdaterte påloggingsdetaljene der de faktisk administreres. Å la dem bli stående er måten en gammel vei forblir brukbar lenge etter at alle tror den er lukket.

En migrering er også øyeblikket for å skrive ned hva profilen var til. Ellers arver neste person en fungerende forbindelse uten noen forklaring.

Sjekk laget, klientversjonen og operatørens gjeldende krav. Bestem deretter om dette er en reparasjon eller en erstatning.