MSCHAPv2 no és un protocol VPN: pregunta primer pel túnel

Els noms d’usuari i les contrasenyes viatgen dins d’un portador, i MSCHAPv2 només anomena el mètode que viatja. Pregunta quin túnel el porta abans de triar un perfil de client, perquè la mateixa cadena de compte apareix en arranjaments que no comparteixen ni una línia de codi. Cada perfil que et donen codifica totes dues decisions, fins i tot quan el full d’instruccions n’imprimeix només una. L’ordre de sota és el que un operador pot respondre sense endevinar i el que tu pots comprovar sense capturar paquets.

L’autenticació viatja dins d’un túnel

Una VPN pren dues decisions que semblen una: com els parells construeixen un canal protegit i com una persona demostra la identitat dins seu. La segona s’imprimeix al full d’instruccions perquè és la que escriu una persona. La primera decideix si qualsevol client funcionarà, i és la que la gent s’estalvia. Demana a l’operador que nomeni primer el portador i després el mètode, en aquest ordre. Dues connexions poden exigir el mateix nom de compte i la mateixa contrasenya sense compartir cap implementació sota la caixa d’inici de sessió.

Per això els paràmetres copiats del telèfon que funciona d’un company poden fallar al teu, fins i tot quan el servidor accepta totes dues credencials. La credencial no era mai la diferència; ho era el perfil que l’envolta. les dues bandes tenen raó i no es connecta res acostuma a ser aquesta confusió, i s’aclareix tan bon punt es nomena el portador.

Tres llocs on apareix el mateix mètode

A PPP el pas d’autenticació espera que existeixi un enllaç, i RFC 2759 defineix MS-CHAPv2 com aquest pas, per això el mètode apareix a L2TP i en desplegaments PPTP més antics. El túnel acaba primer i la negociació PPP passa dins seu, així que una etapa PPP fallida pot deixar el túnel com establit al registre del servidor. Llegeix aquestes dues etapes per separat abans de concloure que s’han rebutjat les credencials. Per tant, un client configurat per a L2TP pot ser perfectament correcte i tot i així ser el client equivocat per a una passarel·la que només parla IKEv2.

IKEv2 en canvi posa EAP-MSCHAPv2 dins de l’intercanvi de claus, així que la mateixa credencial falla en un moment diferent i apareix com a error d’autenticació i no com a error de sessió. El perfil IKEv2 de la plataforma Android és l’exemple quotidià, i demana un certificat o identificador de servidor en lloc d’opcions PPP. El nom del compte és idèntic en tots dos arranjaments, així que no et pot dir quin tens. Només la llista de protocols admesos de l’operador ho resol.

Una VPN basada en TLS afegeix un tercer arranjament, amb els seus propis camps d’usuari i contrasenya i sense MS-CHAPv2 enlloc de l’intercanvi. Per tant, veure una caixa de contrasenya no és cap prova del protocol que hi ha darrere, perquè el formulari està fet per semblar familiar. Confirma el protocol per la documentació del servidor, no per la forma de la finestra del client.

Les respostes que realment necessites

Envia la petició com una llista, perquè una llista és difícil de respondre a mitges. Demana el protocol del túnel, el mètode que hi ha dins i el client que l’operador admet a la teva plataforma. Després demana la identitat i els paràmetres de confiança de la passarel·la, el format del compte i què hauria de ser abastable un cop la connexió estigui activa.

Les tres primeres decideixen si obtens un perfil que funcioni. Les tres últimes decideixen si aquest perfil fa el que la feina necessita. Mantingues la resposta adjunta al tiquet, perquè la persona següent farà les mateixes sis preguntes. On falta una resposta, tracta el buit com una decisió que l’operador encara no ha pres, no com una cosa que puguis inferir.

No relaxis la verificació de la passarel·la

El servidor també demostra la seva identitat al client, i aquesta meitat de l’intercanvi no és decoració. Desactivar la verificació de certificats perquè un perfil tossut es connecti accepta qualsevol extrem que respongui, inclòs un al qual ningú no volia arribar. També amaga una discrepància real en lloc de resoldre-la, cosa que empeny la fallada a un moment posterior i menys evident. Un perfil que necessita la comprovació desactivada és un perfil que apunta a una cosa que no pot verificar.

La discrepància sol ser un nom, perquè un certificat emès per a un nom d’amfitrió falla quan el perfil marca una adreça. Marca el nom en lloc de desactivar la comprovació. Una autoritat de certificació privada falla quan mai no s’ha donat l’arrel al dispositiu, i la solució és distribuir aquesta arrel per la via aprovada. Els entorns gestionats esperen que l’operador proporcioni la identitat i l’àncora de confiança, i que el perfil faci referència a totes dues. Quan el camp és absent, demana l’artefacte en lloc de renunciar a la verificació.

Ajusta el perfil i després demostra cada etapa

Un cop conegut el portador, segueix el procés documentat d’aquell client i introdueix només els camps que demana. Els camps extra omplerts perquè existeixen són igualment valors equivocats, i fallen més tard que els obligatoris. Desa el perfil sense canvis després de la primera connexió correcta, perquè una edició posterior es pugui comparar amb una cosa que se sap que funciona.

Després verifica per etapes: el túnel s’estableix, l’usuari s’autentica, l’adreça i les rutes assignades apareixen i un servei permès respon. Cada etapa deixa la seva línia de registre al servidor, i llegir-les en ordre converteix una queixa vaga en una troballa concreta. Si la plataforma ja no admet l’arranjament que descriu l’operador, això és una conversa de migració i no un motiu per activar totes les opcions heretades del dispositiu. Portador, mètode i perfil són tres respostes separades, i una connexió que funciona les té totes tres d’acord.