Welke laag van het L2TP-profiel is werkelijk stukgegaan

Werk de stapel af, in plaats van dwars over de instellingenpagina: IPsec-onderhandeling, dan L2TP-besturing, dan PPP-authenticatie, dan adres- en DNS-uitgifte. Elke laag heeft zijn eigen foutsignatuur en zijn eigen waarschijnlijke oorzaak. Een profiel dat faalt bij gebruikerauthenticatie heeft al drie controles doorstaan die een profiel dat eerder afliep nooit bereikte. Die volgorde is het eerste dat moet worden vastgesteld.

Dezelfde protocolnaam verbergt vier verschillende gesprekken.

Benoem de laag voordat je instellingen wijzigt

Als de IPsec-configuratie faalt, wijst dat op het gedeelde geheim, de algoritmes of de identiteit van de tegenpartij. Als daarna de L2TP-besturing faalt, wijst dat op de tunnel-laag zelf, wat een smaller probleem is. PPP-authenticatiefouten noemen het account of de authenticatiemethode. Een adres- of DNS-fout na authenticatie betekent dat het transport werkte en de configuratie-uitwisseling niet.

Noteer de clientversie, de versie van het besturingssysteem en de gedocumenteerde configuratie van de operator. Zonder die drie is elke wijziging een gok die per ongeluk iets anders kan repareren.

Vergelijk het profiel met de huidige client

Een opgeslagen profiel kan een gedeeld geheim, een authenticatieoptie of een endpoint bevatten dat de huidige client niet meer accepteert. Sommige platforms hebben L2TP/IPsec-ondersteuning volledig ingetrokken of verwijderd, en een bijgewerkte client kan oud IKE-gedrag laten vallen zonder enige wijziging op de server. Vergelijk je opgeslagen waarden met de huidige gedocumenteerde eisen van de operator, niet met wat een jaar geleden werkte. Het gat tussen die twee documenten is meestal waar het antwoord zit.

Een gecacht geheim of een hernoemd account vraagt meestal niet meer dan een gewone profielupdate, en beide zijn het controleren waard voordat je iets herontwerpt. Dat zijn de goedkope reparaties, en ze moeten worden uitgesloten voordat er iets architectonisch gebeurt.

Oude opties komen niet terug door ze in te schakelen

Validatie uitschakelen repareert geen probleem met de vertrouwensketen, en een algoritme inschakelen alleen omdat een forumdraadje het noemt bewijst niets over wat de server accepteert. Zwakke IKE-voorstellen worden meestal om goede redenen uit clients verwijderd, en er één opnieuw inschakelen maakt een verbinding die slechter is dan degene die stukging. Een zwakkere tunnel is geen reparatie, het is een nieuw probleem met hetzelfde symptoom. De juiste vraag is wat de operator nu ondersteunt.

Een reparatie waarbij alles wordt ingeschakeld verandert veel meer dan de werkelijke storing en laat je niet kunnen zeggen wat het heeft opgelost.

Presenteer de migratie als een project

Als de uitrol de vereiste client niet meer ondersteunt, plan dan een vervanging met de operator in plaats van een ongedocumenteerde uitzondering te bewaren. Neem de toegangseis, de identiteiten, de DNS-records en de routes mee, want een nieuwe handshake alleen herstelt geen van die machtigingen. Dat zijn de onderdelen waarop een werkende verbinding stilzwijgend leunde. Bewaar het oude profiel veilig tot het herstel is bevestigd, en trek daarna de verouderde inloggegevens in waar ze werkelijk worden beheerd. Ze laten staan is de manier waarop een oud pad nog lang bruikbaar blijft nadat iedereen gelooft dat het gesloten is.

Een migratie is ook het moment om vast te leggen waarvoor het profiel diende. Anders erft de volgende persoon een werkende verbinding zonder enige uitleg.

Controleer de laag, de clientversie en de huidige eisen van de operator. Beslis daarna of dit een reparatie of een vervanging is.