MSCHAPv2 är inte ett VPN-protokoll: fråga först om tunneln

Användarnamn och lösenord reser inuti en bärare, och MSCHAPv2 namnger bara den metod som reser. Fråga vilken tunnel som bär den innan du väljer en klientprofil, för samma kontosträng dyker upp i uppsättningar som inte delar en enda rad kod. Varje profil du får kodar båda besluten, även när instruktionsbladet bara trycker ett av dem. Ordningen nedan är vad en operatör kan svara på utan att gissa och vad du kan kontrollera utan att fånga paket.

Autentisering åker inuti en tunnel

En VPN fattar två beslut som ser ut som ett: hur parterna bygger en skyddad kanal och hur en person bevisar identitet inuti den. Det andra trycks på instruktionsbladet eftersom det är det en människa skriver in. Det första avgör om någon klient alls kommer att fungera, och det är det folk hoppar över. Be operatören namnge bäraren och sedan metoden, i den ordningen. Två anslutningar kan kräva samma kontonamn och samma lösenord utan att dela någon implementation under inloggningsfältet.

Därför kan inställningar som kopierats från en kollegas fungerande telefon misslyckas på din, även när servern accepterar båda uppgifterna. Uppgiften var aldrig skillnaden; profilen runtomkring var det. båda sidor har rätt och ingenting ansluter är oftast precis den här förväxlingen, och den klarnar så snart bäraren namnges.

Tre ställen där samma metod dyker upp

I PPP väntar autentiseringssteget tills det finns en förbindelse, och RFC 2759 definierar MS-CHAPv2 som det steget, därför dyker metoden upp i L2TP och i äldre PPTP-installationer. Tunneln avslutas först och PPP-förhandlingen sker inuti den, så ett misslyckat PPP-steg kan lämna tunneln som etablerad i serverns logg. Läs de två stegen var för sig innan du drar slutsatsen att uppgifterna avvisades. En klient som är inställd för L2TP kan alltså vara helt korrekt och ändå vara fel klient för en gateway som bara talar IKEv2.

IKEv2 lägger i stället EAP-MSCHAPv2 inuti nyckelutbytet, så samma uppgift misslyckas vid ett annat tillfälle och visar sig som ett autentiseringsfel i stället för ett sessionsfel. Android-plattformens IKEv2-profil är vardagsexemplet, och den begär ett servercertifikat eller en identifierare i stället för PPP-alternativ. Kontonamnet är identiskt i båda uppsättningarna, så det kan inte säga vilket du har. Bara operatörens lista över protokoll som stöds avgör det.

En TLS-baserad VPN lägger till en tredje uppsättning, med egna fält för användarnamn och lösenord och ingen MS-CHAPv2 någonstans i utbytet. Att se ett lösenordsfält är därför inget bevis om protokollet bakom, eftersom formuläret är byggt för att se bekant ut. Bekräfta protokollet från serverns dokumentation, inte från klientfönstrets form.

Svaren du faktiskt behöver

Skicka begäran som en lista, för en lista är svår att svara på till hälften. Be om tunnelprotokollet, metoden inuti den och den klient som operatören stöder på din plattform. Be sedan om gatewayens identitet och förtroendeinställningar, kontoformatet och vad som ska gå att nå när anslutningen är uppe.

De första tre avgör om du alls får en fungerande profil. De tre sista avgör om den profilen gör det jobbet kräver. Håll svaret bifogat ärendet, för nästa person kommer att ställa samma sex frågor. Där ett svar saknas ska du behandla luckan som ett beslut operatören ännu inte har fattat, inte som något du kan härleda.

Släpp inte efter på gateway-verifieringen

Servern bevisar också sin identitet för klienten, och den halvan av utbytet är inte dekoration. Att stänga av certifikatverifieringen för att en envis profil ska ansluta accepterar vilken slutpunkt som helst som svarar, även en som ingen avsåg att nå. Det döljer också en verklig avvikelse i stället för att lösa den, vilket skjuter felet till ett senare och mindre uppenbart ögonblick. En profil som behöver kontrollen avstängd är en profil som pekar på något den inte kan verifiera.

Avvikelsen är oftast ett namn, för ett certifikat utfärdat för ett värdnamn misslyckas när profilen ringer en adress. Ring namnet i stället för att stänga av kontrollen. En privat certifikatutfärdare misslyckas när enheten aldrig fick roten, och rättelsen är att distribuera den roten via den godkända vägen. Hanterade miljöer förväntar sig att operatören tillhandahåller identiteten och förtroendeankaret, och att profilen hänvisar till båda. När fältet saknas, be om artefakten i stället för att avstå från verifieringen.

Anpassa profilen och bevisa sedan varje steg

När bäraren är känd följer du den klientens dokumenterade process och fyller bara i de fält den begär. Extra fält som fylls i därför att de finns är fortfarande fel värden, och de misslyckas senare än de obligatoriska. Spara profilen oförändrad efter den första lyckade anslutningen, så att en senare ändring kan jämföras med något som är känt att fungera.

Verifiera sedan i steg: tunneln etableras, användaren autentiseras, den tilldelade adressen och rutterna visas, och en tillåten tjänst svarar. Varje steg lämnar sin egen loggrada på servern, och att läsa dem i ordning gör ett vagt klagomål till ett konkret fynd. Om plattformen inte längre stöder den uppsättning operatören beskriver är det ett migreringssamtal och inte en anledning att slå på alla gamla alternativ på enheten. Bärare, metod och profil är tre separata svar, och en anslutning som fungerar har alla tre i samklang.