Por que un kill switch corta o tráfico ao cambiar de servidor
Por que un kill switch bloquea o tráfico durante un cambio de servidor, que fai o cliente nese intervalo e como distinguir unha pausa normal dun bloqueo atascado.
Escolles un servidor que parece máis preto, premes conectar e o navegador deixa de cargar antes de que o túnel novo estea erguido. A icona pasa a un estado de conexión e queda aí mentres cada pestana esgota o tempo. Esa pausa adoita ser o kill switch traballando como está deseñado: o tráfico queda bloqueado mentres o cliente non ten túnel por onde envialo. Se a pausa é aceptable depende do que faga o cliente neses segundos e de se o bloqueo se levanta cando di que o fai.
Que fai o cliente entre dous servidores
Un cambio de punto final son varios pasos, non un interruptor. O cliente desmonta o túnel actual, actualiza as súas regras de bloqueo, resolve e chega ao novo punto final fóra do túnel, e despois instala as rutas novas e levanta o bloqueo. O oco que notas vive entre o primeiro paso e o último.
Aquí a orde importa máis ca a velocidade. Se as regras de bloqueo entran antes da excepción para o novo punto final, o cliente non pode completar o aperto de mans e queda en conectando ata un tempo de espera. Se a excepción é unha copia do enderezo do servidor vello, o novo aperto de mans parece calquera outro paquete de saída e descártase. Ambos os casos vense iguais desde o navegador, e por iso un cambio que se recupera aos seis segundos e un que nunca se recupera poden compartir a causa.
O novo punto final necesita un burato no bloqueo
Para construír o túnel, o cliente debe enviar paquetes ao enderezo e ao porto do servidor novo pola interface física, por exemplo UDP 51820 nun perfil típico de WireGuard ou 1194 e 443 para OpenVPN, sexa o que sexa o que especifique o teu propio perfil. Ese tráfico non está dentro do túnel que está a piques de crear, así que un bloqueo de todo o dispositivo trágao salvo que exista unha regra de permiso que encaixe.
Os perfís baseados en nome de host engaden un segundo requisito: a consulta en si. Se o cliente resolve o punto final antes de que suba o bloqueo, pode usar un enderezo na caché, pero cando o perfil rota os enderezos ou a entrada da caché queda vella, o aperto de mans vai cara a un enderezo que a regra de permiso non cobre. IPv6 faino visible, porque un punto final de dobre pila pode publicar tanto un rexistro A como un AAAA, e unha regra de permiso que só cobre o enderezo v4 deixa o cliente reintentando contra un enderezo v6 bloqueado.
Os nomes das opcións e os valores por defecto cambian segundo o cliente e a versión, así que le a lista documentada do teu en lugar de adiviñar a partir de capturas de pantalla. A referencia de axustes de OpenVPN Connect en openvpn.net/connect-docs/app-settings-windows é un exemplo de como un cliente describe as súas opcións de bloqueo e de túnel dividido.
Fail-closed é unha máquina de estados, non un interruptor
A maioría dos clientes expresan o bloqueo como política de devasa en tres estados: túnel arriba, co tráfico pasando polo túnel e sen bloqueo; túnel abaixo, co bloqueo activo; e transición, co bloqueo activo máis excepcións temporais para o punto final. No terceiro estado viven os erros, porque ten que cambiar dúas veces nun par de segundos, e non saír del vese exactamente como un bloqueo permanente.
O mecanismo cambia segundo a plataforma, e o fallo tamén. Os filtros de Windows Filtering Platform levan pesos, así que un filtro de bloqueo que supera o teu permiso segue descartando paquetes aínda que o permiso exista, e os filtros que deixa un proceso de cliente morto poden manter a máquina sen conexión despois de que a aplicación desapareza. Os clientes de macOS adoitan escribir regras pf nun anchor, onde a orde das regras e as decisións rápidas deciden que regra se aplica. Os clientes de Linux adoitan xestionar unha cadea nftables ou iptables con política drop e permisos explícitos para o punto final, a interface do túnel e o loopback. A VPN sempre activa de Android coa opción de bloquear conexións sen VPN é a máis estrita do grupo, porque o sistema aplica o bloqueo a todo o dispositivo e non por aplicación.
WireGuard necesita a súa propia nota, porque AllowedIPs é un selector de encamiñamento, non un bloqueador. Decide que destinos entran no túnel; non fai nada para impedir que un paquete que aínda non ten túnel saia por Wi-Fi. Nunha configuración só con WireGuard e sen regra de devasa, o kill switch é en realidade a ausencia dunha ruta, e tras un aperto de mans descartado pode saír un paquete real pola interface física.
Mide o oco en lugar de mirar a icona
Vixía os paquetes, non a luz de estado. En Linux, lanza un ping lento contra un enderezo público nunha terminal e captura o porto de transporte do túnel na interface física noutra:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Cambia de servidor no cliente mentres ambos corren. Tres cousas importan: canto tempo se deteñen os ping, se a captura mostra o aperto de mans chegando ao novo punto final e se o tráfico volve antes ou despois de que o estado do cliente pase a conectado. Se o oco dos ping remata primeiro, ou o bloqueo se levantou cedo ou o túnel xa está arriba antes de que o indicador o admita. Se o oco remata máis tarde, o indicador é optimista.
En Windows, netsh wfp show state escribe unha instantánea na que podes buscar filtros de bloqueo que seguen presentes mentres o cliente afirma estar desconectado. En macOS, sudo pfctl -sr lista as regras cargadas e a súa orde. Combina calquera das instantáneas co rexistro propio do cliente; a liña temporal do teu ping diche se o bloqueo rematou tarde ou non rematou nunca.
Apagón normal fronte a bloqueo atascado
Algo de interrupción é o propósito da función, así que fai triaxe antes de cambiar calquera axuste:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Se acabas na segunda ou na quinta fila, non desactives o kill switch para probar, porque iso converte un erro de encamiñamento nunha fuga. Reinicia o servizo do cliente, ou reinicia a máquina onde os filtros sobreviven á morte do proceso, e mira se o bloqueo se despexa. Se se despexa, o fallo está na limpeza durante o cambio e non no bloqueo.
Antes do teu próximo cambio, confirma catro cousas: o permiso do punto final cobre cada familia de enderezos que resolve o teu perfil, o rexistro do cliente mostra a transición completada, a túa proba de ping mide o oco e non a icona, e pechar o cliente restaura a conectividade normal. Un kill switch que aguanta durante o cambio e solta despois fai o seu traballo. Un que solta cedo, ou nunca, merece depuración.