TCP funciona e UDP chega a outro servidor na mesma porta

Um perfil funciona por TCP e falha por UDP com um aviso de certificado. A leitura intuitiva é que o caminho UDP quebrou a confiança, e a correção intuitiva é aceitar o certificado. Ambas as suposições ignoram uma possibilidade que explica o sintoma por completo: os dois transportes chegaram a máquinas diferentes. Uma regra de encaminhamento é aplicada por protocolo, e nada obriga as metades TCP e UDP de um mesmo número de porta a apontar para o mesmo host.

Um número de porta, duas regras independentes

O encaminhamento é uma consulta de tabela indexada por protocolo, endereço de destino e porta. Um gateway com uma regra para TCP 1194 e uma regra para UDP 1194 expressa duas decisões independentes, e elas podem indicar hosts internos diferentes. O número compartilhado é uma comodidade para as pessoas, não uma propriedade que a rede imponha. Trate o número da porta como um rótulo e não como uma definição de serviço.

Observe as regras efetivas em vez das pretendidas. Endereço de destino, porta traduzida e interface de entrada participam todos, e uma regra deixada de uma migração anterior costuma ser o motivo de as duas metades não concordarem.

Anote os dois mapeamentos antes de mudar qualquer outra coisa. O par de linhas é toda a hipótese.

O que o cliente realmente verificou

Durante o handshake o cliente verifica o certificado contra a confiança configurada e contra o nome que espera. Um certificado inesperado é uma verificação bem-sucedida que falhou na checagem de identidade, que é o resultado correto quando o par não é aquele que você queria alcançar. Rejeitá-lo é prova de que o cliente funciona, não de que o transporte está quebrado. Leia o nome informado antes da cadeia informada, porque o nome é o que o cliente comparou.

A distinção importa porque as duas falhas levam a correções diferentes. Um problema de confiança precisa de uma correção de confiança, enquanto um par inesperado precisa de uma correção de roteamento ou de encaminhamento.

Anote qual identidade o cliente informou. Esse nome é a pista mais forte sobre qual máquina respondeu.

Correlacionar a tentativa com um servidor

Registre o perfil, o endereço público, o transporte e a porta que o cliente usou. Depois combine o horário da tentativa com o log do servidor que você pretendia alcançar. A ausência ali é uma pista e não prova de descarte pelo firewall, porque os níveis de registro variam entre implantações. Um carimbo de tempo junto com um endereço de origem restringe mais do que qualquer um dos dois sozinho.

Compare a identidade do certificado que você encontrou com a identidade esperada por um canal administrativo. É essa comparação fora de banda que mantém a checagem confiável.

Verifique regras de encaminhamento antigas, ouvintes alternativos e qualquer caminho de balanceamento de carga antes de concluir que os dois transportes compartilham um backend. Cada um deles pode redirecionar um fluxo sem tocar no outro transporte.

Não ajustar a confiança a um par errado

Importar a CA inesperada faz o sintoma desaparecer e muda em quem o cliente confia. É um estado pior do que uma conexão falha, porque esconde a divergência em vez de resolvê-la. O mesmo vale para desativar a verificação só para ver se o túnel sobe.

Se o par se revelar legítimo mas não desejado, a ação correta é retirá-lo ou apontar a regra para o host certo. O armazenamento de confiança não é o lugar para reconciliar um erro de inventário.

Guarde o texto da rejeição. É o único registro do que o cliente viu.

Depois da correção, testar um fluxo novo

Corrija o mapeamento e então conecte-se com uma sessão de cliente nova. A tradução com estado pode manter um fluxo existente apontado para o destino antigo, então uma conexão estabelecida pode sobreviver à mudança e enganá-lo. Inicie uma nova e confirme no log do servidor pretendido que ele tratou a tentativa.

Se os dois transportes comprovadamente alcançam o mesmo servidor e ainda assim se comportam de modo diferente, a diferença restante são os ouvintes e a configuração desse servidor. A comparação de transportes só significa algo depois que a identidade do endpoint está fixada.