MSCHAPv2 não é um protocolo VPN: pergunte primeiro pelo túnel

Os nomes de utilizador e as palavras-passe viajam dentro de um portador, e o MSCHAPv2 apenas nomeia o método que viaja. Pergunte qual túnel o transporta antes de escolher um perfil de cliente, porque a mesma cadeia de conta aparece em disposições que não partilham uma linha de código. Cada perfil que lhe entregam codifica ambas as decisões, mesmo quando a folha de instruções imprime apenas uma delas. A ordem abaixo é o que um operador consegue responder sem adivinhar e o que você consegue verificar sem capturar pacotes.

A autenticação viaja dentro de um túnel

Uma VPN toma duas decisões que parecem uma: como os pares constroem um canal protegido e como uma pessoa prova a identidade dentro dele. A segunda é impressa na folha de instruções porque é a que um humano escreve. A primeira decide se algum cliente funcionará sequer, e é essa que as pessoas saltam. Peça ao operador que nomeie primeiro o portador e depois o método, nessa ordem. Duas ligações podem exigir o mesmo nome de conta e a mesma palavra-passe sem partilhar qualquer implementação sob a caixa de início de sessão.

Por isso, definições copiadas do telefone que funciona de um colega podem falhar no seu, mesmo quando o servidor aceita ambas as credenciais. A credencial nunca foi a diferença; o perfil que a envolve é que era. ambos os lados terem razão e nada se ligar é normalmente exatamente esta confusão, e resolve-se assim que o portador é nomeado.

Três locais onde o mesmo método aparece

No PPP o passo de autenticação espera até existir uma ligação, e RFC 2759 define o MS-CHAPv2 como esse passo, por isso o método aparece em L2TP e em implementações PPTP mais antigas. O túnel termina primeiro e a negociação PPP ocorre dentro dele, pelo que uma fase PPP falhada pode deixar o túnel com aparência de estabelecido no registo do servidor. Leia essas duas fases em separado antes de concluir que as credenciais foram rejeitadas. Assim, um cliente configurado para L2TP pode estar perfeitamente correto e continuar a ser o cliente errado para um gateway que só fala IKEv2.

O IKEv2 coloca antes o EAP-MSCHAPv2 dentro da troca de chaves, pelo que a mesma credencial falha noutro momento e surge como erro de autenticação e não como erro de sessão. O perfil IKEv2 da plataforma Android é o exemplo quotidiano, e pede um certificado ou identificador de servidor em vez de opções PPP. O nome da conta é idêntico nas duas disposições, pelo que não lhe pode dizer qual tem. Só a lista de protocolos suportados do operador resolve isso.

Uma VPN baseada em TLS acrescenta uma terceira disposição, com os seus próprios campos de nome de utilizador e palavra-passe e sem MS-CHAPv2 em qualquer ponto da troca. Ver uma caixa de palavra-passe não é, portanto, prova do protocolo por trás dela, porque o formulário foi construído para parecer familiar. Confirme o protocolo pela documentação do servidor, não pela forma da janela do cliente.

As respostas de que realmente precisa

Envie o pedido como lista, porque uma lista é difícil de responder a meio. Peça o protocolo do túnel, o método lá dentro e o cliente que o operador suporta na sua plataforma. Depois peça a identidade e as definições de confiança do gateway, o formato da conta e o que deve estar acessível quando a ligação estiver de pé.

As três primeiras decidem se chega a obter um perfil que funcione. As três últimas decidem se esse perfil faz o que o trabalho exige. Mantenha a resposta anexada ao ticket, porque a pessoa seguinte fará as mesmas seis perguntas. Onde falta uma resposta, trate a lacuna como uma decisão que o operador ainda não tomou, e não como algo que possa inferir.

Não relaxe a verificação do gateway

O servidor também prova a sua identidade ao cliente, e essa metade da troca não é decoração. Desativar a verificação de certificados para que um perfil teimoso se ligue aceita qualquer extremo que responda, incluindo um a que ninguém pretendia chegar. Também esconde uma discrepância real em vez de a resolver, o que empurra a falha para um momento mais tardio e menos óbvio. Um perfil que precisa da verificação desligada é um perfil que aponta para algo que não consegue verificar.

A discrepância costuma ser um nome, porque um certificado emitido para um nome de anfitrião falha quando o perfil marca um endereço. Marque o nome em vez de desativar a verificação. Uma autoridade de certificação privada falha quando o dispositivo nunca recebeu a raiz, e a correção é distribuir essa raiz pela via aprovada. Os ambientes geridos esperam que o operador forneça a identidade e a âncora de confiança, e que o perfil faça referência a ambas. Quando o campo falta, peça o artefacto em vez de renunciar à verificação.

Ajuste o perfil e depois prove cada etapa

Uma vez conhecido o portador, siga o processo documentado desse cliente e introduza apenas os campos que ele pede. Os campos extra preenchidos por existirem continuam a ser valores errados, e falham mais tarde do que os obrigatórios. Guarde o perfil sem alterações após a primeira ligação bem-sucedida, para que uma edição posterior possa ser comparada com algo que se sabe funcionar.

Depois verifique por etapas: o túnel estabelece-se, o utilizador autentica-se, aparecem o endereço e as rotas atribuídas, e um serviço permitido responde. Cada etapa deixa a sua própria linha de registo no servidor, e lê-las por ordem transforma uma queixa vaga numa constatação concreta. Se a plataforma já não suporta a disposição que o operador descreve, isso é uma conversa de migração e não um motivo para ativar todas as opções antigas no dispositivo. Portador, método e perfil são três respostas separadas, e uma ligação que funciona tem as três de acordo.