Remote ID na VPN do iPhone: o que esse campo realmente significa
Remote ID é a identidade que o servidor deve provar ao iPhone; Local ID é a identidade que o cliente afirma. Aqui está qual string vai em cada campo.
Você está em Ajustes adicionando uma configuração IKEv2, e dois campos pedem um texto que ninguém lhe deu: Remote ID e Local ID. Nenhum deles é seu nome de usuário, e nenhum é uma segunda cópia do campo Servidor. Remote ID é a identidade que o gateway deve provar ao seu iPhone; Local ID é a identidade que seu iPhone afirma ao gateway. Erre qualquer um e o túnel morre depois que o servidor já respondeu, por isso a falha parece um problema de senha sem ser.
Onde ficam os campos no iOS
Abra Ajustes > Geral > VPN e gestão de dispositivos > VPN e adicione uma configuração IKEv2. Em Autenticação você escolhe Nome de usuário ou Certificado, e só então Remote ID e Local ID aparecem como caixas de texto livre. São identificadores, não endereços: o iOS os carrega na troca IKE_AUTH, onde o IKEv2 chama de IDi a identidade do iniciador e de IDr a do respondedor.
Depois de salvar, o iOS dobra a configuração em uma única linha e deixa de mostrar os valores. Toque no botão de informações ou abra o perfil novamente antes de concluir que os campos estão vazios. Uma configuração enviada por MDM pode deixá-los completamente cinza, o que muda quem consegue corrigir o problema.
Remote ID é o nome do gateway
Este é o valor que seu iPhone espera que o servidor prove. Com autenticação por certificado, ele é comparado ao nome no certificado do servidor, normalmente o subject ou uma entrada subjectAltName. Se o certificado foi emitido para vpn.example.com, esse nome de host é o Remote ID, mesmo quando você chega à máquina por um endereço IP cru.
Essa divergência é a falha clássica: os pacotes chegam, o servidor responde e a conexão cai mesmo assim porque a identidade no certificado não corresponde ao que o perfil exigia. Apontar o campo Servidor para o IP bruto não ajuda, e em muitos gateways o servidor simplesmente para de responder a uma identidade que não consegue casar.
O gateway tem um ajuste correspondente. Um servidor strongSwan envia a própria identidade com leftid e pode restringir a identidade do cliente com rightid; se os dois lados não concordam quanto à string, o IKE_AUTH falha nos dois sentidos. Pergunte ao operador para qual identidade o certificado foi emitido em vez de copiar a URL da barra do navegador.
A Apple documenta as chaves da carga como RemoteIdentifier e LocalIdentifier na sua referência de ajustes do IKEv2. Ambas são strings simples, então maiúsculas e um espaço no final podem importar.
Local ID é o que seu iPhone afirma
Com autenticação por nome de usuário, o EAP verifica o nome e a senha, e o Local ID é uma identidade IKE separada que alguns gateways também exigem. Um gateway pode exigir que o Local ID seja igual ao nome de usuário, seja um endereço de e-mail ou corresponda a uma entrada na sua política de conexões; outros o ignoram. Deixá-lo vazio só é seguro quando o operador diz isso.
Com autenticação por certificado, o Local ID deve corresponder a uma identidade que o gateway aceite para esse certificado de cliente, muitas vezes o nome comum do certificado ou um valor associado a um registro de dispositivo. Copiar o perfil de um colega copia também a identidade dele. No melhor caso o gateway registra o dispositivo errado; no pior, uma política por dispositivo rejeita você.
A armadilha é supor que vazio significa nenhuma identidade. Não preencha um campo vazio com seu endereço de e-mail só porque ele parece inacabado. Confirme o valor pretendido e insira-o exatamente como fornecido.
Uma verificação de cinco minutos antes de salvar
Percorra-os em ordem; o primeiro passo que falhar é o que deve ser corrigido.
- Obtenha três strings do operador: o nome no certificado do servidor, o Local ID esperado e o método de autenticação.
- Ajuste o método de autenticação. Remote ID e Local ID não substituem nome de usuário e senha, e um perfil de certificado não aceitará senha.
- Digite os valores exatamente, incluindo maiúsculas e minúsculas, sem espaço no final.
- Mantenha a validação de certificados ativa. Instalar um certificado raiz sem relação para silenciar um aviso esconde uma divergência de nome em vez de corrigi-la.
- Teste com dados móveis, não com o Wi-Fi do escritório, para que um portal cativo ou DNS dividido não se passem por problema de identidade.
| Field | What belongs there | What a wrong value looks like |
|---|---|---|
| Remote ID | The DNS name in the gateway certificate | Server answers, then the tunnel drops with a certificate or identity error |
| Local ID | The identity the gateway policy expects for you | IKE_AUTH or user authentication fails after the server responds |
| Server | A reachable hostname or IP | Timeout with no identity exchange at all |
Leia a tabela de cima para baixo. Um tempo esgotado na linha Servidor significa que os campos de identidade nunca foram testados, então pare ali. Um erro que só aparece depois da resposta do servidor é quase sempre divergência de Remote ID ou Local ID.
Erros que apontam o campo errado
Uma mensagem como "User authentication failed" trata de credenciais ou EAP, não de Remote ID. Um aviso de certificado trata do nome no certificado, e é aí que Remote ID e o campo Servidor se encontram. "The VPN server did not respond" geralmente significa que UDP 500 e 4500 nunca se completaram, ou que o traversal de NAT falhou, e que nenhuma identidade foi comparada.
Do lado do gateway, as falhas de identidade parecem diferentes: o peer é rejeitado durante o IKE_AUTH, ou o log nomeia o ID que o cliente enviou e diz que ele não corresponde a nenhuma conexão. Essa linha do log é a forma mais rápida de resolver a discussão, porque mostra a string exata que o telefone enviou.
Redefinir uma senha não conserta uma identidade de servidor esperada, e mudar o Remote ID não conserta uma senha errada. Separe primeiro o estágio e depois edite o campo que pertence a esse estágio.
Quando o perfil é gerenciado
Se os campos estão cinza, a configuração veio do MDM e o telefone não é o lugar de corrigir. A carga do VPN leva os identificadores, então a mudança correta está no perfil do servidor de gestão, seguida de reinstalá-lo no dispositivo.
Verifique em Ajustes > Geral > VPN e gestão de dispositivos se o perfil é gerenciado e quem o assinou. Se não puder removê-lo, não poderá editar os identificadores localmente, e criar um segundo perfil local só gera uma configuração conflitante.
Antes de fechar Ajustes, anote as três strings que você digitou e de onde vieram. Na próxima vez que o túnel falhar, compare o ID recebido no log do gateway com essa nota: se for diferente, você está olhando o campo, não a senha.