Az L2TP-profil melyik rétege hibázott valójában
Az IPsec-egyeztetés, az L2TP-vezérlés, a PPP-hitelesítés és a címkiosztás másképp hibázik. Határozza meg a réteget, mielőtt minden régi beállítást engedélyez.
A verem mentén haladjon lefelé, ne a beállítási oldalon keresztül: IPsec-egyeztetés, majd L2TP-vezérlés, majd PPP-hitelesítés, majd cím- és DNS-kiosztás. Minden rétegnek megvan a maga hiba-aláírása és a maga valószínű oka. Az a profil, amely a felhasználói hitelesítésnél hibázik, már három ellenőrzésen jutott túl, amelyekhez egy korábban lejárt profil soha nem ért el. Ezt a sorrendet kell először megállapítani.
Ugyanaz a protokollnév négy különböző beszélgetést rejt.
Nevezze meg a réteget, mielőtt beállításokat módosít
Ha az IPsec beállítása hibázik, az a közös titokra, az algoritmusokra vagy a partner azonosságára utal. Ha utána az L2TP-vezérlés hibázik, az magára az alagút-rétegre utal, ami szűkebb probléma. A PPP-hitelesítés hibái a fiókot vagy a hitelesítési módszert nevezik meg. A hitelesítés utáni cím- vagy DNS-hiba azt jelenti, hogy az átvitel működött, a konfigurációcserélés pedig nem.
Jegyezze fel a kliens verzióját, az operációs rendszer verzióját és az üzemeltető dokumentált beállítását. E három nélkül minden változtatás találgatás, amely véletlenül valami mást is megjavíthat.
Hasonlítsa össze a profilt a jelenlegi klienssel
Egy mentett profil olyan közös titkot, hitelesítési beállítást vagy végpontot hordozhat, amelyet a jelenlegi kliens már nem fogad el. Egyes platformok teljesen visszavonták vagy eltávolították az L2TP/IPsec támogatását, és egy frissített kliens a szerveren végzett bármilyen változtatás nélkül elhagyhatja a régi IKE-viselkedést. Hasonlítsa össze mentett értékeit az üzemeltető jelenlegi dokumentált követelményeivel, ne azzal, ami egy éve működött. A két dokumentum közötti különbség általában az a hely, ahol a válasz van.
A gyorsítótárazott titok vagy az átnevezett fiók általában nem igényel többet egy szokásos profilfrissítésnél, és mindkettőt érdemes ellenőrizni, mielőtt bármit újratervezne. Ezek az olcsó javítások, és ezeket ki kell zárni minden architekturális munka előtt.
A régi beállítások nem jönnek vissza azzal, hogy engedélyezi őket
Az ellenőrzés kikapcsolása nem javítja a bizalmi lánc problémáját, és egy algoritmus engedélyezése csak azért, mert egy fórumtéma említi, semmit sem bizonyít arról, mit fogad el a szerver. A gyenge IKE-javaslatokat általában jó okból távolítják el a kliensekből, és egyikük újraengedélyezése rosszabb kapcsolatot hoz létre, mint amelyik elromlott. A gyengébb alagút nem javítás, hanem új probléma ugyanazzal a tünettel. A helyes kérdés az, mit támogat most az üzemeltető.
A mindent engedélyező javítás sokkal többet változtat a tényleges hibánál, és nem tudja megmondani, mi javította meg.
Mutassa be a migrációt projektként
Ha a telepítés már nem támogatja a szükséges klienst, tervezzen cserét az üzemeltetővel, ahelyett hogy dokumentálatlan kivételt őrizne meg. Vigye át a hozzáférési követelményt, az azonosságokat, a DNS-bejegyzéseket és az útvonalakat, mert egy új kézfogás önmagában egyiket sem hozza létre újra ezek közül az engedélyek közül. Ezek azok a részek, amelyeken egy működő kapcsolat csendben nyugodott. Tartsa biztonságban a régi profilt, amíg a helyreállítás megerősítést nem nyer, majd vonja vissza az elavult hitelesítő adatokat ott, ahol valóban kezelik őket. A helyükön hagyásuk az az út, amelyen egy régi ösvény még sokáig használható marad azután, hogy mindenki hiszi, bezárták.
A migráció az a pillanat is, amikor le kell írni, mire való volt a profil. Különben a következő ember magyarázat nélkül örököl egy működő kapcsolatot.
Ellenőrizze a réteget, a kliens verzióját és az üzemeltető jelenlegi követelményeit. Utána döntse el, javításról vagy cseréről van-e szó.