MSCHAPv2 er ikkje ein VPN-protokoll: spør først om tunnelen
Eit passord og ordet MSCHAPv2 gir ikkje ei tilkopling. Spør kva tunnel som ber utvekslinga, og tilpass deretter klientprofilen til han.
Brukarnamn og passord reiser inne i ein berar, og MSCHAPv2 namngir berre metoden som reiser. Spør kva tunnel som ber han, før du vel ein klientprofil, for den same kontostrengen dukkar opp i oppsett som ikkje deler éi linje kode. Kvar profil du får utlevert, kodar begge avgjerdene, sjølv når instruksjonsarket berre trykkjer den eine av dei. Rekkjefølgja nedanfor er det ein operatør kan svare på utan å gjette, og det du kan kontrollere utan å fange pakkar.
Autentisering køyrer inne i ein tunnel
Ein VPN tek to avgjerder som ser ut som éi: korleis partane byggjer ein verna kanal, og korleis ein person beviser identitet inne i han. Den andre vert trykt på instruksjonsarket fordi det er den eit menneske tastar. Den første avgjer om nokon klient i det heile vil verke, og det er den folk hoppar over. Be operatøren namngi beraren og deretter metoden, i den rekkjefølgja. To tilkoplingar kan krevje same kontonamn og same passord utan å dele noka implementasjon under innloggingsfeltet.
Derfor kan innstillingar kopierte frå ein kollega sin fungerande telefon feile på din, sjølv når tenaren godtek begge legitimasjonane. Legitimasjonen var aldri skilnaden; profilen rundt han var det. at begge sider har rett, og ingenting koplar seg til er som regel nettopp denne forvekslinga, og ho klarer opp så snart beraren er namngitt.
Tre stader der den same metoden dukkar opp
I PPP ventar autentiseringstrinnet til det finst ei tilkopling, og RFC 2759 definerer MS-CHAPv2 som dette trinnet, derfor dukkar metoden opp i L2TP og i eldre PPTP-utplasseringar. Tunnelen vert avslutta først, og PPP-forhandlinga skjer inne i han, så eit mislukka PPP-trinn kan etterlate tunnelen som etablert i tenarloggen. Les dei to trinna kvar for seg før du konkluderer med at legitimasjonen vart avvist. Ein klient som er sett opp for L2TP, kan altså vere heilt korrekt og likevel vere feil klient for ein gateway som berre snakkar IKEv2.
IKEv2 legg i staden EAP-MSCHAPv2 inne i nøkkelutvekslinga, så den same legitimasjonen feilar på eit anna tidspunkt og viser seg som ein autentiseringsfeil i staden for ein sesjonsfeil. IKEv2-profilen til Android-plattforma er kvardagseksempelet, og han ber om eit tenarsertifikat eller ein identifikator i staden for PPP-val. Kontonamnet er identisk i begge oppsetta, så det kan ikkje fortelje deg kva du har. Berre lista til operatøren over støtta protokollar avgjer det.
Ein TLS-basert VPN legg til eit tredje oppsett, med eigne felt for brukarnamn og passord og ingen MS-CHAPv2 nokon stad i utvekslinga. Å sjå eit passordfelt er derfor ikkje bevis om protokollen bak det, for skjemaet er bygt for å sjå kjent ut. Stadfest protokollen frå tenardokumentasjonen, ikkje frå forma på klientvindauget.
Svara du faktisk treng
Send førespurnaden som ei liste, for ei liste er vanskeleg å svare halvt på. Be om tunnelprotokollen, metoden inne i han og klienten operatøren støttar på plattforma di. Be deretter om identiteten og tillitsinnstillingane til gatewayen, kontoformatet og kva som skal vere tilgjengeleg når tilkoplinga er oppe.
Dei tre første avgjer om du i det heile får ein fungerande profil. Dei tre siste avgjer om den profilen gjer det jobben treng. Hald svaret vedlagt saka, for neste person vil stille dei same seks spørsmåla. Der eit svar manglar, skal du handsame holet som ei avgjerd operatøren enno ikkje har teke, ikkje som noko du kan utleie.
| 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 |
Ikkje slakk på gateway-verifiseringa
Tenaren beviser også sin identitet overfor klienten, og den halvdelen av utvekslinga er ikkje pynt. Å slå av sertifikatverifisering for å få ein sta profil til å kople seg til godtek kvar einaste endepunkt som svarar, også eit ingen hadde til hensikt å nå. Det skjuler også eit reelt avvik i staden for å løyse det, noko som skyv feilen til eit seinare og mindre tydeleg tidspunkt. Ein profil som treng kontrollen slått av, er ein profil som peikar på noko han ikkje kan verifisere.
Avviket er som regel eit namn, for eit sertifikat utstedt for eitt vertsnamn feilar når profilen ringjer ei adresse. Ring namnet i staden for å slå av kontrollen. Ei privat sertifikatstyresmakt feilar når eininga aldri fekk rota, og rettinga er å distribuere den rota via den godkjende vegen. Styrte miljø ventar at operatøren leverer identiteten og tillitsankeret, og at profilen viser til begge. Når feltet manglar, be om artefakten i staden for å melde deg ut av verifiseringa.
Tilpass profilen, og prov deretter kvart trinn
Når beraren er kjend, følg den dokumenterte prosessen til den klienten og skriv berre inn felta han ber om. Ekstrafelt som vert fylte ut fordi dei finst, er framleis feil verdiar, og dei feilar seinare enn dei obligatoriske. Lagre profilen uendra etter den første vellukka tilkoplinga, slik at ei seinare endring kan samanliknast med noko som er kjent å verke.
Verifiser deretter i trinn: tunnelen vert etablert, brukaren vert autentisert, den tildelte adressa og rutene viser seg, og éin tillaten teneste svarar. Kvart trinn etterlet si eiga logglinje på tenaren, og å lese dei i rekkjefølgje gjer ei vag klage til eit konkret funn. Viss plattforma ikkje lenger støttar oppsettet operatøren skildrar, er det ein migrasjonssamtale og ikkje ein grunn til å slå på alle gamle val på eininga. Berar, metode og profil er tre separate svar, og ei tilkopling som verkar har alle tre i samsvar.