MSCHAPv2 is geen VPN-protocol: vraag eerst naar de tunnel

Gebruikersnamen en wachtwoorden reizen in een drager, en MSCHAPv2 noemt alleen de methode die reist. Vraag welke tunnel die draagt voordat u een clientprofiel kiest, want dezelfde accountreeks duikt op in opstellingen die geen regel code delen. Elk profiel dat u krijgt codeert beide beslissingen, ook wanneer het instructieblad er maar één van afdrukt. De volgorde hieronder is wat een operator zonder gokken kan beantwoorden en wat u zonder packet capture kunt controleren.

Authenticatie rijdt in een tunnel

Een VPN neemt twee beslissingen die op één lijken: hoe de partijen een beschermd kanaal bouwen en hoe iemand daarin identiteit bewijst. De tweede staat op het instructieblad omdat een mens die intypt. De eerste bepaalt of überhaupt een client werkt, en juist die slaan mensen over. Vraag de operator eerst de drager en dan de methode te noemen, in die volgorde. Twee verbindingen kunnen dezelfde accountnaam en hetzelfde wachtwoord eisen zonder onder het inlogveld enige implementatie te delen.

Daarom kunnen instellingen die van de werkende telefoon van een collega zijn gekopieerd op de uwe mislukken, zelfs wanneer de server beide inloggegevens accepteert. Het inloggegeven was nooit het verschil; het profiel eromheen was dat. beide kanten gelijk hebben en niets verbindt is meestal precies deze verwarring, en die klaart op zodra de drager is genoemd.

Drie plekken waar dezelfde methode opduikt

In PPP wacht de authenticatiestap tot er een verbinding is, en RFC 2759 definieert MS-CHAPv2 als die stap, daarom duikt de methode op in L2TP en in oudere PPTP-implementaties. De tunnel eindigt eerst en de PPP-onderhandeling gebeurt erbinnen, dus een mislukte PPP-fase kan de tunnel in het serverlog als opgezet achterlaten. Lees die twee fasen apart voordat u concludeert dat de inloggegevens zijn geweigerd. Een client die voor L2TP is ingesteld kan dus volledig correct zijn en toch de verkeerde client zijn voor een gateway die alleen IKEv2 spreekt.

IKEv2 legt EAP-MSCHAPv2 in plaats daarvan in de sleuteluitwisseling, dus dezelfde inloggegevens falen op een ander moment en komen naar voren als authenticatiefout in plaats van sessiefout. Het IKEv2-profiel van het Android-platform is het dagelijkse voorbeeld, en het vraagt om een servercertificaat of identificatie in plaats van PPP-opties. De accountnaam is in beide opstellingen identiek, dus die kan u niet vertellen welke u hebt. Alleen de lijst met ondersteunde protocollen van de operator beslist dat.

Een op TLS gebaseerde VPN voegt een derde opstelling toe, met eigen velden voor gebruikersnaam en wachtwoord en nergens in de uitwisseling MS-CHAPv2. Een wachtwoordveld zien is daarom geen bewijs over het protocol erachter, want het formulier is gebouwd om vertrouwd te lijken. Bevestig het protocol uit de serverdocumentatie, niet uit de vorm van het clientvenster.

De antwoorden die u echt nodig hebt

Stuur het verzoek als lijst, want een lijst is moeilijk half te beantwoorden. Vraag naar het tunnelprotocol, de methode erbinnen en de client die de operator op uw platform ondersteunt. Vraag daarna naar de identiteit en vertrouwensinstellingen van de gateway, het accountformaat en wat bereikbaar moet zijn zodra de verbinding staat.

De eerste drie bepalen of u überhaupt een werkend profiel krijgt. De laatste drie bepalen of dat profiel doet wat het werk nodig heeft. Houd het antwoord aan het ticket, want de volgende persoon stelt dezelfde zes vragen. Waar een antwoord ontbreekt, behandelt u het gat als een beslissing die de operator nog niet heeft genomen, niet als iets wat u kunt afleiden.

Versoepel de gatewayverificatie niet

De server bewijst zijn identiteit ook aan de client, en die helft van de uitwisseling is geen versiering. Certificaatverificatie uitschakelen om een koppig profiel te laten verbinden accepteert elk eindpunt dat antwoordt, ook een waar niemand heen wilde. Het verbergt ook een echte mismatch in plaats van die op te lossen, wat de storing naar een later en minder duidelijk moment schuift. Een profiel dat de controle uit moet, is een profiel dat naar iets wijst wat het niet kan verifiëren.

De mismatch is meestal een naam, want een certificaat dat voor één hostnaam is uitgegeven faalt wanneer het profiel een adres kiest. Kies de naam in plaats van de controle uit te schakelen. Een particuliere certificaatautoriteit faalt wanneer het apparaat nooit de root heeft gekregen, en de oplossing is die root via de goedgekeurde weg te verspreiden. Beheerde omgevingen verwachten dat de operator de identiteit en het vertrouwensanker levert en dat het profiel naar beide verwijst. Ontbreekt het veld, vraag dan om het artefact in plaats van de verificatie op te geven.

Stem het profiel af en bewijs daarna elke fase

Zodra de drager bekend is, volgt u het gedocumenteerde proces van die client en vult u alleen de velden in die hij vraagt. Extra velden die worden ingevuld omdat ze bestaan zijn nog steeds verkeerde waarden, en ze falen later dan de verplichte. Bewaar het profiel ongewijzigd na de eerste geslaagde verbinding, zodat een latere wijziging met iets bekends kan worden vergeleken.

Controleer daarna in fasen: de tunnel komt op, de gebruiker authenticeert, het toegewezen adres en de routes verschijnen, en één toegestane dienst antwoordt. Elke fase laat zijn eigen logregel op de server achter, en ze in volgorde lezen maakt van een vage klacht een concrete bevinding. Ondersteunt het platform de opstelling die de operator beschrijft niet meer, dan is dat een migratiegesprek en geen reden om elke oude optie op het apparaat aan te zetten. Drager, methode en profiel zijn drie aparte antwoorden, en een verbinding die werkt heeft ze alle drie in overeenstemming.