MSCHAPv2 ni protokol VPN: najprej vprašajte za tunel

Uporabniška imena in gesla potujejo znotraj nosilca, MSCHAPv2 pa poimenuje le metodo, ki potuje. Vprašajte, kateri tunel ga prenaša, preden izberete profil odjemalca, ker se ista veriga računa pojavi v postavitvah, ki si ne delijo niti vrstice kode. Vsak profil, ki ga dobite, kodira obe odločitvi, tudi ko navodilo natisne le eno od njiju. Vrstni red spodaj je tisto, na kar lahko operater odgovori brez ugibanja in kar lahko preverite brez zajemanja paketov.

Preverjanje pristnosti se pelje znotraj tunela

VPN sprejme dve odločitvi, ki izgledata kot ena: kako strani zgradita zaščiten kanal in kako oseba v njem dokaže identiteto. Druga je natisnjena na navodilu, ker jo vnaša človek. Prva odloči, ali bo sploh deloval kak odjemalec, in prav to ljudje preskočijo. Prosita operatorja, naj najprej poimenuje nosilec in nato metodo, v tem vrstnem redu. Dve povezavi lahko zahtevata isto ime računa in isto geslo, ne da bi si pod prijavnim poljem delili kakršno koli izvedbo.

Zato lahko nastavitve, kopirane s sodelavčevega delujočega telefona, na vašem spodletijo, tudi ko strežnik sprejme obe poverilnici. Poverilnica nikoli ni bila razlika; razlika je bil profil okoli nje. obe strani imata prav in nič se ne poveže je običajno prav ta zmešnjava in se razjasni takoj, ko je nosilec imenovan.

Tri mesta, kjer se pojavi ista metoda

V PPP korak preverjanja pristnosti čaka, dokler ne obstaja povezava, in RFC 2759 opredeli MS-CHAPv2 kot ta korak, zato se metoda pojavi v L2TP in v starejših namestitvah PPTP. Tunel se konča prvi, pogajanja PPP pa potekajo znotraj njega, zato lahko neuspešna faza PPP v dnevniku strežnika pusti tunel videti vzpostavljen. Berite ti dve fazi ločeno, preden zaključite, da so bile poverilnice zavrnjene. Odjemalec, nastavljen za L2TP, je torej lahko povsem pravilen in vseeno napačen odjemalec za prehod, ki govori samo IKEv2.

IKEv2 namesto tega postavi EAP-MSCHAPv2 v izmenjavo ključev, zato ista poverilnica spodleti v drugem trenutku in se pokaže kot napaka preverjanja pristnosti namesto kot napaka seje. Profil IKEv2 platforme Android je vsakdanji primer in zahteva potrdilo ali identifikator strežnika namesto možnosti PPP. Ime računa je v obeh postavitvah enako, zato vam ne more povedati, katero imate. To odloči le operaterjev seznam podprtih protokolov.

VPN na osnovi TLS doda tretjo postavitev, z lastnimi polji za uporabniško ime in geslo in brez MS-CHAPv2 kjer koli v izmenjavi. Vidno polje za geslo torej ni dokaz o protokolu za njim, ker je obrazec zgrajen tako, da izgleda znano. Protokol potrdite iz dokumentacije strežnika, ne iz oblike okna odjemalca.

Odgovori, ki jih v resnici potrebujete

Pošljite zahtevo kot seznam, ker je na seznam težko odgovoriti na pol. Zahtevajte protokol tunela, metodo v njem in odjemalca, ki ga operater podpira na vaši platformi. Nato zahtevajte identiteto in nastavitve zaupanja prehoda, obliko računa in kaj naj bo dosegljivo, ko je povezava vzpostavljena.

Prve tri odločijo, ali sploh dobite delujoč profil. Zadnje tri odločijo, ali ta profil počne to, kar delo potrebuje. Hranite odgovor priložen k zahtevku, ker bo naslednja oseba postavila istih šest vprašanj. Kjer odgovora ni, obravnavajte vrzel kot odločitev, ki se je operater še ni lotil, ne kot nekaj, kar lahko sklepate sami.

Ne popuščajte pri preverjanju prehoda

Strežnik dokaže svojo identiteto tudi odjemalcu in ta polovica izmenjave ni okras. Izklop preverjanja potrdila, da bi se trmast profil povezal, sprejme vsako končno točko, ki odgovori, tudi tisto, do katere ni nihče nameraval priti. Prav tako skrije resnično neujemanje, namesto da bi ga rešilo, kar potisne napako v poznejši in manj očiten trenutek. Profil, ki potrebuje izklopljeno preverjanje, kaže na nekaj, česar ne more preveriti.

Neujemanje je običajno ime, ker potrdilo, izdano za eno ime gostitelja, spodleti, ko profil pokliče naslov. Pokličite ime, namesto da izklopite preverjanje. Zasebni potrditveni organ spodleti, ko naprava nikoli ni dobila korena, popravek pa je, da ta koren razširite po odobreni poti. Upravljana okolja pričakujejo, da operater zagotovi identiteto in sidro zaupanja, profil pa se sklicuje na oboje. Ko polja ni, zahtevajte artefakt, namesto da se odpoveste preverjanju.

Prilagodite profil in nato dokažite vsako fazo

Ko je nosilec znan, sledite dokumentiranemu postopku tega odjemalca in vnesite le polja, ki jih zahteva. Dodatna polja, izpolnjena zato, ker obstajajo, so še vedno napačne vrednosti in spodletijo pozneje kot obvezna. Shranite profil nespremenjen po prvi uspešni povezavi, da bo poznejši popravek mogoče primerjati z nečim, za kar je znano, da deluje.

Nato preverjajte po fazah: tunel se vzpostavi, uporabnik se preveri, pojavita se dodeljeni naslov in poti ter ena dovoljena storitev odgovori. Vsaka faza pusti na strežniku svojo vrstico dnevnika in branje po vrsti spremeni nejasno pritožbo v konkretno ugotovitev. Če platforma ne podpira več postavitve, ki jo opisuje operater, je to pogovor o selitvi in ne razlog, da v napravi vklopite vse stare možnosti. Nosilec, metoda in profil so tri ločeni odgovori, povezava, ki deluje, pa ima vse tri usklajene.