Kuris L2TP profilio sluoksnis iš tikrųjų lūžo

Eikite žemyn sluoksniais, o ne skersai nustatymų puslapio: IPsec derybos, tada L2TP valdymas, tada PPP autentifikavimas, tada adreso ir DNS priskyrimas. Kiekvienas sluoksnis turi savo klaidos parašą ir savo tikėtiną priežastį. Profilis, kuris nepavyksta autentifikuojant naudotoją, jau praėjo tris patikras, kurių anksčiau pasibaigęs profilis niekada nepasiekė. Būtent šią seką pirmiausia reikia nustatyti.

Tas pats protokolo pavadinimas slepia keturis skirtingus pokalbius.

Įvardykite sluoksnį prieš keisdami nustatymus

IPsec sąrankos nepavykimas nurodo bendrą paslaptį, algoritmus arba priešinės pusės tapatybę. Jei po to nepavyksta L2TP valdymas, tai rodo patį tunelio sluoksnį, o tai siauresnė problema. PPP autentifikavimo klaidos įvardija paskyrą arba autentifikavimo metodą. Adreso ar DNS nepavykimas po autentifikavimo reiškia, kad transportas veikė, o konfigūracijos mainai ne.

Užrašykite kliento versiją, operacinės sistemos versiją ir dokumentuotą operatoriaus sąranką. Be šių trijų kiekvienas pakeitimas yra spėjimas, kuris gali atsitiktinai sutaisyti ką nors kita.

Palyginkite profilį su dabartiniu klientu

Išsaugotame profilyje gali būti bendra paslaptis, autentifikavimo parinktis arba galinis taškas, kurių dabartinis klientas nebepriima. Kai kurios platformos visiškai atsisakė L2TP/IPsec palaikymo arba jį pašalino, o atnaujintas klientas gali atsisakyti seno IKE elgesio be jokių pakeitimų serveryje. Palyginkite savo išsaugotas reikšmes su dabartiniais dokumentuotais operatoriaus reikalavimais, o ne su tuo, kas veikė prieš metus. Skirtumas tarp šių dviejų dokumentų paprastai yra vieta, kurioje slypi atsakymas.

Talpykloje esanti paslaptis arba pervadinta paskyra paprastai nereikalauja nieko daugiau nei įprasto profilio atnaujinimo, ir abu verta patikrinti prieš ką nors perdarant. Tai pigūs taisymai, ir juos reikėtų atmesti prieš bet kokį architektūrinį darbą.

Senos parinktys negrįžta vien todėl, kad įjungiamos

Išjungus tikrinimą pasitikėjimo grandinės problema nesutaisoma, o algoritmą įjungus vien todėl, kad jį mini forumo tema, nieko neįrodoma apie tai, ką serveris priima. Silpni IKE pasiūlymai paprastai pašalinami iš klientų dėl gerų priežasčių, o vieno jų vėl įjungimas sukuria ryšį, prastesnį už tą, kuris lūžo. Silpnesnis tunelis nėra taisymas, tai nauja problema su tuo pačiu simptomu. Teisingas klausimas yra tai, ką operatorius dabar palaiko.

Taisymas įjungiant viską pakeičia daug daugiau nei tikrąjį gedimą ir palieka jus negalintį pasakyti, kas jį ištaisė.

Pateikite migraciją kaip projektą

Jei diegimas nebeatitinka reikiamo kliento, planuokite pakeitimą kartu su operatoriumi, o ne saugokite nedokumentuotą išimtį. Perkelkite prieigos reikalavimą, tapatybes, DNS įrašus ir maršrutus, nes vienas naujas rankos paspaudimas pats savaime neatkuria nė vieno iš tų leidimų. Tai dalys, kuriomis veikiantis ryšys tyliai rėmėsi. Saugokite seną profilį, kol bus patvirtintas atkūrimas, tada panaikinkite pasenusius prisijungimo duomenis ten, kur jie iš tikrųjų administruojami. Palikti juos vietoje yra būdas, kuriuo senas kelias lieka naudingas dar ilgai po to, kai visi tiki, kad jis uždarytas.

Migracija taip pat yra momentas užrašyti, kam profilis buvo skirtas. Priešingu atveju kitas žmogus paveldi veikiantį ryšį be jokio paaiškinimo.

Patikrinkite sluoksnį, kliento versiją ir dabartinius operatoriaus reikalavimus. Tada nuspręskite, ar tai taisymas, ar pakeitimas.