MSCHAPv2 non é un protocolo VPN: pregunta primeiro polo túnel

Os nomes de usuario e os contrasinais viaxan dentro dun portador, e MSCHAPv2 só nomea o método que viaxa. Pregunta que túnel o transporta antes de escoller un perfil de cliente, porque a mesma cadea de conta aparece en configuracións que non comparten nin unha liña de código. Cada perfil que che entregan codifica ambas as dúas decisións, mesmo cando a folla de instrucións imprime só unha delas. A orde de abaixo é o que un operador pode responder sen adiviñar e o que ti podes comprobar sen capturar paquetes.

A autenticación viaxa dentro dun túnel

Unha VPN toma dúas decisións que parecen unha: como os pares constrúen unha canle protexida e como unha persoa demostra a súa identidade dentro dela. A segunda está impresa na folla de instrucións porque é a que teclea un humano. A primeira decide se algún cliente funcionará sequera, e é a que a xente salta. Pide ao operador que nomee primeiro o portador e despois o método, nesa orde. Dúas conexións poden esixir o mesmo nome de conta e o mesmo contrasinal sen compartir ningunha implementación baixo a caixa de inicio de sesión.

Por iso os axustes copiados do teléfono que funciona dun compañeiro poden fallar no teu, mesmo cando o servidor acepta ambas as dúas credenciais. A credencial nunca foi a diferenza; era o perfil que a envolve. as dúas partes teñen razón e non se conecta nada adoita ser xusto esta confusión, e aclárase en canto se nomea o portador.

Tres lugares onde aparece o mesmo método

En PPP o paso de autenticación espera a que exista unha ligazón, e RFC 2759 define MS-CHAPv2 como ese paso, por iso o método aparece en L2TP e en despregamentos PPTP máis antigos. O túnel remata primeiro e a negociación PPP ocorre dentro del, así que unha etapa PPP fallida pode deixar o túnel como establecido no rexistro do servidor. Le esas dúas etapas por separado antes de concluír que se rexeitaron as credenciais. Por tanto, un cliente configurado para L2TP pode ser totalmente correcto e aínda así ser o cliente equivocado para unha pasarela que só fala IKEv2.

IKEv2 en cambio coloca EAP-MSCHAPv2 dentro do intercambio de claves, así que a mesma credencial falla noutro momento e aparece como un erro de autenticación e non como un erro de sesión. O perfil IKEv2 da plataforma Android é o exemplo cotián, e pide un certificado ou identificador de servidor en lugar de opcións PPP. O nome de conta é idéntico en ambos os dous arranxos, así que non pode dicirche cal tes. Só a lista de protocolos admitidos do operador o resolve.

Unha VPN baseada en TLS engade un terceiro arranxo, cos seus propios campos de usuario e contrasinal e sen MS-CHAPv2 en ningún punto do intercambio. Ver unha caixa de contrasinal non é, por tanto, proba do protocolo que hai detrás, porque o formulario está construído para parecer coñecido. Confirma o protocolo pola documentación do servidor, non pola forma da xanela do cliente.

As respostas que de verdade necesitas

Envía a petición como unha lista, porque unha lista é difícil de responder a medias. Pide o protocolo do túnel, o método que hai dentro e o cliente que o operador admite na túa plataforma. Despois pide a identidade e os axustes de confianza da pasarela, o formato da conta e que debería ser alcanzable unha vez levantada a conexión.

As tres primeiras deciden se obténs un perfil que funcione. As tres últimas deciden se ese perfil fai o que o traballo necesita. Mantén a resposta anexa ao tícket, porque a seguinte persoa fará as mesmas seis preguntas. Onde falte unha resposta, trata o oco como unha decisión que o operador aínda non tomou, non como algo que poidas inferir.

Non relaxes a verificación da pasarela

O servidor tamén demostra a súa identidade ao cliente, e esa metade do intercambio non é decoración. Desactivar a verificación de certificados para que un perfil teimudo conecte acepta calquera extremo que responda, incluído un ao que ninguén pretendía chegar. Tamén agocha unha discrepancia real en lugar de resolvela, o que empurra o fallo a un momento posterior e menos obvio. Un perfil que necesita a comprobación desactivada é un perfil que apunta a algo que non pode verificar.

A discrepancia adoita ser un nome, porque un certificado emitido para un nome de host falla cando o perfil marca un enderezo. Marca o nome en lugar de desactivar a comprobación. Unha autoridade de certificación privada falla cando ao dispositivo nunca se lle deu a raíz, e a solución é distribuír esa raíz pola vía aprobada. Os contornos xestionados esperan que o operador achegue a identidade e a áncora de confianza, e que o perfil faga referencia a ambas as dúas. Cando falta o campo, pide o artefacto en lugar de renunciar á verificación.

Axusta o perfil e despois demostra cada etapa

Unha vez coñecido o portador, segue o proceso documentado dese cliente e introduce só os campos que pide. Os campos extra cubertos porque existen seguen sendo valores erróneos, e fallan máis tarde que os obrigatorios. Garda o perfil sen cambios tras a primeira conexión correcta, para que unha edición posterior poida compararse con algo que se sabe que funciona.

Despois verifica por etapas: o túnel establécese, o usuario autentícase, aparecen o enderezo e as rutas asignadas e un servizo permitido responde. Cada etapa deixa a súa propia liña de rexistro no servidor, e lelas en orde converte unha queixa vaga nun achado concreto. Se a plataforma xa non admite o arranxo que describe o operador, iso é unha conversación de migración e non un motivo para activar todas as opcións herdadas do dispositivo. Portador, método e perfil son tres respostas separadas, e unha conexión que funciona ten as tres de acordo.