La segona entrada VPN de WAN falla mentre la primària continua funcionant

El túnel primari es manté aixecat, els usuaris continuen treballant i el segon circuit d'ISP queda inactiu facis el que facis. Heu publicat una adreça per al circuit de reserva, hi heu apuntat un nom, potser heu afegit una entrada de reserva al client, i el client o bé no la prova mai o s'autentica i després mor. En els casos que he seguit, la funció de failover solia estar bé; el que faltava era una de les cinc coses que fan que una entrada sigui utilitzable. Un nom pot resoldre's a l'adreça de reserva mentre no hi ha res escoltant en aquella interfície, i un oient pot acceptar una connexió mentre la resposta surt per la primària. Tracteu cada WAN com una entrada separada amb el seu propi contracte i la fallada deixa de semblar un error del client.

Cada WAN necessita el seu propi contracte d'entrada

Anoteu cinc camps per WAN: el nom i l'adreça públics, el transport i el port, la interfície o el context que el termina, la identitat de parell que ha de presentar i d'on surt la resposta. Dos circuits volen dir dos jocs complets. Si el segon joc no té interfície de terminació ni camí de retorn, no teniu una entrada de reserva; teniu un registre DNS que descriu una intenció.

L'aparell i la seva versió també han de suportar aquesta disposició. Un registre DNS no pot obrir un servei en una altra interfície, i en moltes plataformes l'oient es configura per adreça i no per dispositiu. L'IPsec basat en interfície en un ASA lliga mapes criptogràfics i grups de túnel a la interfície exterior, així que un segon enllaç ascendent necessita política allà on aquests paquets arriben de veritat. Els dissenys basats en rutes es comporten diferent: l'oient es pot lligar a totes les adreces o a una adreça concreta, i aquesta tria decideix si l'ISP B pot respondre o no.

Comproveu que el segon WAN respon de veritat

Proveu-ho des de fora dels dos circuits, no des d'una màquina darrere la passarel·la, i proveu el nom exacte que fa servir el perfil del client. Per a un oient TLS, la comprovació ràpida és openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts executada des d'un amfitrió fora de la vostra xarxa. Voleu un handshake complet l'encadenament del qual coincideixi amb el nom del perfil, no només un port TCP que accepti una connexió.

RFC 9525 explica què comprova el client: la identitat a què pretenia arribar, comparada amb el certificat que presenta el servei. Una segona entrada que retorna el certificat de l'entrada primària, o un certificat per defecte que no llista cap dels dos noms, falla aquesta prova encara que el port estigui obert i el tallafoc ho permeti.

Dos patrons expliquen la majoria de fallades aquí. Una connexió que es penja normalment vol dir que no hi ha oient en aquella interfície, una regla d'accés que només permet les subxarxes primàries, o un dispositiu de l'operador davant del segon circuit que descarta el port. Un handshake que acaba amb la identitat equivocada normalment vol dir un trustpoint diferent, un host virtual per defecte, o configuració copiada de la primària sense ajustar la identitat.

Seguiu la resposta, no només la petició

El segon WAN normalment es trenca a la tornada. Una petició arriba per l'ISP B, l'aparell respon, i la resposta surt per la ruta per defecte de l'ISP A amb una adreça d'origen que el client no havia demanat mai. La traducció amb estat ho empitjora: si el mapatge es va construir per a la interfície primària, el paquet de tornada no troba la traducció o porta un origen que el tallafoc del client descarta. Els proveïdors també descarten adreces d'origen que no pertanyen al circuit que us han donat, i per això això sembla un forat negre unidireccional en lloc d'un error de protocol net.

Comproveu la decisió d'encaminament per al trànsit originat en la segona entrada. La resposta ha de sortir per la interfície per on va arribar la petició, o com a mínim portar una adreça que el costat llunyà accepti com a pertanyent a aquest camí. En plataformes d'encaminament per política això vol dir una regla lligada a la interfície d'entrada o a l'origen traduït, més una declaració de traducció lligada a cada interfície exterior. Captureu alhora a les dues interfícies mentre el client es connecta; un SYN que arriba per l'ISP B amb el SYN-ACK que surt per l'ISP A resol la qüestió en una sola passada.

Doneu al client una manera de saber de la segona entrada

El failover és una decisió del costat del client, i cada família de clients aprèn les alternatives de manera diferent. En un ASA, la llista de servidors de reserva es lliura mitjançant els atributs webvpn de la política de grup, mentre que altres clients esperen una llista dins del perfil o un segon perfil manual que l'usuari tria. La guia de polítiques de connexió de Cisco descriu tant la informació configurada al client com la proporcionada per la passarel·la, i aquests detalls específics del protocol no s'han de generalitzar a cada client o mode de túnel. Confirmeu quin mecanisme implementa el client desplegat abans de construir la segona entrada al voltant del mecanisme equivocat.

Sigui quin sigui el mecanisme, el client ha de poder resoldre el nom alternatiu abans de perdre el camí primari. Aquesta dependència és la que la gent passa per alt: si el nom de reserva el respon un resolutor només abastable pel túnel que acaba de fallar, la reserva no pot ni començar. Publiqueu el segon nom en un resolutor que respongui localment o per internet. Espereu una autenticació nova i una sessió d'aplicació nova després del canvi, perquè el failover del client no és failover amb estat i les sessions llargues no el sobreviuen.

Una adreça en dos proveïdors és un altre producte

Mantenir una única adreça pública abastable pels dos circuits és un servei d'encaminament, no una casella al VPN. Necessita espai d'adreces que els dos proveïdors estiguin disposats a portar, anunciat de manera que les seves xarxes ho acceptin, i això és el que dona el multihoming amb espai independent del proveïdor i BGP. Assignar l'adreça de l'ISP A a la interfície de l'ISP B no hi arriba; el paquet arriba a una xarxa que mai va anunciar el prefix i es descarta més amunt.

No necessiteu res d'això per publicar dues entrades. Si el client pot mantenir dos noms i fallar entre ells, dues entrades independents són prou, i us estalvieu un número AS, un acord de peering i un prefix que s'hagi d'acceptar a tot arreu. Considereu l'opció d'adreça portàtil només quan realment necessiteu un punt d'entrada estable que els clients no es puguin reconfigurar per substituir, o quan el failover basat en DNS amb el seu retard de TTL sigui massa lent per a la interrupció contra la qual dissenyeu.

Què cal comprovar després

Partiu de l'entrada que falla i aneu cap enfora en aquest ordre: la segona adreça respon des de fora, presenta la identitat que el client espera, la resposta surt pel camí per on va arribar la petició, i el client pot aprendre el nom abans de necessitar-lo. On la resposta sigui no, arregleu aquella capa i torneu a provar amb el perfil desplegat i no amb un amfitrió de prova, perquè un handshake del laboratori demostra menys que una connexió completada pel client real.

Mantingueu un registre breu per WAN, amb adreça, port, interfície de terminació, nom del certificat, camí de retorn i regla de traducció, i reviseu-lo sempre que canviï un circuit, un dispositiu NAT o una versió de client. Els camins de reserva inactius es podreixen en silenci: res no avisa de l'entrada que ningú no fa servir fins al dia que tothom en depèn.