Per què un kill switch talla el trànsit quan canvies de servidor
Per què un kill switch bloqueja el trànsit durant un canvi de servidor, què fa el client en aquest interval i com distingir una pausa normal d'un bloqueig encallat.
Tries un servidor que sembla més a prop, prems connecta i el navegador deixa de carregar abans que el túnel nou estigui aixecat. La icona passa a un estat de connexió i s'hi queda mentre cada pestanya esgota el temps. Aquesta pausa sol ser el kill switch treballant tal com està dissenyat: el trànsit queda bloquejat mentre el client no té cap túnel per on enviar-lo. Si la pausa és acceptable depèn del que fa el client en aquests segons i de si el bloqueig s'aixeca quan diu que ho fa.
Què fa el client entre dos servidors
Un canvi de punt final són diverses passes, no un sol commutador. El client desmunta el túnel actual, actualitza les seves regles de bloqueig, resol i arriba al punt final nou fora del túnel, i després instal·la les rutes noves i aixeca el bloqueig. El buit que notes viu entre la primera passa i l'última.
Aquí l'ordre importa més que la velocitat. Si les regles de bloqueig entren abans de l'excepció per al punt final nou, el client no pot completar l'encaixada de mans i es queda en connectant fins a un temps d'espera. Si l'excepció és una còpia de l'adreça del servidor vell, l'encaixada nova sembla qualsevol altre paquet de sortida i es descarta. Els dos casos es veuen iguals des del navegador, i per això un canvi que es recupera als sis segons i un que no es recupera mai poden compartir la causa.
El punt final nou necessita un forat al bloqueig
Per construir el túnel, el client ha d'enviar paquets a l'adreça i el port del servidor nou per la interfície física, per exemple UDP 51820 en un perfil típic de WireGuard o 1194 i 443 per a OpenVPN, sigui el que sigui que especifiqui el teu perfil. Aquest trànsit no és dins del túnel que està a punt de crear, així que un bloqueig de tot el dispositiu se'l menja tret que existeixi una regla de permís que hi encaixi.
Els perfils basats en nom d'amfitrió afegeixen un segon requisit: la consulta mateixa. Si el client resol el punt final abans que pugi el bloqueig, pot fer servir una adreça emmagatzemada, però quan el perfil rota les adreces o l'entrada de la memòria cau es fa vella, l'encaixada va cap a una adreça que la regla de permís no cobreix. IPv6 ho fa visible, perquè un punt final de doble pila pot publicar tant un registre A com un AAAA, i una regla d'allow que només cobreix l'adreça v4 deixa el client reintentant contra una adreça v6 bloquejada.
Els noms de les opcions i els valors per defecte varien segons el client i la versió, així que llegeix la llista documentada per al teu en lloc d'endevinar a partir de captures de pantalla. La referència de configuració d'OpenVPN Connect a openvpn.net/connect-docs/app-settings-windows és un exemple de com un client descriu les seves opcions de bloqueig i de túnel dividit.
Fail-closed és una màquina d'estats, no un commutador
La majoria de clients expressen el bloqueig com a política de tallafocs en tres estats: túnel aixecat, amb el trànsit passant pel túnel i sense bloqueig; túnel baixat, amb el bloqueig actiu; i transició, amb el bloqueig actiu més excepcions temporals per al punt final. És en el tercer estat on viuen els errors, perquè ha de canviar dues vegades en un parell de segons, i no sortir-ne sembla exactament un bloqueig permanent.
El mecanisme difereix per plataforma, i la fallada també. Els filtres de Windows Filtering Platform porten pesos, així que un filtre de bloqueig que supera el teu permís continua descartant paquets tot i que el permís existeixi, i els filtres que deixa un procés de client assassinat poden mantenir la màquina fora de línia després que l'aplicació desaparegui. Els clients de macOS solen escriure regles pf en un anchor, on l'ordre de les regles i les decisions ràpides decideixen quina regla s'aplica. Els clients de Linux solen gestionar una cadena nftables o iptables amb política drop i permisos explícits per al punt final, la interfície del túnel i el loopback. L'VPN sempre activa d'Android amb l'opció de bloquejar connexions sense VPN és la més estricta del grup, perquè el sistema aplica el bloqueig a tot el dispositiu i no per aplicació.
WireGuard necessita una nota pròpia, perquè AllowedIPs és un selector d'encaminament, no un bloquejador. Decideix quines destinacions entren al túnel; no fa res per impedir que un paquet que encara no té túnel surti per Wi-Fi. En una configuració només amb WireGuard i sense regla de tallafocs, el kill switch és en realitat l'absència d'una ruta, i darrere d'una encaixada descartada pot sortir un paquet real per la interfície física.
Mesura el buit en lloc de mirar la icona
Vigila els paquets, no el llum d'estat. A Linux, engega un ping lent contra una adreça pública en un terminal i captura el port de transport del túnel a la interfície física en un altre:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Canvia de servidor al client mentre tots dos corren. Tres coses importen: quant de temps s'aturen els pings, si la captura mostra l'encaixada arribant al punt final nou i si el trànsit torna abans o després que l'estat del client passi a connectat. Si el buit dels pings s'acaba primer, o bé el bloqueig s'aixeca aviat o bé el túnel ja és a dalt abans que l'indicador ho admeti. Si el buit s'acaba més tard, l'indicador és optimista.
A Windows, netsh wfp show state escriu una instantània on pots buscar filtres de bloqueig que encara hi són mentre el client afirma estar desconnectat. A macOS, sudo pfctl -sr llista les regles carregades i el seu ordre. Combina qualsevol instantània amb el registre propi del client; la línia temporal del teu ping et diu si el bloqueig va acabar tard o no va acabar mai.
Apagada normal contra bloqueig encallat
Una mica d'interrupció és el propòsit de la funció, així que fes triatge abans de canviar cap paràmetre:
| 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 |
Si acabes a la segona o la cinquena fila, no desactivis el kill switch per provar, perquè això converteix un error d'encaminament en una fuita. Reinicia el servei del client, o reinicia l'ordinador on els filtres sobreviuen a la mort del procés, i mira si el bloqueig s'esborra. Si s'esborra, la fallada és la neteja durant el canvi i no el bloqueig.
Abans del proper canvi, confirma quatre coses: el permís del punt final cobreix cada família d'adreces que resol el teu perfil, el registre del client mostra la transició completada, la teva prova de ping mesura el buit i no la icona, i tancar el client restaura la connectivitat normal. Un kill switch que aguanta durant el canvi i deixa anar després fa la seva feina. Un que deixa anar aviat, o mai, val la pena depurar-lo.