A segunda entrada VPN de WAN falla mentres a primaria segue funcionando

O túnel primario segue en pé, os usuarios seguen traballando e o segundo circuíto do ISP queda inactivo fagas o que fagas. Publicaches un enderezo para o circuíto de reserva, apuntaches un nome cara a el, quizais engadiches unha entrada de reserva ao cliente, e o cliente ou nunca a proba ou autentícase e despois morre. Nos casos que seguín, a función de failover adoita estar ben; o que faltaba era unha das cinco cousas que fan utilizábel unha entrada. Un nome pode resolverse ao enderezo de reserva mentres nada escoita nesa interface, e un oínte pode aceptar unha conexión mentres a resposta sae pola primaria. Trata cada WAN como unha entrada separada co seu propio contrato e o fallo deixa de parecer un erro do cliente.

Cada WAN necesita o seu propio contrato de entrada

Anota cinco campos por WAN: o nome e o enderezo públicos, o transporte e o porto, a interface ou o contexto que o termina, a identidade do par que debe presentar e por onde sae a resposta. Dous circuítos significan dous conxuntos completos. Se o segundo conxunto non ten interface de terminación nin ruta de retorno, non tes unha entrada de reserva; tes un rexistro DNS que describe unha intención.

O equipo e a súa versión tamén deben soportar a disposición. Un rexistro DNS non pode abrir un servizo noutra interface, e en moitas plataformas o oínte configúrase por enderezo e non por dispositivo. O IPsec baseado en interface nun ASA liga os mapas criptográficos e os grupos de túnel á interface exterior, así que un segundo enlace ascendente necesita política onde eses paquetes chegan de verdade. Os deseños baseados en rutas compórtanse distinto: o oínte pode ligarse a todos os enderezos ou a un enderezo concreto, e esa escolla decide se o ISP B pode responder sequera.

Comproba que o segundo WAN responde de verdade

Proba desde fóra de ambos circuítos, non desde unha máquina detrás da pasarela, e proba o nome exacto que usa o perfil do cliente. Para un oínte TLS, a comprobación rápida é openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts executada desde un host fóra da túa rede. Queres un handshake completado cuxa cadea coincida co nome do perfil, non só un porto TCP que acepte unha conexión.

RFC 9525 explica que comproba o cliente: a identidade á que pretendía chegar, comparada co certificado que presenta o servizo. Unha segunda entrada que devolve o certificado da entrada primaria, ou un certificado por defecto que non lista ningún dos dous nomes, falla esta proba aínda que o porto estea aberto e o cortafuegos o permita.

Dous patróns explican a maioría dos fallos aquí. Unha conexión que se colga adoita significar que non hai oínte nesa interface, unha regra de acceso que só permite as subredes primarias, ou un dispositivo do operador diante do segundo circuíto que descarta o porto. Un handshake que remata coa identidade equivocada adoita significar outro trustpoint, un host virtual por defecto ou unha configuración copiada da primaria sen axustar a identidade.

Segue a resposta, non só a petición

O segundo WAN adoita romper na volta. Unha petición chega polo ISP B, o equipo responde e a resposta sae pola ruta por defecto do ISP A cun enderezo de orixe que o cliente nunca pediu. A tradución con estado empeórao: se o mapeamento se construíu para a interface primaria, o paquete de volta non atopa a tradución ou leva unha orixe que o cortafuegos do cliente descarta. Os provedores tamén descartan enderezos de orixe que non pertencen ao circuíto que che deron, e por iso isto parece un burato negro unidireccional en lugar dun erro de protocolo limpo.

Comproba a decisión de encamiñamento para o tráfico orixinado na segunda entrada. A resposta debe saír pola interface pola que chegou a petición, ou polo menos levar un enderezo que o lado afastado acepte como pertencente a esa ruta. En plataformas de encamiñamento por política iso significa unha regra ligada á interface de entrada ou á orixe traducida, máis unha declaración de tradución ligada a cada interface exterior. Captura á vez en ambas interfaces mentres o cliente se conecta; un SYN que chega polo ISP B co SYN-ACK saíndo polo ISP A resolve a cuestión nunha soa pasada.

Dálle ao cliente unha forma de saber da segunda entrada

O failover é unha decisión do lado do cliente, e cada familia de clientes aprende as alternativas de forma distinta. Nun ASA, a lista de servidores de reserva entrégase mediante os atributos webvpn da política de grupo, mentres que outros clientes esperan unha lista dentro do perfil ou un segundo perfil manual que o usuario escolle. A guía de políticas de conexión de Cisco describe tanto a información configurada no cliente como a proporcionada pola pasarela, e eses detalles específicos do protocolo non deben xeneralizarse a cada cliente ou modo de túnel. Confirma que mecanismo implementa o cliente despregado antes de construír a segunda entrada arredor do equivocado.

Sexa cal sexa o mecanismo, o cliente debe poder resolver o nome alternativo antes de perder a ruta primaria. Esa dependencia é a que a xente pasa por alto: se o nome de reserva o responde un resolutor só accesíbel polo túnel que acaba de fallar, a reserva nin sequera pode comezar. Publica o segundo nome nun resolutor que responda localmente ou por internet. Espera unha autenticación nova e unha sesión de aplicación nova tras o cambio, porque o failover do cliente non é failover con estado e as sesións longas non o sobreviven.

Un enderezo en dous provedores é outro produto

Manter un único enderezo público accesíbel por ambos circuítos é un servizo de encamiñamento, non unha casilla no VPN. Necesita espazo de enderezos que ambos provedores estean dispostos a transportar, anunciado de forma que as súas redes o acepten, e iso é o que dá o multihoming con espazo independente do provedor e BGP. Asignar o enderezo do ISP A á interface do ISP B non chega aí; o paquete chega a unha rede que nunca anunciou o prefixo e descártase augas arriba.

Non necesitas nada diso para publicar dúas entradas. Se o cliente pode manter dous nomes e fallar entre eles, dúas entradas independentes abondan, e aforras un número AS, un acordo de peering e un prefixo que deba aceptarse en todas partes. Considera a opción de enderezo portátil só cando de verdade necesites un punto de entrada estable que os clientes non poidan reconfigurar para substituír, ou cando o failover baseado en DNS co seu retardo de TTL sexa demasiado lento para a interrupción contra a que deseñas.

Que comprobar despois

Traballa cara a fóra desde a entrada que falla nesta orde: se o segundo enderezo responde desde fóra, se presenta a identidade que o cliente espera, se a resposta sae polo camiño polo que chegou a petición, e se o cliente pode aprender o nome antes de necesitalo. Onde a resposta sexa non, arranxa esa capa e volve probar co perfil despregado e non cun host de proba, porque un handshake do laboratorio demostra menos que unha conexión completada polo cliente real.

Mantén un rexistro breve por WAN, con enderezo, porto, interface de terminación, nome do certificado, ruta de retorno e regra de tradución, e revísao cada vez que cambie un circuíto, un dispositivo NAT ou unha versión de cliente. As rutas de reserva inactivas podrecen en silencio: nada avisa da entrada que ninguén usa ata o día en que todos dependen dela.