Interruptor de emerxencia tras un cambio de Wi-Fi a móbil: que se rompe

Nun momento o portátil está na Wi-Fi da oficina, no seguinte está conectado a un teléfono, e o indicador do túnel volve estar verde antes de que remates de cambiar de xanela. A luz verde só informa de que o túnel se reconectou; que fixo a política de encamiñamento e bloqueo durante o oco é outra pregunta. Esa política é un conxunto de condicións de coincidencia compiladas cando se instalou por última vez, e nomea unha interface, un enderezo e unha familia de enderezos que a transición acaba de eliminar. O mesmo cambio produce, xa que logo, tres resultados que parecen idénticos: o bloqueo continúa, a política bloquea a súa propia recuperación, ou ábrese un camiño que nada cobre.

Nada na pantalla separa eses tres estados, así que pregunta a que identificadores estaban ancoradas as regras en lugar de que cor mostra o indicador. En Linux unha regra pode nomear unha interface ou un ipset enchido desde unha; en Android pódeselle dicir a un VpnService que redes subxacentes seguir mediante setUnderlyingNetworks. Cada ancoraxe apunta a unha ligazón que está a piques de ser substituída, e cada unha debe reevaluarse despois.

Que reescribe realmente a transición

Cando a ligazón antiga desaparece, o núcleo elimina os seus enderezos, retira as rutas que apuntaban a través dela e reconstrúe a selección de enderezo de orixe co que queda. A ruta por defecto móvese á nova pasarela, e o índice de interface ao que facían referencia as regras antigas desapareceu ou reciclouse para outro dispositivo. Os resolutores por ligazón tamén se refrescan, aínda que non no mesmo instante que as rutas. Todo isto ocorre por debaixo do cliente VPN, así que un cliente que só vixía o estado do seu propio túnel non ve nada diso.

O problema é que unha regra codifica un identificador concreto en lugar da intención que hai detrás. Unha regra que descarta todo o que non sae pola interface do túnel codifica un nome de interface; unha regra que permite o punto final codifica un enderezo que a nova rede pode encamiñar a outro sitio. Cando o identificador desaparece, a regra non se volve visiblemente incorrecta: ou deixa de coincidir con nada ou comeza a coincidir coa cousa equivocada.

Reconstruír o túnel exterior sen abrir un burato

O transporte exterior estaba ligado ao enderezo de orixe antigo, así que ten que abrir un socket novo desde o novo. Cando o punto final é un nome de host e non un enderezo literal, unha consulta debe ter éxito mentres o bloqueo segue vixente. Ese é o lazo da orde: unha política o bastante estrita como para descartar todo agás o punto final tamén descartará a consulta necesaria para atopalo, salvo que a resolución ocorra antes de levantar o bloqueo ou se leve por un túnel que aínda estea vivo. Calquera das dúas ordes pode funcionar, pero só se o cliente sabe en cal está.

Os clientes difiren aquí dun xeito que importa ao diagnosticar. Algúns resolven primeiro e instalan as regras despois, de modo que unha transición custa unha interrupción visible e logo recupérase só; outros manteñen o bloqueo e dependen do túnel supervivente para levar a consulta, o que falla de todo cando o túnel morreu coa ligazón. Engadir unha ruta directa por defecto ampla para restaurar a conectividade sempre fai pasar a proba e sempre deixa a fuga que estabas evitando.

Unha ruta que aínda apunta á pasarela antiga dá a mesma recuperación atascada por unha causa distinta, así que le a táboa antes de culpar o cliente. Os comandos de abaixo nomean a interface e o enderezo de orixe que o núcleo usaría de verdade, o que resolve nunha liña se o camiño antigo segue instalado.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Cando a ligazón nova trae IPv6 e as regras non

As redes móbiles e de convidados adoitan repartir un prefixo IPv6 global aínda que a LAN cableada da oficina nunca o fixese. Unha política escrita só como regras IPv4, a forma por defecto da maioría das receitas feitas a man de iptables e nftables, non cobre nada diso. O túnel segue conectado, as aplicacións con alcance IPv6 saen fóra del, e o indicador non pode mostrar a diferenza porque o túnel realmente está levantado. O caso espello é igual de común: un conxunto de regras só para IPv6 non fai nada nunha rede que non ofrece v6.

Compara o que ofrece a ligazón co que menciona a política, nos dous lados da transición. Estes comandos imprimen os mesmos feitos cos que traballa o cliente:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Se o segundo comando imprime unha ruta por defecto mentres o terceiro devolve cero, a ligazón nova pode sacar a máquina por IPv6 sen ningunha regra que o vixíe. Executa os tres de novo tras o cambio, porque o número interesante é a diferenza entre as dúas execucións. Se o segundo non imprime nada, aplícase o caso inverso e calquera política cargada de v6 alí é só decoración.

O resolutor cambia de mans a metade de sesión

Nos sistemas modernos os resolutores van ligados ás ligazóns, así que unha ligazón nova chega cun conxunto novo de resolutores e quizais cunha vista distinta de split-DNS. systemd-resolved mantén un ámbito por ligazón e escolle entre eles por ruta, mentres que macOS le resolutores con ámbito do almacén dinámico e respecta a orde de interfaces. Un cliente que instala o seu propio resolutor compite co da ligazón, e as regras de prioridade que ninguén vixía deciden o gañador. Entón a resolución de nomes pode romper mentres o filtrado de paquetes fai exactamente aquilo para o que se escribiu.

Le o resolutor que está activo en lugar do configurado. Nun host systemd o subcomando status mostra de que ligazón veu cada ámbito e se hai un nome private-DNS vixente:

resolvectl status --no-pager
resolvectl query intranet.example.com

Se a consulta sae pola ligazón física en lugar do túnel, o cliente perdeu a competición de prioridade e ningún axuste da devasa arranxará o nomeado. Compara o camiño da consulta nos dous lados da transición para ver cal se moveu. Un nome que resolve a un enderezo privado que a nova rede non pode encamiñar é un terceiro caso, e preséntase como un tempo de espera e non como un erro.

Ensaya a transición e garda o rexistro

Reproduce o cambio a propósito en lugar de agardalo. Levanta o túnel na primeira ligazón, inicia unha transferencia longa e unha consulta repetida, logo cambia a ligazón e observa cal sobrevive. Anota o intervalo entre a desaparición da ligazón antiga e o informe do túnel de que está conectado, porque nesa xanela a política ou aguantou ou non. Executa a secuencia tamén na outra dirección, para que o resultado non sexa unilateral.

As excepcións necesitan o seu propio paso, porque unha omisión xustificada na rede antiga non queda xustificada automaticamente na nova. Unha impresora, un NAS ou un portal cativo na LAN da casa non teñen equivalente no móbil, e a excepción que chegaba a eles convértese nunha regra sen equivalente.

Anota os nomes de interface, as familias ofrecidas, o resolutor vixente e a duración da interrupción para cada dirección. Unha reconexión demostra que o transporte se recuperou, non que o bloqueo aguantase durante o oco, e son afirmacións separadas que pór nun tícket. Con ese rexistro a próxima transición compárase cun estado coñecido e non coa memoria.