Un perfil funciona por TCP e falla por UDP cun aviso de certificado. A lectura intuitiva é que a ruta UDP rompeu a confianza, e a solución intuitiva é aceptar o certificado. Ambas as hipóteses pasan por alto unha posibilidade que explica o síntoma por completo: os dous transportes chegaron a máquinas distintas. Unha regra de reenvío aplícase por protocolo, e nada obriga as metades TCP e UDP dun mesmo número de porto a apuntar ao mesmo servidor.

Un número de porto, dúas regras independentes

O reenvío é unha consulta de táboa indexada por protocolo, enderezo de destino e porto. Unha pasarela cunha regra para TCP 1194 e unha regra para UDP 1194 expresa dúas decisións independentes, e estas poden nomear servidores internos distintos. O número compartido é unha comodidade para as persoas, non unha propiedade que impoña a rede. Trate o número de porto como unha etiqueta e non como unha definición de servizo.

Mire as regras efectivas en lugar das previstas. O enderezo de destino, o porto traducido e a interface de entrada participan todos, e unha regra sobrante dunha migración anterior adoita ser a razón de que as dúas metades non coincidan.

Escriba ambas as asignacións antes de cambiar calquera outra cousa. O par de liñas é toda a hipótese.

O que o cliente verificou realmente

Durante o handshake o cliente comproba o certificado contra a confianza configurada e contra o nome que espera. Un certificado inesperado é unha verificación correcta que fallou a comprobación de identidade, que é o resultado axeitado cando o par non é o que quería alcanzar. Rexeitalo é proba de que o cliente funciona, non de que o transporte estea roto. Lea o nome informado antes ca a cadea informada, porque o nome é o que o cliente comparou.

A distinción importa porque os dous fallos levan a arranxos distintos. Un problema de confianza necesita un arranxo de confianza, mentres que un par inesperado necesita un arranxo de encamiñamento ou de reenvío.

Anote que identidade informou o cliente. Ese nome é a pista máis forte sobre que máquina respondeu.

Correlacionar o intento cun servidor

Rexiste o perfil, o enderezo público, o transporte e o porto que usou o cliente. Despois coteje a hora do intento co rexistro do servidor ao que quería chegar. A súa ausencia é unha pista e non unha proba dun descarte do firewall, porque os niveis de rexistro varían entre despregamentos. Unha marca de tempo xunto cun enderezo de orixe acouta máis que calquera das dúas por separado.

Compare a identidade do certificado que atopou coa identidade esperada por unha canle administrativa. Esa comparación fóra de banda é a que mantén fiable a comprobación.

Revise regras de reenvío antigas, escoitas alternativas e calquera ruta de balanceo de carga antes de concluír que ambos os transportes comparten un backend. Cada unha delas pode redirixir un fluxo sen tocar o outro transporte.

Non axustar a confianza a un par equivocado

Importar a CA inesperada fai desaparecer o síntoma e cambia en quen confía o cliente. É un estado peor ca unha conexión fallida, porque oculta a discrepancia en lugar de resolvela. O mesmo vale para desactivar a verificación só para ver se o túnel levanta.

Se o par resulta lexítimo pero non desexado, a acción correcta é retiralo ou apuntar a regra ao servidor correcto. O almacén de confianza non é o lugar para conciliar un erro de inventario.

Conserve o texto do rexeitamento. É o único rexistro do que viu o cliente.

Tras o arranxo, probar un fluxo novo

Corrixa a asignación e despois conéctese cunha sesión de cliente nova. A tradución con estado pode manter un fluxo existente apuntado ao destino antigo, así que unha conexión establecida pode sobrevivir ao cambio e enganalo. Comece unha nova e confirme no rexistro do servidor previsto que atendeu o intento.

Se ambos os transportes demostrablemente chegan ao mesmo servidor e aínda así se comportan distinto, a diferenza restante son as escoitas e a configuración propias dese servidor. A comparación de transportes só ten sentido unha vez fixada a identidade do extremo.

Artigos relacionados