MSCHAPv2 er ikke en VPN-protokoll: spør først om tunnelen

Brukernavn og passord reiser inne i en bærer, og MSCHAPv2 navngir bare metoden som reiser. Spør hvilken tunnel som bærer den, før du velger en klientprofil, for den samme kontostrengen dukker opp i oppsett som ikke deler én linje kode. Hver profil du får utlevert, koder begge beslutningene, selv når instruksjonsarket bare trykker den ene av dem. Rekkefølgen nedenfor er det en operatør kan svare på uten å gjette, og det du kan kontrollere uten å fange pakker.

Autentisering kjører inne i en tunnel

En VPN tar to beslutninger som ser ut som én: hvordan partene bygger en beskyttet kanal, og hvordan en person beviser identitet inne i den. Den andre trykkes på instruksjonsarket fordi det er den et menneske taster. Den første avgjør om noen klient i det hele tatt vil virke, og det er den folk hopper over. Be operatøren navngi bæreren og deretter metoden, i den rekkefølgen. To forbindelser kan kreve samme kontonavn og samme passord uten å dele noen implementasjon under innloggingsfeltet.

Derfor kan innstillinger kopiert fra en kollegas fungerende telefon feile på din, selv når serveren godtar begge legitimasjonene. Legitimasjonen var aldri forskjellen; profilen rundt den var det. begge sider har rett, og ingenting kobler seg til er som regel nettopp denne forvekslingen, og den klarer opp så snart bæreren er navngitt.

Tre steder der den samme metoden dukker opp

I PPP venter autentiseringstrinnet til det finnes en forbindelse, og RFC 2759 definerer MS-CHAPv2 som dette trinnet, derfor dukker metoden opp i L2TP og i eldre PPTP-utplasseringer. Tunnelen avsluttes først, og PPP-forhandlingen skjer inne i den, så et mislykket PPP-trinn kan etterlate tunnelen som etablert i serverloggen. Les de to trinnene hver for seg før du konkluderer med at legitimasjonen ble avvist. En klient som er satt opp for L2TP, kan altså være helt korrekt og likevel være feil klient for en gateway som bare snakker IKEv2.

IKEv2 legger i stedet EAP-MSCHAPv2 inne i nøkkelutvekslingen, så den samme legitimasjonen feiler på et annet tidspunkt og viser seg som en autentiseringsfeil i stedet for en sesjonsfeil. Android-plattformens IKEv2-profil er hverdagseksempelet, og den ber om et serversertifikat eller en identifikator i stedet for PPP-valg. Kontonavnet er identisk i begge oppsettene, så det kan ikke fortelle deg hvilket du har. Bare operatørens liste over støttede protokoller avgjør det.

En TLS-basert VPN legger til et tredje oppsett, med egne felt for brukernavn og passord og ingen MS-CHAPv2 noe sted i utvekslingen. Å se et passordfelt er derfor ikke bevis om protokollen bak det, for skjemaet er bygget for å se kjent ut. Bekreft protokollen fra serverdokumentasjonen, ikke fra formen på klientvinduet.

Svarene du faktisk trenger

Send forespørselen som en liste, for en liste er vanskelig å svare halvt på. Be om tunnelprotokollen, metoden inne i den og klienten operatøren støtter på plattformen din. Be deretter om gatewayens identitet og tillitsinnstillinger, kontoformatet og hva som skal være tilgjengelig når forbindelsen er oppe.

De tre første avgjør om du i det hele tatt får en fungerende profil. De tre siste avgjør om den profilen gjør det jobben trenger. Hold svaret vedlagt saken, for neste person vil stille de samme seks spørsmålene. Der et svar mangler, skal du behandle hullet som en beslutning operatøren ennå ikke har tatt, ikke som noe du kan utlede.

Ikke slakk på gateway-verifiseringen

Serveren beviser også sin identitet overfor klienten, og den halvdelen av utvekslingen er ikke pynt. Å slå av sertifikatverifisering for å få en sta profil til å koble seg til godtar ethvert endepunkt som svarer, også et ingen hadde til hensikt å nå. Det skjuler også et reelt avvik i stedet for å løse det, noe som skyver feilen til et senere og mindre tydelig tidspunkt. En profil som trenger kontrollen slått av, er en profil som peker på noe den ikke kan verifisere.

Avviket er som regel et navn, for et sertifikat utstedt for ett vertsnavn feiler når profilen ringer en adresse. Ring navnet i stedet for å slå av kontrollen. En privat sertifikatmyndighet feiler når enheten aldri fikk roten, og rettelsen er å distribuere den roten via den godkjente veien. Administrerte miljøer forventer at operatøren leverer identiteten og tillitsankeret, og at profilen refererer til begge. Når feltet mangler, be om artefakten i stedet for å melde deg ut av verifiseringen.

Tilpass profilen, og bevis deretter hvert trinn

Når bæreren er kjent, følg den klientens dokumenterte prosess og skriv bare inn feltene den ber om. Ekstrafelter som fylles ut fordi de finnes, er fortsatt feil verdier, og de feiler senere enn de obligatoriske. Lagre profilen uendret etter den første vellykkede forbindelsen, slik at en senere endring kan sammenlignes med noe som er kjent å virke.

Verifiser deretter i trinn: tunnelen etableres, brukeren autentiseres, den tildelte adressen og rutene vises, og én tillatt tjeneste svarer. Hvert trinn etterlater sin egen logglinje på serveren, og å lese dem i rekkefølge gjør en vag klage til et konkret funn. Hvis plattformen ikke lenger støtter oppsettet operatøren beskriver, er det en migreringssamtale og ikke en grunn til å slå på alle gamle valg på enheten. Bærer, metode og profil er tre separate svar, og en forbindelse som virker, har alle tre i samsvar.