MSCHAPv2 nėra VPN protokolas: pirmiausia paklauskite apie tunelį
Slaptažodis ir žodis MSCHAPv2 dar nesudaro ryšio. Paklauskite, kuris tunelis neša mainus, tada priderinkite kliento profilį prie jo.
Vartotojų vardai ir slaptažodžiai keliauja nešiklio viduje, o MSCHAPv2 tik įvardija keliaujantį metodą. Paklauskite, kuris tunelis jį neša, prieš rinkdamiesi kliento profilį, nes ta pati paskyros eilutė pasitaiko išdėstymuose, kurie nesidalija nė viena kodo eilute. Kiekvienas jums duotas profilis užkoduoja abu sprendimus, net kai instrukcijų lapas atspausdina tik vieną jų. Žemiau pateikta tvarka yra tai, į ką operatorius gali atsakyti nespėliodamas, ir tai, ką jūs galite patikrinti nepagavę paketų.
Autentifikavimas važiuoja tunelio viduje
VPN priima du sprendimus, kurie atrodo kaip vienas: kaip šalys stato apsaugotą kanalą ir kaip žmogus jame įrodo tapatybę. Antrasis atspausdinamas instrukcijų lape, nes jį įveda žmogus. Pirmasis nusprendžia, ar apskritai veiks koks nors klientas, ir būtent jį žmonės praleidžia. Paprašykite operatoriaus pirmiausia įvardyti nešiklį, o paskui metodą, būtent tokia tvarka. Du ryšiai gali reikalauti to paties paskyros vardo ir to paties slaptažodžio, tačiau po prisijungimo lauku nesidalyti jokia implementacija.
Todėl nustatymai, nukopijuoti iš kolegos veikiančio telefono, gali nepavykti jūsų telefone, net kai serveris priima abu prisijungimo duomenis. Skirtumas niekada nebuvo prisijungimo duomenys; juo buvo juos apgaubiantis profilis. abi pusės teisios, o niekas nesijungia paprastai yra būtent ši painiava, ir ji išsiaiškėja vos įvardijus nešiklį.
Trys vietos, kur pasirodo tas pats metodas
PPP atveju autentifikavimo žingsnis laukia, kol atsiras jungtis, o RFC 2759 apibrėžia MS-CHAPv2 kaip tą žingsnį, todėl metodas pasirodo L2TP ir senesniuose PPTP diegimuose. Tunelis baigiasi pirmas, o PPP derybos vyksta jo viduje, tad nepavykęs PPP etapas serverio žurnale gali palikti tunelį atrodantį kaip sukurtą. Skaitykite tuos du etapus atskirai, prieš darydami išvadą, kad prisijungimo duomenys atmesti. Taigi klientas, sukonfigūruotas L2TP, gali būti visiškai teisingas ir vis tiek būti netinkamas klientas šliuzui, kuris kalba tik IKEv2.
IKEv2 vietoj to įdeda EAP-MSCHAPv2 į raktų mainus, tad tie patys prisijungimo duomenys nepavyksta kitu momentu ir pasirodo kaip autentifikavimo klaida, o ne sesijos klaida. Android platformos IKEv2 profilis yra kasdienis pavyzdys, ir jis prašo serverio sertifikato arba identifikatoriaus, o ne PPP parinkčių. Paskyros vardas abiejuose išdėstymuose yra identiškas, tad jis negali pasakyti, kurį turite. Tai nusprendžia tik operatoriaus palaikomų protokolų sąrašas.
TLS pagrindu veikiantis VPN prideda trečią išdėstymą, su savo vartotojo vardo ir slaptažodžio laukais ir be MS-CHAPv2 bet kur mainuose. Todėl slaptažodžio lauko matymas nėra įrodymas apie protokolą už jo, nes forma pastatyta atrodyti pažįstamai. Patvirtinkite protokolą iš serverio dokumentacijos, o ne iš kliento lango formos.
Atsakymai, kurių jums iš tikrųjų reikia
Siųskite prašymą kaip sąrašą, nes į sąrašą sunku atsakyti pusiau. Paprašykite tunelio protokolo, metodo jo viduje ir kliento, kurį operatorius palaiko jūsų platformoje. Tada paprašykite šliuzo tapatybės ir pasitikėjimo nustatymų, paskyros formato ir to, kas turėtų būti pasiekiama, kai ryšys bus užmegztas.
Pirmieji trys nusprendžia, ar apskritai gausite veikiantį profilį. Paskutiniai trys nusprendžia, ar tas profilis daro tai, ko reikia darbui. Laikykite atsakymą prisegtą prie bilieto, nes kitas žmogus užduos tuos pačius šešis klausimus. Kur atsakymo nėra, tą spragą traktuokite kaip operatoriaus dar nepriimtą sprendimą, o ne kaip tai, ką galite numanyti.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
Nesusilpninkite šliuzo tikrinimo
Serveris taip pat įrodo savo tapatybę klientui, ir ši mainų pusė nėra puošmena. Išjungti sertifikato tikrinimą, kad užsispyręs profilis prisijungtų, reiškia priimti bet kurį atsakančią galinį tašką, įskaitant tą, į kurį niekas neketino patekti. Tai taip pat paslepia tikrą neatitikimą, užuot jį išsprendus, o tai nustumia gedimą į vėlesnį ir mažiau akivaizdų momentą. Profilis, kuriam reikia išjungto tikrinimo, rodo į tai, ko negali patikrinti.
Neatitikimas paprastai yra vardas, nes sertifikatas, išduotas vienam pagrindinio kompiuterio vardui, nepavyksta, kai profilis renkasi adresą. Rinkitės vardą, o ne išjunkite tikrinimą. Privati sertifikatų tarnyba nepavyksta, kai įrenginiui niekada nebuvo duota šaknis, o pataisa yra paskirstyti tą šaknį patvirtintu keliu. Valdomos aplinkos tikisi, kad operatorius pateiks tapatybę ir pasitikėjimo inkarą, o profilis nurodys abu. Kai lauko nėra, paprašykite artefakto, o ne atsisakykite tikrinimo.
Priderinkite profilį, tada įrodykite kiekvieną etapą
Kai nešiklis žinomas, vadovaukitės dokumentuotu to kliento procesu ir įveskite tik tuos laukus, kurių jis prašo. Papildomi laukai, užpildyti todėl, kad jie yra, vis tiek yra neteisingos reikšmės, ir jie nepavyksta vėliau nei privalomi. Išsaugokite profilį nepakeistą po pirmojo sėkmingo prisijungimo, kad vėlesnis redagavimas būtų lyginamas su tuo, kas žinoma, jog veikia.
Tada tikrinkite etapais: tunelis užmezgamas, vartotojas autentifikuojamas, pasirodo priskirtas adresas ir maršrutai, ir atsako viena leidžiama paslauga. Kiekvienas etapas palieka savo žurnalo eilutę serveryje, o jų skaitymas iš eilės neaiškią nusiskundimą paverčia konkrečiu radiniu. Jei platforma nebepalaiko operatoriaus aprašyto išdėstymo, tai pokalbis apie migraciją, o ne priežastis įjungti visus senus variantus įrenginyje. Nešiklis, metodas ir profilis yra trys atskiri atsakymai, o veikiančiame ryšyje visi trys sutampa.