MSCHAPv2 is nie ’n VPN-protokol nie: vra eers na die tonnel

Gebruikersname en wagwoorde reis binne ’n draer, en MSCHAPv2 noem net die metode wat reis. Vra watter tonnel dit dra voordat jy ’n kliëntprofiel kies, want dieselfde rekeningstring kom voor in reëlings wat geen kode deel nie. Elke profiel wat jy kry, kodeer albei besluite, selfs wanneer die instruksieblad net een daarvan druk. Die volgorde hieronder is wat ’n operateur sonder raaiwerk kan beantwoord en wat jy sonder ’n pakkie-opname kan nagaan.

Verifikasie ry binne ’n tonnel

’n VPN maak twee besluite wat soos een lyk: hoe die eweknieë ’n beskermde kanaal bou, en hoe ’n persoon binne-in dit identiteit bewys. Die tweede word op die instruksieblad gedruk omdat dit die een is wat ’n mens intik. Die eerste bepaal of enige kliënt hoegenaamd sal werk, en dit is die een wat mense oorslaan. Vra die operateur om eers die draer en dan die metode te noem, in daardie volgorde. Twee verbindings kan dieselfde rekeningnaam en dieselfde wagwoord vereis terwyl hulle geen implementering onder die aanmeldblok deel nie.

Daarom kan instellings wat van ’n kollega se werkende foon gekopieer is, op joune misluk selfs wanneer die bediener albei geloofsbriewe aanvaar. Die geloofsbrief was nooit die verskil nie; die profiel rondom dit was. beide kante reg is en niks verbind nie is gewoonlik hierdie verwarring, en dit word opgeklaar sodra die draer genoem word.

Drie plekke waar dieselfde metode voorkom

In PPP wag die verifikasiestap tot ’n skakel bestaan, en RFC 2759 definieer MS-CHAPv2 as daardie stap, daarom duik die metode op in L2TP en in ouer PPTP-ontplooiings. Die tonnel eindig eerste en die PPP-onderhandeling gebeur binne-in dit, so ’n mislukte PPP-stadium kan die tonnel in die bedienerlog laat lyk of dit gevestig is. Lees daardie twee stadiums afsonderlik voordat jy aflei dat die geloofsbriewe verwerp is. Dus kan ’n kliënt wat vir L2TP opgestel is heeltemal korrek wees en tog die verkeerde kliënt wees vir ’n poort wat net IKEv2 praat.

IKEv2 plaas EAP-MSCHAPv2 eerder binne die sleuteluitruiling, so dieselfde geloofsbrief misluk op ’n ander oomblik en verskyn as ’n verifikasiefout eerder as ’n sessiefout. Android se platform-IKEv2-profiel is die alledaagse voorbeeld, en dit vra vir ’n bediener-sertifikaat of identifiseerder eerder as vir PPP-opsies. Die rekeningnaam is in albei reëlings identies, so dit kan jou nie sê watter een jy het nie. Net die operateur se lys van ondersteunde protokolle beslis dit.

’n TLS-gebaseerde VPN voeg ’n derde reëling by, met sy eie gebruikersnaam- en wagwoordvelde en geen MS-CHAPv2 enige plek in die uitruiling nie. Om ’n wagwoordblokkie te sien is dus geen bewys van die protokol daaronder nie, want die vorm is gebou om vertroud te lyk. Bevestig die protokol uit die bediener se dokumentasie eerder as uit die vorm van die kliëntvenster.

Die antwoorde wat jy werklik nodig het

Stuur die versoek as ’n lys, want ’n lys is moeilik om half te beantwoord. Vra vir die tonnelprotokol, die metode daarbinne, en die kliënt wat die operateur op jou platform ondersteun. Vra dan vir die poortidentiteit en vertroue-instellings, die rekeningformaat, en wat bereikbaar moet wees sodra die verbinding staan.

Die eerste drie bepaal of jy hoegenaamd ’n werkende profiel kry. Die laaste drie bepaal of daardie profiel doen wat die werk nodig het. Hou die antwoord by die kaartjie, want die volgende persoon sal dieselfde ses vrae vra. Waar ’n antwoord ontbreek, beskou die leemte as ’n besluit wat die operateur nog nie gemaak het nie, eerder as een wat jy kan aflei.

Moet nie poortverifikasie verslap nie

Die bediener bewys ook sy identiteit aan die kliënt, en daardie helfte van die uitruiling is nie versiering nie. Om sertifikaatverifikasie af te skakel sodat ’n hardnekkige profiel kan verbind, aanvaar enige eindpunt wat antwoord, insluitend een wat niemand bedoel het om te bereik nie. Dit verberg ook ’n werklike wanaanpassing in plaas daarvan om dit op te los, wat die mislukking na ’n later en minder ooglopende oomblik skuif. ’n Profiel wat die kontrole uitgeskakel wil hê, is ’n profiel wat na iets wys wat dit nie kan verifieer nie.

Die wanaanpassing is gewoonlik ’n naam, want ’n sertifikaat wat vir een gasheernaam uitgereik is, misluk wanneer die profiel ’n adres skakel. Skakel die naam eerder as om die kontrole af te skakel. ’n Private sertifikaatowerheid misluk wanneer die toestel nooit die wortel gegee is nie, en die oplossing is om daardie wortel langs die goedgekeurde weg te versprei. Bestuurde omgewings verwag dat die operateur die identiteit en die vertroue-anker verskaf, en dat die profiel na albei verwys. Wanneer die veld ontbreek, vra vir die artefak eerder as om van die verifikasie af te sien.

Pas die profiel, bewys dan elke stadium

Sodra die draer bekend is, volg daardie kliënt se gedokumenteerde proses en voer net die velde in wat dit vra. Ekstra velde wat ingevul word omdat hulle bestaan, is steeds verkeerde waardes, en hulle misluk later as die vereiste een. Stoor die profiel onveranderd ná die eerste suksesvolle verbinding, sodat ’n latere wysiging met iets vergelyk kan word wat bewys het dat dit werk.

Verifieer dan in stadiums: die tonnel vestig, die gebruiker verifieer, die toegewysde adres en roetes verskyn, en een toegelate diens antwoord. Elke stadium laat sy eie logreël op die bediener, en om hulle in volgorde te lees verander ’n vae klag in ’n spesifieke bevinding. As die platform nie meer die reëling ondersteun wat die operateur beskryf nie, is dit ’n migrasiegesprek eerder as ’n rede om elke legacy-opsie op die toestel aan te skakel. Draer, metode en profiel is drie aparte antwoorde, en ’n verbinding wat werk, het al drie in ooreenstemming.