MSCHAPv2 er ikke en VPN-protokol: spørg efter tunnelen først

Brugernavne og adgangskoder rejser inde i en bærer, og MSCHAPv2 navngiver kun den metode, der rejser. Spørg, hvilken tunnel der bærer den, før du vælger en klientprofil, for den samme kontostreng optræder i opsætninger, der ikke deler én linje kode. Hver profil, du får udleveret, koder begge beslutninger, også når instruktionsarket kun trykker den ene af dem. Rækkefølgen nedenfor er det, en operatør kan svare på uden at gætte, og det, du kan kontrollere uden at fange pakker.

Godkendelse kører inde i en tunnel

En VPN træffer to beslutninger, der ligner én: hvordan parterne bygger en beskyttet kanal, og hvordan en person beviser identitet inde i den. Den anden står trykt på instruktionsarket, fordi det er den, et menneske taster. Den første afgør, om overhovedet nogen klient vil virke, og det er den, folk springer over. Bed operatøren om at navngive bæreren og derefter metoden, i den rækkefølge. To forbindelser kan kræve samme kontonavn og samme adgangskode uden at dele nogen implementering under loginfeltet.

Derfor kan indstillinger kopieret fra en kollegas fungerende telefon fejle på din, selv når serveren accepterer begge legitimationsoplysninger. Legitimationsoplysningen var aldrig forskellen; profilen omkring den var. begge sider har ret, og intet forbinder er som regel netop denne forveksling, og den klarer op, så snart bæreren navngives.

Tre steder hvor den samme metode dukker op

I PPP venter godkendelsestrinnet, til der findes en forbindelse, og RFC 2759 definerer MS-CHAPv2 som dette trin, og derfor dukker metoden op i L2TP og i ældre PPTP-opsætninger. Tunnelen afsluttes først, og PPP-forhandlingen foregår inde i den, så et mislykket PPP-trin kan efterlade tunnelen som etableret i serverloggen. Læs de to trin hver for sig, før du konkluderer, at legitimationsoplysningerne blev afvist. En klient, der er sat op til L2TP, kan altså være helt korrekt og stadig være den forkerte klient til en gateway, der kun taler IKEv2.

IKEv2 lægger i stedet EAP-MSCHAPv2 inde i nøgleudvekslingen, så den samme legitimationsoplysning fejler på et andet tidspunkt og viser sig som en godkendelsesfejl frem for en sessionsfejl. Androids platform-IKEv2-profil er det daglige eksempel, og den beder om et servercertifikat eller en identifikator frem for PPP-indstillinger. Kontonavnet er identisk i begge opsætninger, så det kan ikke fortælle dig, hvilken du har. Kun operatørens liste over understøttede protokoller afgør det.

En TLS-baseret VPN tilføjer en tredje opsætning med egne brugernavn- og adgangskodefelter og ingen MS-CHAPv2 noget sted i udvekslingen. At se et adgangskodefelt er derfor intet bevis om protokollen bag det, for formularen er bygget til at se velkendt ud. Bekræft protokollen ud fra serverdokumentationen, ikke ud fra klientvinduets form.

De svar, du faktisk har brug for

Send anmodningen som en liste, for en liste er svær at svare halvt på. Bed om tunnelprotokollen, metoden inde i den og den klient, operatøren understøtter på din platform. Bed derefter om gatewayens identitet og tillidsindstillinger, kontoformatet og hvad der skal kunne nås, når forbindelsen er oppe.

De første tre afgør, om du overhovedet får en fungerende profil. De sidste tre afgør, om den profil gør det, arbejdet kræver. Hold svaret vedhæftet sagen, for den næste person vil stille de samme seks spørgsmål. Hvor et svar mangler, skal du behandle hullet som en beslutning, operatøren endnu ikke har taget, ikke som noget, du kan udlede.

Slæk ikke på gatewayverificeringen

Serveren beviser også sin identitet over for klienten, og den halvdel af udvekslingen er ikke pynt. At slå certifikatverificering fra for at få en genstridig profil til at forbinde accepterer ethvert endepunkt, der svarer, også et som ingen havde til hensigt at nå. Det skjuler også en reel uoverensstemmelse i stedet for at løse den, hvilket skubber fejlen til et senere og mindre tydeligt tidspunkt. En profil, der kræver kontrollen slået fra, er en profil, der peger på noget, den ikke kan verificere.

Uoverensstemmelsen er som regel et navn, for et certifikat udstedt til ét værtsnavn fejler, når profilen ringer til en adresse. Ring til navnet i stedet for at slå kontrollen fra. En privat certifikatmyndighed fejler, når enheden aldrig har fået roden, og rettelsen er at distribuere den rod ad den godkendte vej. Administrerede miljøer forventer, at operatøren leverer identiteten og tillidsankeret, og at profilen refererer til begge. Når feltet mangler, skal du bede om artefakten i stedet for at melde dig ud af verifikationen.

Tilpas profilen, og bevis derefter hvert trin

Når bæreren er kendt, følg den klients dokumenterede proces, og indtast kun de felter, den beder om. Ekstra felter, der udfyldes, fordi de findes, er stadig forkerte værdier, og de fejler senere end de krævede. Gem profilen uændret efter den første vellykkede forbindelse, så en senere ændring kan sammenlignes med noget, der vides at virke.

Verificér derefter i trin: tunnelen etableres, brugeren godkendes, den tildelte adresse og ruter vises, og én tilladt tjeneste svarer. Hvert trin efterlader sin egen loglinje på serveren, og at læse dem i rækkefølge gør en vag klage til en konkret konstatering. Hvis platformen ikke længere understøtter den opsætning, operatøren beskriver, er det en migreringssamtale og ikke en grund til at slå alle gamle valgmuligheder til på enheden. Bærer, metode og profil er tre separate svar, og en forbindelse, der virker, har alle tre i overensstemmelse.