L’interruptor de seguretat bloqueja el servidor VPN abans que hi circuli cap trànsit
Quina etapa bloqueja un interruptor de seguretat: la cerca del punt final, la ruta exterior, el camí de tornada i les excepcions obsoletes de parells, amb comptadors en lloc de conjectures.
Els interruptors de seguretat fallen en una direcció que la gent no espera: estan fets per bloquejar el trànsit mentre el túnel està caigut, i els paquets que construeixen el túnel són ells mateixos trànsit. Aquest és el problema sencer. Un conjunt de regles que descarta tot el que no surt pel túnel també descarta l’intercanvi de claus que l’hauria d’aixecar, així que el client reintenta en bucle i l’error s’atribueix a l’etapa que es comprova primer. Abans d’ampliar un tallafoc, esbrineu quina de les tres etapes es denega: la cerca del nom, el paquet exterior cap al parell o la resposta que torna.
Com depenen l’un de l’altre el túnel i el seu propi transport
Llegiu un client VPN com dos estats de xarxa que comparteixen un sol camí de sòcol. Abans que existeixi el túnel, el client obre un sòcol a l’adaptador físic i envia trames xifrades a l’adreça i el port del parell. Només quan aquest intercanvi té èxit crea el dispositiu de túnel i instal·la les rutes. Un interruptor de seguretat és una política sobre el segon estat, escrita tan àmpliament que s’aplica a tots dos.
Les regles basades en la interfície són la forma habitual: accepteu el que surt per tun0 o wg0, descarteu la resta del camí de sortida. Aquesta formulació no pot eximir la connexió pròpia del client amb el servidor, així que una implementació correcta hi afegeix aquesta excepció explícitament, i vosaltres també quan escriviu regles a mà. Les regles per aplicació a Windows i macOS eviten part d’això fent coincidir un procés en lloc d’una interfície, però el procés encara ha de sortir abans que existeixi el túnel.
Tres etapes, en l’ordre en què passen
La primera etapa és la resolució. Quan el perfil desa un nom d’amfitrió en lloc d’una adreça literal, el client necessita una resposta DNS abans de poder enviar res. Un perfil que apunta el DNS al resoledor del túnel crea un bloqueig: el resoledor només és abastable a través del túnel que la consulta hauria d’habilitar. Resoldre fora del túnel, o fixar el punt final a una adreça, elimina l’ambigüitat.
La segona etapa és el paquet exterior, que ha de sobreviure primer a l’encaminament i després al tallafoc, en aquest ordre. wireguard-tools s’encarrega de la meitat d’encaminament per a WireGuard marcant els seus propis paquets i afegint una regla de política perquè saltin la ruta per defecte que acaba d’instal·lar; la pàgina de manual de wg-quick descriu aquesta regla i la taula que utilitza. Reconstruïu aquest encaminament a mà, o deixeu que una segona eina reescrigui les regles, i els paquets marcats poden ser enviats de tornada al túnel que han de crear.
La tercera etapa és el camí de tornada. Un intercanvi de claus sense resposta no és prova d’un descartament de sortida; és igualment compatible amb una regla d’entrada del servidor o un dispositiu NAT que ha oblidat la correspondència. Separeu-ho abans de tocar el client.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Els clients registren el símptoma que detecten, no l’etapa que ha fallat, així que la taula sol ser més ràpida que el registre.
Els comptadors decideixen més de pressa que els registres
A Linux, nft list ruleset o iptables -vnL OUTPUT mostra un comptador de paquets per regla. Connecteu-vos una vegada, deixeu que falli i torneu a llegir els comptadors. Una regla el comptador de la qual s’ha mogut és una regla que l’intercanvi de claus ha tocat; si no s’ha mogut res enlloc, el paquet no ha arribat mai al tallafoc. He vist un conjunt de regles descartar el seu propi intercanvi de claus, i només els comptadors ho van dir.
Per separar «no ha arribat mai al tallafoc» de «no ha sortit mai de l’amfitrió», observeu la interfície mateixa. ip -s link show dev wlan0 informa dels paquets enviats, i tcpdump -ni wlan0 udp port 51820 mostra les trames. Si es queda pla mentre el client reintenta, la fallada és per damunt de netfilter: una ruta de parell que falta, una regla de política que apunta a un dispositiu que encara no existeix, o un error de sòcol que el client s’empassa.
Proveu les excepcions amb adreces de documentació com 203.0.113.10, perquè un descuit no pugui sondar l’amfitrió d’algú altre.
Una excepció de punt final obsoleta es llegeix com una caiguda del servidor
La versió més enganyosa apareix després que canviï l’adreça del parell: un servei d’adreces dinàmiques l’ha mogut, l’amfitrió s’ha reconstruït o l’adreça de sortida de la vostra xarxa és diferent. L’excepció encara anomena l’adreça antiga, així que els paquets cap a la nova cauen sota la regla de descartament. La mateixa configuració funcionava ahir, i per això la gent comença per diagnosticar el servidor.
Un nom d’amfitrió dins d’una regla de tallafoc no us salva. A nftables el nom es resol quan es carrega el conjunt de regles, així que fixa l’adreça que existia en aquell moment i es torna obsolet com una de literal. La solució duradora és actualitzar l’excepció quan canvia el punt final i mantenir-la estreta: una adreça de parell, un port de transport. Un interval prou ampli per sobreviure a un canvi d’adreça també ho és per deixar sortir trànsit no relacionat.
Quan l’interruptor de seguretat s’executa a l’amfitrió del servidor
La mateixa dependència existeix a l’altre extrem, i allà és més fàcil passar-la per alt. Si la màquina que fa de servidor VPN també executa un client d’escriptori amb interruptor de seguretat, o un perfil de tallafoc copiat d’un portàtil, les seves regles de descartament s’apliquen al servei que acaba els túnels. Les respostes a l’intercanvi de claus d’un client es descarten, així que tots els clients no es poden connectar mentre el servidor sembla sa i la seva interfície de túnel queda sense ús.
Aquest amfitrió necessita tres acceptacions estretes abans del descartament: el port d’escolta a la interfície física, la interfície de túnel per al trànsit desxifrat i el reenviament des del túnel cap al que els clients han d’abastar. Llegiu el conjunt instal·lat amb nft list ruleset, iptables -S, o pfctl -sr abans de canviar res, i recordeu que un conjunt de regles desat sobreviu a un reinici, així que un error allà sobreviu al procés que el va fer.
Ordre de recuperació que manté la màquina tancada
Treballeu de dins cap a fora des del perfil. Llegiu l’adreça i el port del parell que fa servir el client, confirmeu que el nom d’amfitrió es resol sense el túnel i després afegiu una excepció per a aquesta adreça i port només a l’adaptador físic. Torneu a connectar-vos i observeu el comptador d’enviament; un intercanvi de claus complet és el senyal que la segona etapa està arreglada.
Deixeu la resta de la política de descartament al seu lloc mentre proveu. Una comprovació innòcua és intentar una connexió a una adreça de documentació no relacionada i confirmar que encara expira, cosa que mostra que l’interruptor de seguretat funciona i no que està desactivat. Estrenyeu l’excepció quan el túnel sigui estable, i no deixeu un permís permanent de tot per al binari del client només perquè és còmode.
Si el túnel s’aixeca i l’aplicació encara falla, les etapes restants no són aquesta: el DNS dividit, l’MTU i l’encaminament per aplicació produeixen cadascun un túnel connectat amb trànsit trencat, i cadascun té una primera comprovació diferent.