Az MSCHAPv2 nem VPN-protokoll: először a tunelről kérdezzen

A felhasználónevek és jelszavak egy hordozó belsejében utaznak, és az MSCHAPv2 csak az utazó módszert nevezi meg. Kérdezze meg, melyik tunel hordozza, mielőtt ügyfélprofilt választ, mert ugyanaz a fiók-karakterlánc olyan elrendezésekben is megjelenik, amelyek egyetlen kódsort sem osztanak meg. Minden profil, amelyet kap, mindkét döntést kódolja, akkor is, ha az útmutató csak az egyiket nyomtatja ki. Az alábbi sorrend az, amire egy üzemeltető tippelés nélkül válaszolni tud, és amit Ön csomagrögzítés nélkül ellenőrizni tud.

A hitelesítés egy tunel belsejében utazik

Egy VPN két döntést hoz, amelyek egynek látszanak: hogyan építenek a felek védett csatornát, és hogyan bizonyítja egy ember a személyazonosságát benne. A másodikat az útmutatóra nyomtatják, mert azt gépeli be az ember. Az első dönti el, hogy egyáltalán működik-e bármelyik ügyfél, és éppen ezt hagyják ki az emberek. Kérje meg az üzemeltetőt, hogy először a hordozót, majd a módszert nevezze meg, ebben a sorrendben. Két kapcsolat ugyanazt a fióknevet és ugyanazt a jelszót kérheti, miközben a bejelentkező mező alatt semmilyen megvalósítást nem osztanak meg.

Ezért a kolléga működő telefonjáról másolt beállítások az Önében meghiúsulhatnak, akkor is, ha a kiszolgáló mindkét hitelesítő adatot elfogadja. A hitelesítő adat soha nem volt a különbség; a köré tekert profil volt az. mindkét félnek igaza van, és semmi nem kapcsolódik általában pont ez a zavar, és azonnal tisztázódik, amint a hordozót megnevezik.

Három hely, ahol ugyanaz a módszer megjelenik

A PPP-ben a hitelesítési lépés addig vár, amíg létezik egy kapcsolat, és RFC 2759 az MS-CHAPv2-t erre a lépésre határozza meg, ezért a módszer megjelenik a L2TP és a régebbi PPTP-telepítésekben. A tunel előbb végződik, és a PPP-tárgyalás benne történik, így egy sikertelen PPP-szakasz a tunelt létrehozottként hagyhatja a kiszolgáló naplójában. Olvassa ezt a két szakaszt külön, mielőtt arra jut, hogy a hitelesítő adatokat elutasították. Egy L2TP-re beállított ügyfél tehát teljesen helyes lehet, és mégis a rossz ügyfél egy olyan átjáróhoz, amely csak IKEv2-t beszél.

IKEv2 ehelyett az EAP-MSCHAPv2-t a kulcscsere belsejébe teszi, így ugyanaz a hitelesítő adat más pillanatban hiúsul meg, és hitelesítési hibaként jelenik meg munkamenet-hiba helyett. Az Android platform IKEv2-profilja a mindennapi példa, és PPP-beállítások helyett kiszolgáló-tanúsítványt vagy azonosítót kér. A fióknév mindkét elrendezésben azonos, tehát nem tudja megmondani, melyik van Önnél. Ezt csak az üzemeltető támogatott protokolljainak listája dönti el.

Egy TLS-alapú VPN harmadik elrendezést ad hozzá, saját felhasználónév- és jelszómezőkkel, és az eszmecsere sehol nem tartalmaz MS-CHAPv2-t. Jelszómezőt látni tehát nem bizonyíték a mögötte lévő protokollról, mert az űrlapot ismerősnek látszani építették. A protokollt a kiszolgáló dokumentációjából erősítse meg, ne az ügyfélablak formájából.

A válaszok, amelyekre valóban szüksége van

Listaként küldje el a kérést, mert egy listát nehéz félúton megválaszolni. Kérje a tunel protokollját, a benne lévő módszert és azt az ügyfelet, amelyet az üzemeltető az Ön platformján támogat. Aztán kérje az átjáró azonosságát és bizalmi beállításait, a fiók formátumát, és azt, hogy minek kell elérhetőnek lennie a kapcsolat felállása után.

Az első három eldönti, hogy egyáltalán kap-e működő profilt. Az utolsó három eldönti, hogy az a profil azt teszi-e, amire a munkának szüksége van. Tartsa a választ a jegy mellett, mert a következő ember ugyanezt a hat kérdést fogja feltenni. Ahol hiányzik egy válasz, kezelje a hiányt olyan döntésként, amelyet az üzemeltető még nem hozott meg, ne olyanként, amit Ön kikövetkeztethet.

Ne lazítsa az átjáró ellenőrzését

A kiszolgáló az ügyfél felé is bizonyítja az azonosságát, és az eszmecsere ezen fele nem díszítés. A tanúsítvány-ellenőrzés kikapcsolása, hogy egy makacs profil csatlakozzon, minden válaszoló végpontot elfogad, beleértve olyat is, ahová senki nem akart eljutni. Elrejti a valódi eltérést ahelyett, hogy megoldaná, ami a hibát későbbi és kevésbé nyilvánvaló pillanatra tolja. Az a profil, amelynek kikapcsolt ellenőrzés kell, olyan dologra mutat, amit nem tud ellenőrizni.

Az eltérés általában név, mert az egy hosztnévre kiállított tanúsítvány meghiúsul, amikor a profil címet tárcsáz. A nevet tárcsázza, ne az ellenőrzést kapcsolja ki. Egy magán tanúsítványhatóság meghiúsul, ha az eszköz soha nem kapta meg a gyökeret, és a javítás az, hogy ezt a gyökeret a jóváhagyott úton terjesszék. A felügyelt környezetek elvárják, hogy az üzemeltető adja az azonosságot és a bizalmi horgonyt, a profil pedig mindkettőre hivatkozzon. Ha a mező hiányzik, kérje az artefaktumot, ne mondjon le az ellenőrzésről.

Igazítsa a profilt, majd bizonyítsa minden szakaszt

Amint a hordozó ismert, kövesse annak az ügyfélnek a dokumentált folyamatát, és csak az általa kért mezőket töltse ki. A további mezők, amelyeket azért töltenek ki, mert léteznek, továbbra is hibás értékek, és később hiúsulnak meg, mint a kötelezők. A profilt változatlanul mentse el az első sikeres kapcsolat után, hogy egy későbbi módosítás összevethető legyen valamivel, amiről tudott, hogy működik.

Azután szakaszonként ellenőrizzen: a tunel felépül, a felhasználó hitelesítődik, megjelenik a kiosztott cím és az útvonalak, és egy engedélyezett szolgáltatás válaszol. Minden szakasz a saját naplósorát hagyja a kiszolgálón, és ezek sorrendben olvasása homályos panaszt konkrét megállapítássá alakít. Ha a platform már nem támogatja az üzemeltető által leírt elrendezést, az áttelepítési beszélgetés, nem pedig ok arra, hogy az eszközön minden régi beállítást bekapcsoljon. A hordozó, a módszer és a profil három külön válasz, és egy működő kapcsolatban mindhárom összhangban van.