Perfil bloqueado ao servidor falha atrás de um proxy TLS: qual geração?

Um usuário consegue conectar e outro não, pelo mesmo portal, no mesmo dia. Ambos têm perfis bloqueados ao servidor, ambos estão na mesma compilação do Access Server, e a única diferença é quando o perfil deles foi gerado. Esse é o padrão que vale a pena reconhecer, porque "bloqueado ao servidor" nomeia uma política e não uma sequência de conexão. O Access Server já entregou duas gerações desse artefato, e um proxy reverso TLS fica à frente de apenas um dos seus caminhos. Três condições decidem em qual ramo você está.

Duas gerações, duas sequências de conexão

No projeto mais antigo, válido até a 2.8, o arquivo importado é um pseudoperfil. O OpenVPN Connect o usa para se autenticar na API web do Access Server por HTTPS, recebe um perfil temporário bloqueado ao usuário e um token de sessão, e só então estabelece a VPN. Dois transportes funcionam em sequência, e o primeiro é uma requisição web comum.

O formato introduzido com a 2.9 não realiza essa inicialização por conexão. É um perfil nativo utilizável por OpenVPN clientes compatíveis, não apenas pelo OpenVPN Connect. Baixá-lo ou importá-lo por URL ainda pode envolver HTTPS — isso é uma etapa de publicação, não uma obtenção de perfil temporário por conexão.

Uma atualização não reescreve necessariamente perfis já emitidos, então uma versão atual do servidor ainda pode estar distribuindo o artefato antigo. A compilação do servidor diz o que é possível, não o que este usuário importou.

Três condições que escolhem o seu ramo

A primeira condição é a geração do artefato. Peça o arquivo, veja como foi produzido e anote a versão do cliente que o importou. Se não conseguir estabelecer a geração a partir do arquivo, um perfil novo emitido para uma conta de teste dirá o que o servidor produz hoje, e essa é uma informação diferente da que o usuário que falha possui.

A segunda é o que o seu front end realmente termina. Um proxy reverso HTTP de camada sete que descarrega o TLS não é o mesmo objeto que um encaminhador TCP de camada quatro, e um encaminhador UDP também não é. A disposição habitual do Access Server na porta 443 faz o daemon OpenVPN TCP reconhecer o tráfego do navegador e entregá-lo aos serviços web, então inserir um terminador HTTPS alheio na frente não preserva o tratamento de protocolo desse daemon. Compartilhar o número 443 não torna dois projetos equivalentes.

A terceira é onde a falha aterrissa. Uma falha antes da VPN e uma falha do canal de controle parecem iguais em um cliente que só diz "conectando", mas deixam evidências em lugares diferentes. Se o formato antigo estiver em jogo, a inicialização é candidata. Se o formato novo estiver em jogo, um log de acesso web vazio é esperado e não prova nada em nenhuma direção.

Quando o artefato é antigo: a inicialização falha primeiro

Leia o erro real do cliente em vez do seu estado final. Os campos interessantes são o erro HTTPS, a identidade do servidor que o cliente esperava, o destino para onde a requisição foi e se a validação do certificado foi concluída. Depois compare-os com os logs do serviço web e do proxy no lado do servidor.

Um navegador chegar à página de login não é prova de que a autenticação por API deste cliente teve sucesso. São requisições diferentes, com expectativas de certificado diferentes e, muitas vezes, nomes de host diferentes. Se o portal é servido corretamente e o cliente ainda falha, a divergência está no caminho de inicialização, não na senha do usuário.

Não faça a comparação passar desativando a verificação TLS ou afrouxando a política de autenticação. Isso transforma uma incompatibilidade de configuração diagnosticável em um caminho que funciona mas não está verificado, e é exatamente essa mudança que transforma um teste temporário em um buraco permanente. A documentação do Access Server sobre perfis de conexão descreve as duas gerações e o fluxo do perfil temporário, e é a referência que deve ser consultada antes de supor que um proxy é o culpado.

Quando o artefato é novo: leia o canal de controle

Com um perfil no estilo 2.9, o cliente vai direto ao endpoint nativo da VPN. Investigue os endpoints do perfil, o transporte em uso e o erro do canal de controle. Se o cliente nunca emite uma requisição HTTP, isso é coerente com o projeto e não é um sintoma.

Aqui também a questão do proxy muda de forma. Uma descarga HTTPS não pode quebrar um fluxo apenas TCP que nunca vê, mas ainda pode quebrar o download que publica o perfil, e um encaminhador apenas TCP não transportará UDP de forma alguma. Verifique qual transporte o perfil exige antes de concluir que o front end é irrelevante.

O passthrough TLS para um único fluxo é uma disposição estreita. Ele não fornece encaminhamento UDP e não reproduz o próprio comportamento de encaminhamento de serviços do daemon na 443. Se o seu front end faz uma dessas coisas, diga qual, porque o remédio é diferente.

Remédios que permanecem estreitos

A verificação menos intrusiva é gerar um perfil novo suportado para uma conta de teste e conectar pelo endpoint nativo previsto com os mesmos requisitos de autenticação. Se isso funcionar e o perfil antigo mantido não funcionar, você separou o artefato do servidor e do proxy em um único passo.

A distribuição de um perfil bloqueado ao usuário elimina totalmente a dependência da inicialização legada, porque não há troca de perfil temporário que possa falhar. Ele deve ser emitido para o usuário previsto, nunca copiado de um administrador, e altera o que o cliente tem autorização para fazer, então trate-o como uma decisão de política e não como um contorno.

Depois corrija a disposição de publicação para que cada caminho necessário exista: o caminho web para downloads e uso do portal, e o caminho nativo de VPN no transporte que os perfis esperam. Mantenha o trabalho do proxy em uma única camada. Um túnel bloqueado ao usuário que funciona prova que esse caminho funciona; não prova que toda disposição de proxy suporta toda geração, e uma falha de inicialização antiga não condena o formato mais novo.

• Identifique a geração do artefato antes de tocar no proxy.
• Estabeleça se a falha ocorre antes do túnel ou dentro dele.
• Confirme o que o front end termina: HTTP, fluxo TCP ou UDP.
• Teste um perfil recém-emitido contra o endpoint nativo com a política inalterada.