Encaminament recursiu: quan el túnel captura els seus propis paquets

El túnel s’aixeca, el registre mostra un intercanvi de claus complet i, un segon després, la mateixa sessió mor i es reconnecta en bucle. Aquest patró té una causa concreta: la ruta al servidor ara apunta dins del túnel, de manera que els paquets que porten el túnel s’envien pel túnel. No ha canviat res de l’autenticació, i per això tornar a introduir les credencials no serveix de res. Compareu el camí exterior abans i després del canvi de ruta i la recursió es fa visible.

Primer, comproveu el camí exterior

Hi ha dos paquets en joc, no un. El paquet interior pertany a l’aplicació i ha d’anar xifrat, mentre que el paquet exterior s’adreça al servidor i l’ha de poder assolir per un camí que no depengui del túnel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Pregunteu al nucli per la ruta a l’adreça del servidor un cop el túnel és actiu, i una altra vegada després que canviï la ruta per defecte. Un salt següent que acabi al dispositiu del túnel és la recursió, i es veu sense cap captura de paquets. L’enllaçament a una interfície, les marques o un espai de noms de xarxa poden fer incompleta una consulta simple, així que feu servir el context que utilitza el mateix client. Quan la resposta sembla correcta però la sessió continua en bucle, llegiu les regles de la política d’encaminament i no només la taula principal.

Per què la sessió sobreviu un moment

L’intercanvi de claus es completa abans que s’instal·li la ruta nova, així que els primers segons semblen sans. Quan el client afegeix la ruta per defecte, el paquet exterior següent la segueix cap a la interfície per la qual aquest paquet ha de viatjar. El servidor no veu res, el client retransmet i el reintent o bé expira o bé mata la sessió i comença de nou.

Aquest ordre explica per què un túnel pot funcionar en un portàtil i fallar en un encaminador, i per què la fallada sovint comença quan arrenca el trànsit i no en el moment de connectar-se. També explica el bucle: cada reinici torna a establir la sessió abans que la ruta ho faci impossible.

Trobeu qui és el propietari de l’excepció de l’extrem

Els clients compatibles arreglen la seva pròpia excepció: una ruta d’amfitrió al servidor a través de la passarel·la original, o una marca que manté el sòcol exterior fora del túnel. La pregunta és si alguna altra cosa l’ha eliminada o l’ha superada.

En IPsec basat en rutes, reviseu els selectors de política que decideixen quins paquets entren al túnel i confirmeu que l’adreça del parell n’està exclosa. En WireGuard, la marca de tallafoc de la interfície i les seves regles de política mantenen els paquets de transport fora del túnel, així que una ruta per defecte afegida a mà pot trencar aquesta disposició. Un segon perfil de VPN o un script de gestió que reescriu la ruta per defecte és un culpable habitual. L’addició d’amplis regles d’omissió d’un en un és el resultat normal, i converteixen un error d’encaminament en una taula que ningú no pot mantenir.

Torneu a comprovar-ho després d’un canvi de xarxa

Una ruta d’amfitrió a través d’una passarel·la Wi-Fi és correcta fins que la màquina es trasllada a una altra xarxa. Llavors el mateix símptoma torna sense cap canvi de configuració.

Anoteu l’adreça de l’extrem, la ruta abans i després de connectar i la interfície que havia fet servir cadascuna. Aquests tres fets solen separar un error del client d’una superació, i sobreviuen a la persona que els va recollir.

Reconnecteu-vos a la xarxa nova i repetiu la lectura. Si l’excepció torna a faltar, la correcció pertoca al perfil que la posseeix, no a una ordre puntual escrita durant una avaria.