MSCHAPv2 ne estas VPN-protokolo: demandu unue pri la tunelo
Pasvorto kaj la vorto MSCHAPv2 ne kreas konekton. Demandu, kiu tunelo portas la interŝanĝon, poste agordu la klientan profilon al ĝi.
Uzantnomoj kaj pasvortoj vojaĝas ene de portanto, kaj MSCHAPv2 nomas nur la metodon, kiu vojaĝas. Demandu, kiu tunelo portas ĝin, antaŭ ol elekti klientan profilon, ĉar la sama konta ĉeno aperas en aranĝoj, kiuj dividas eĉ ne unu linion da kodo. Ĉiu profilo, kiun oni transdonas al vi, kodigas ambaŭ decidojn, eĉ kiam la instrukcia folio presas nur unu el ili. La ordo sube estas tio, kion operatoro povas respondi sen konjekti kaj kion vi povas kontroli sen kapti pakaĵojn.
Aŭtentigo veturas ene de tunelo
VPN faras du decidojn, kiuj aspektas kiel unu: kiel la partneroj konstruas protektitan kanalon, kaj kiel persono pruvas identecon ene de ĝi. La dua estas presita sur la instrukcia folio, ĉar ĝin tajpas homo. La unua decidas, ĉu iu ajn kliento entute funkcios, kaj ĝin homoj preterlasas. Petu la operatoron nomi unue la portanton kaj poste la metodon, en tiu ordo. Du konektoj povas postuli la saman kontan nomon kaj la saman pasvorton, dum ili dividas nenian realigon sub la ensaluta kampo.
Tial agordoj kopiitaj de funkcianta telefono de kolego povas malsukcesi ĉe via, eĉ kiam la servilo akceptas ambaŭ legitimilojn. La legitimilo neniam estis la diferenco; la profilo ĉirkaŭ ĝi estis. ambaŭ flankoj pravas kaj nenio konektiĝas kutime estas ĝuste ĉi tiu konfuzo, kaj ĝi klariĝas tuj kiam la portanto estas nomita.
Tri lokoj, kie la sama metodo aperas
En PPP la aŭtentiga paŝo atendas, ĝis ekzistas ligilo, kaj RFC 2759 difinas MS-CHAPv2 kiel tiun paŝon, tial la metodo aperas en L2TP kaj en pli malnovaj PPTP-instalaĵoj. La tunelo finiĝas unue, kaj la PPP-prilaborado okazas ene de ĝi, do malsukcesinta PPP-fazo povas lasi la tunelon aspekti establita en la servila protokolo. Legu tiujn du fazojn aparte antaŭ ol konkludi, ke la legitimiloj estis malakceptitaj. Do kliento agordita por L2TP povas esti tute ĝusta kaj tamen la malĝusta kliento por pordego, kiu parolas nur IKEv2.
IKEv2 metidas EAP-MSCHAPv2 ene de la ŝlosila interŝanĝo anstataŭe, do la sama legitimilo malsukcesas je alia momento kaj aperas kiel aŭtentiga eraro anstataŭ kiel sesia eraro. La platforma IKEv2-profillo de Android estas la ĉiutaga ekzemplo, kaj ĝi petas servilan atestilon aŭ identigilon anstataŭ PPP-opciojn. La konta nomo estas identa en ambaŭ aranĝoj, do ĝi ne povas diri al vi, kiun vi havas. Nur la listo de subtenataj protokoloj ĉe la operatoro decidas tion.
TLS-bazita VPN aldonas trian aranĝon, kun propraj kampoj por uzantnomo kaj pasvorto kaj sen MS-CHAPv2 ie ajn en la interŝanĝo. Vidi pasvortan kampon do ne estas pruvo pri la protokolo malantaŭ ĝi, ĉar la formularo estas konstruita por aspekti konata. Konfirmu la protokolon el la servila dokumentaro, ne el la formo de la klienta fenestro.
La respondoj, kiujn vi vere bezonas
Sendu la peton kiel liston, ĉar liston malfacilas duone respondi. Petu la tunelan protokolon, la metodon ene de ĝi kaj la klienton, kiun la operatoro subtenas sur via platformo. Poste petu la identecon kaj fidoagordojn de la pordego, la kontan formaton kaj tion, kio devas esti atingebla post kiam la konekto staras.
La unuaj tri decidas, ĉu vi entute ricevos funkciantan profilon. La lastaj tri decidas, ĉu tiu profilo faras tion, kion la tasko bezonas. Tenu la respondon ĉe la bileto, ĉar la sekva persono demandos la samajn ses demandojn. Kie respondo mankas, traktu la breĉon kiel decidon, kiun la operatoro ankoraŭ ne faris, ne kiel ion, kion vi povas dedukti.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
Ne malstreĉu la pordegan kontroladon
La servilo ankaŭ pruvas sian identecon al la kliento, kaj tiu duono de la interŝanĝo ne estas ornamo. Malŝalti la atestilan kontroladon por ke obstina profilo konektiĝu akceptas ajnan finpunkton, kiu respondas, inkluzive de tiu, kiun neniu intencis atingi. Ĝi ankaŭ kaŝas realan malkongruon anstataŭ solvi ĝin, kio puŝas la malsukceson al pli posta kaj malpli evidenta momento. Profilo, kiu bezonas la kontrolon malŝaltita, estas profilo montranta al io, kion ĝi ne povas kontroli.
La malkongruo kutime estas nomo, ĉar atestilo eldonita por unu gastignomo malsukcesas, kiam la profilo vokas adreson. Voku la nomon anstataŭ malŝalti la kontrolon. Privata atestila aŭtoritato malsukcesas, kiam la aparato neniam ricevis la radikon, kaj la solvo estas disdoni tiun radikon per la aprobita vojo. Administrataj medioj atendas, ke la operatoro liveru la identecon kaj la fidopunkton, kaj ke la profilo referencu ambaŭ. Kiam la kampo mankas, petu la artefakton anstataŭ rezigni pri la kontrolado.
Agordu la profilon, poste pruvu ĉiun etapon
Post kiam la portanto estas konata, sekvu la dokumentitan procezon de tiu kliento kaj enigu nur la kampojn, kiujn ĝi petas. Pliaj kampoj plenigitaj ĉar ili ekzistas estas ankoraŭ malĝustaj valoroj, kaj ili malsukcesas pli malfrue ol la devigaj. Konservu la profilon senŝanĝe post la unua sukcesa konekto, por ke posta redakto kompareblu kun io sciata funkcii.
Poste kontrolu laŭ etapoj: la tunelo establiĝas, la uzanto aŭtentiĝas, la asignita adreso kaj la itineroj aperas, kaj unu permesita servo respondas. Ĉiu etapo lasas sian propran protokollinion ĉe la servilo, kaj legi ilin laŭ ordo ŝanĝas malprecizan plendon en konkretan konstaton. Se la platformo ne plu subtenas la aranĝon, kiun la operatoro priskribas, tio estas migrada interparolo, ne kialo ŝalti ĉiun heredaĵan opcion en la aparato. Portanto, metodo kaj profilo estas tri apartaj respondoj, kaj konekto, kiu funkcias, havas ĉiujn tri en interkonsento.