Cila shtresë e profilit L2TP u prish në të vërtetë

Zbrisni nëpër shtresa, jo për së gjeri në faqen e cilësimeve: Negocimi IPsec, pastaj kontrolli L2TP, pastaj vërtetimi PPP, pastaj caktimi i adresës dhe DNS. Secila shtresë ka nënshkrimin e vet të gabimit dhe shkakun e vet të mundshëm. Një profil që dështon në vërtetimin e përdoruesit tashmë ka kaluar tre kontrolle që një profil i skaduar më parë nuk i arriti kurrë. Pikërisht ky renditje duhet përcaktuar së pari.

I njëjti emër protokolli fsheh katër biseda të ndryshme.

Emërtoni shtresën përpara se të ndryshoni cilësimet

Dështimi i konfigurimit IPsec të drejton te sekreti i përbashkët, algoritmet ose identiteti i palës tjetër. Nëse më pas dështon kontrolli L2TP, sugjerohet vetë shtresa e tunelit, që është problem më i ngushtë. Dështimet e vërtetimit PPP emërtojnë llogarinë ose metodën e vërtetimit. Një dështim adrese ose DNS pas vërtetimit do të thotë që transporti funksionoi dhe shkëmbimi i konfigurimit jo.

Shënoni versionin e klientit, versionin e sistemit operativ dhe konfigurimin e dokumentuar të operatorit. Pa këto të treja, çdo ndryshim është një hamendje që mund të rregullojë aksidentalisht diçka tjetër.

Krahasoni profilin me klientin aktual

Një profil i ruajtur mund të mbajë një sekret të përbashkët, një opsion vërtetimi ose një pikë fundore që klienti aktual nuk i pranon më. Disa platforma kanë tërhequr ose hequr plotësisht mbështetjen për L2TP/IPsec, dhe një klient i përditësuar mund të heqë dorë nga sjellja e vjetër e IKE pa asnjë ndryshim në server. Krahasoni vlerat tuaja të ruajtura me kërkesat aktuale të dokumentuara të operatorit, jo me atë që funksiononte një vit më parë. Diferenca midis këtyre dy dokumenteve është zakonisht vendi ku ndodhet përgjigjja.

Një sekret i ruajtur në cache ose një llogari e riemërtuar zakonisht nuk kërkojnë më shumë se një përditësim të zakonshëm të profilit, dhe të dyja vlen të kontrollohen përpara se të ridizajnoni diçka. Këto janë rregullimet e lira dhe duhet të përjashtohen përpara çdo pune arkitekturore.

Opsionet e vjetra nuk kthehen duke i aktivizuar

Çaktivizimi i verifikimit nuk rregullon një problem të zinxhirit të besimit, dhe aktivizimi i një algoritmi vetëm sepse e përmend një temë forumi nuk provon asgjë se çfarë pranon serveri. Propozimet e dobëta IKE zakonisht hiqen nga klientët për arsye të mira, dhe riaktivizimi i njërës prej tyre krijon një lidhje më të keqe se ajo që u prish. Një tunel më i dobët nuk është rregullim, është problem i ri me të njëjtin simptomë. Pyetja e saktë është çfarë mbështet operatori tani.

Rregullimi që aktivizon gjithçka ndryshon shumë më tepër sesa defekti real dhe ju lë të paaftë të thoni se çfarë e rregulloi.

Parashtroni migrimin si projekt

Nëse vendosja nuk e mbështet më klientin e kërkuar, planifikoni një zëvendësim me operatorin në vend që të ruani një përjashtim të padokumentuar. Kaloni kërkesën e aksesit, identitetet, regjistrimet DNS dhe rrugët, sepse një shtrëngim duarsh i ri nuk rikrijon asnjë prej atyre lejeve. Këto janë pjesët nga të cilat një lidhje funksionale varej në heshtje. Mbajeni profilin e vjetër të sigurt derisa rikuperimi të konfirmohet, pastaj tërhiqni kredencialet e vjetruara atje ku ato administrohen vërtet. T'i lini në vend është mënyra se si një rrugë e vjetër mbetet e përdorshme shumë kohë pasi të gjithë besojnë se është mbyllur.

Migrimi është gjithashtu momenti për të shkruar për çfarë ishte profili. Përndryshe personi tjetër trashëgon një lidhje funksionale pa asnjë shpjegim.

Kontrolloni shtresën, versionin e klientit dhe kërkesat aktuale të operatorit. Pastaj vendosni nëse ky është rregullim apo zëvendësim.