UFW descarta el servidor DNS de la VPN quan el túnel ja és actiu
La política de denegació per defecte d'UFW també cobreix la interfície del túnel. Ordena el trànsit per direcció, admet el resolutor empès a tun0 i després obre el camí exterior.
Els noms deixen de resoldre's en el moment en què la VPN es connecta, mentre que un ping a una adreça pública encara respon i l'estat del tallafoc no mostra res que sembli incorrecte. No ha canviat res a la política; el que ha canviat és que ha aparegut una interfície nova, i la denegació per defecte la cobreix des del primer paquet. UFW decideix per direcció i interfície, així que una regla escrita per a l'enllaç sense fil no diu res sobre el trànsit que surt del túnel. La reparació és un grapat de regles estretes aplicades en un ordre concret.
El símptoma només apareix quan el túnel ja és actiu
Una política de denegació per defecte fa exactament el que se li ha dit: tot el que no té una regla coincident es rebutja, a cada interfície que existeix. El túnel no existia quan es van escriure les regles, així que cap d'elles no el pot cobrir, i la denegació que sempre hi era ara s'aplica a la resolució de noms. El trànsit directe a una adreça literal encara pot funcionar quan el cobreix un permís més ampli, i per això un ping a un resolutor públic té èxit mentre que la consulta d'un nom falla. El buit és una regla per a una interfície que la política no ha vist mai.
Això també explica per què la fallada s'inverteix netament: treu el túnel i els noms tornen a resoldre's, perquè la consulta torna a una interfície que sí que té regles. Una política que només falla mentre el túnel és actiu no és un problema de DNS, i ajustar el resolutor mateix és el que més temps fa perdre aquí. Llegeix la llista d'interfícies abans de llegir la configuració del resolutor.
Tres direccions, tres conjunts de regles diferents
Una sola sessió toca regles en més d'una direcció, i un túnel afegeix una segona interfície a gairebé totes. Ordenar el trànsit primer per direcció i interfície fa mecànica la resta, perquè cada fila de sota necessita la seva pròpia regla al seu propi lloc. Els exemples fan servir tun0 i un pool de 10.8.0.0/24, així que substituïu els noms i els rangs pels de la sortida del propi client.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Dues files es confonen sovint perquè totes dues esmenten el túnel. Una regla per al resolutor admet el trànsit que el client envia al túnel, mentre que una regla per a SSH admet el trànsit que el servidor en rep; viuen en màquines diferents i fallen de manera independent. La fila que més sovint s'oblida és la segona, perquè el client no pot establir el túnel en absolut fins que el seu trànsit a l'adreça pública del servidor no estigui permès. Treballa de dalt a baix i cada fallada té una causa candidata.
Un resolutor empès necessita la seva pròpia regla
Que el túnel porti DNS depèn del que enviï el servidor. Un servidor que empeny una opció de resolutor instal·la una adreça privada a la configuració del client, i aquesta adreça només és encaminable a través del túnel. Si el servidor no empeny res, el client conserva el resolutor que ja tenia i les regles de sota no tenen res a admetre. Comprova l'estat empès i el resultat actual de la consulta abans d'escriure res:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedLa sortida d'estat anomena el resolutor en ús i l'enllaç al qual està lligat, i la consulta de ruta que hi ha darrere mostra quina interfície portaria una consulta a aquesta adreça. Quan el resolutor és en un altre enllaç, el problema és anterior al tallafoc i cap regla no ajudarà. Quan tots dos coincideixen en el túnel, calen dues regles, perquè UDP porta la majoria de consultes i TCP pren el relleu quan una resposta es trunca. Anota tots dos valors, perquè són els que les regles nomenaran:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Obre el camí exterior abans que l'interior
El client ha d'arribar a l'adreça pública del servidor abans que existeixi un túnel, així que la regla per a això se senta a l'enllaç físic i ha d'estar al seu lloc primer. Una política que admet el resolutor però oblida el servidor deixa el client incapaç de construir el túnel, i aquest símptoma normalment s'atribueix a un kill switch. Després admet els serveis que realment volies a través del túnel, una regla estreta alhora, en comptes d'obrir la interfície sencera. Les regles estretes són la raó per la qual la denegació pot quedar-se al seu lloc.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'L'ordre importa mentre proves, perquè la primera regla és la que permet que el túnel pugi. Afegeix-la, connecta't i confirma que el túnel és actiu abans d'afegir la regla del servei, perquè fer les dues alhora fa que una fallada no et digui res sobre quina meitat està malament. Substitueix l'adreça de documentació de dalt pel punt de connexió per al qual el client està configurat.
Acaba la part del client desconnectant a propòsit. La denegació encara hauria de rebutjar el trànsit que has exclòs deliberadament, perquè un resolutor que respon mentre el túnel és actiu només cobreix la meitat d'una política que denega en cas de dubte.
Un client que es connecta encara no està admès
El servidor té la seva pròpia direcció a considerar, i un client que completa l'encaixada de mans encara no pot arribar a res que s'executi al servidor fins que el servidor l'admeti. La regla del listener públic només permet que el túnel existeixi; no deixa entrar el trànsit del túnel. Al servidor això són dues regles més una comprovació que el servei realment escolta:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'El pool de la regla ha de ser igual al rang que assigna el servidor, i el número del túnel ha de coincidir amb el que el servidor ha creat, perquè una regla per a una interfície diferent és indistingible de cap regla. limit és deliberat per a un port administratiu, perquè limita les connexions repetides en lloc d'admetre-les sense límit. La comprovació del listener separa un port tancat d'un paquet descartat, que des del client semblen idèntics. Les regles numerades tampoc no són tota la imatge: les regles before d'UFW i qualsevol línia nftables escrita a mà coincideixen abans i encara poden rebutjar un paquet que la llista sembla permetre.