Enrutamento recursivo: cando o túnel captura os seus propios paquetes

O túnel levanta, o rexistro mostra unha aperta de mans completada e, un segundo despois, a mesma sesión morre e reconéctase nun bucle. Ese patrón ten unha causa concreta: a ruta ao servidor agora apunta cara a dentro do túnel, así que os paquetes que transportan o túnel envíanse polo túnel. Nada cambiou na autenticación, e por iso volver introducir as credenciais non serve de nada. Compare o camiño exterior antes e despois do cambio de ruta e a recursión faise visible.

Comprobe primeiro o camiño exterior

Hai dous paquetes en xogo, non un. O paquete interior pertence á aplicación e debería ir cifrado, mentres que o paquete exterior vai dirixido ao servidor e debe chegar a el por un camiño que non dependa do 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

Pregunte ao núcleo pola ruta ao enderezo do servidor unha vez levantado o túnel, e outra vez despois de que cambie a ruta predeterminada. Un seguinte salto que aterre no dispositivo do túnel é a recursión, e vese sen ningunha captura de paquetes. A vinculación a unha interface, as marcas ou un espazo de nomes de rede poden deixar incompleta unha consulta simple, así que use o contexto que usa o propio cliente. Cando a resposta parece correcta pero a sesión segue en bucle, lea as regras da política de enrutamento e non só a táboa principal.

Por que a sesión sobrevive un intre

A aperta de mans complétase antes de que se instale a ruta nova, así que os primeiros segundos parecen sans. En canto o cliente engade a ruta predeterminada, o seguinte paquete exterior séguena cara á interface pola que ese paquete exterior ten que viaxar. O servidor non ve nada, o cliente retransmite e o intento ou ben expira ou ben mata a sesión e comeza de novo.

Ese orde explica por que un túnel pode funcionar nun portátil e fallar nun router, e por que o fallo adoita comezar cando arranca o tráfico e non ao conectar. Tamén explica o bucle: cada reinicio restablece a sesión antes de que a ruta o faga imposible.

Averigüe quen é o dono da excepción do extremo

Os clientes compatibles preparan a súa propia excepción: unha ruta de host ao servidor a través da pasarela orixinal, ou unha marca que mantén o zócolo exterior fóra do túnel. A pregunta é se algo máis a eliminou ou a anulou.

En IPsec baseado en rutas, revise os selectores de política que deciden que paquetes entran no túnel e confirme que o enderezo do par queda excluído deles. En WireGuard, a marca de cortalumes da interface e as súas regras de política manteñen os paquetes de transporte fóra do túnel, así que unha ruta predeterminada engadida a man pode romper esa disposición. Un segundo perfil de VPN ou un script de administración que reescriba a ruta predeterminada é un culpable habitual. As regras de omisión amplas engadidas unha a unha son o resultado normal, e converten un erro de enrutamento nunha táboa que ninguén pode manter.

Volva comprobar tras un cambio de rede

Unha ruta de host por unha pasarela Wi-Fi é correcta ata que a máquina pasa a outra rede. Entón o mesmo síntoma volve sen ningún cambio de configuración.

Anote o enderezo do extremo, a ruta antes e despois de conectar e a interface que usou cada unha. Eses tres feitos adoitan separar un erro do cliente dunha anulación, e sobreviven á persoa que os recolleu.

Volva conectar na rede nova e repita a lectura. Se a excepción volve faltar, a corrección pertence ao perfil que a posúe, non a unha orde puntual escrita durante unha avaría.