UFW descarta o servidor DNS da VPN en canto o túnel está activo
A política de denegación por defecto de UFW tamén cobre a interface do túnel. Ordena o tráfico por dirección, admite o resolutor empurrado en tun0 e despois abre o camiño exterior.
Os nomes deixan de resolverse no momento en que a VPN se conecta, mentres que un ping a un enderezo público segue respondendo e o estado da devasa non mostra nada que pareza incorrecto. Non cambiou nada na política; o que cambiou é que apareceu unha interface nova, e a denegación por defecto cóbrea desde o primeiro paquete. UFW decide por dirección e interface, así que unha regra escrita para a ligazón sen fíos non di nada sobre o tráfico que sae do túnel. A reparación é unha manchea de regras estreitas aplicadas nunha orde concreta.
O síntoma só aparece cando o túnel está activo
Unha política de denegación por defecto fai exactamente o que se lle dixo: todo o que non ten unha regra coincidente rexéitase, en cada interface que existe. O túnel non existía cando se escribiron as regras, así que ningunha delas pode cubrilo, e a denegación que sempre estaba alí agora aplícase á resolución de nomes. O tráfico directo a un enderezo literal aínda pode funcionar cando o cobre un permiso máis amplo, e por iso un ping a un resolutor público ten éxito mentres que a consulta dun nome falla. O oco é unha regra para unha interface que a política nunca viu.
Iso tamén explica por que o fallo se invirte limpiamente: quita o túnel e os nomes volven resolverse, porque a consulta volve a unha interface que si ten regras. Unha política que só falla mentres o túnel está activo non é un problema de DNS, e axustar o propio resolutor é o que máis tempo fai perder aquí. Le a lista de interfaces antes de ler a configuración do resolutor.
Tres direccións, tres conxuntos de regras distintos
Unha soa sesión toca regras en máis dunha dirección, e un túnel engade unha segunda interface a case todas elas. Ordenar o tráfico primeiro por dirección e interface fai mecánico o resto, porque cada fila de abaixo necesita a súa propia regra no seu propio sitio. Os exemplos usan tun0 e un grupo de 10.8.0.0/24, así que substitúe os nomes e os rangos polos da propia saída do cliente.
| 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 |
Dúas filas confúndense a miúdo porque ambas mencionan o túnel. Unha regra para o resolutor admite o tráfico que o cliente envía ao túnel, mentres que unha regra para SSH admite o tráfico que o servidor recibe del; viven en máquinas distintas e fallan de forma independente. A fila que máis a miúdo se esquece é a segunda, porque o cliente non pode establecer o túnel en absoluto ata que se permite o seu tráfico ao enderezo público do servidor. Traballa de arriba abaixo e cada fallo ten unha única causa candidata.
Un resolutor empurrado necesita a súa propia regra
Que o túnel leve DNS depende do que envíe o servidor. Un servidor que empurra unha opción de resolutor instala un enderezo privado na configuración do cliente, e ese enderezo só é encamiñable a través do túnel. Se o servidor non empurra nada, o cliente conserva o resolutor que xa tiña e as regras de abaixo non teñen nada que admitir. Comproba o estado empurrado e o resultado actual da consulta antes de escribir nada:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedA saída de estado nomea o resolutor en uso e a ligazón á que está ligado, e a procura de ruta que hai detrás mostra que interface levaría unha consulta a ese enderezo. Cando o resolutor está noutra ligazón, o problema é anterior á devasa e ningunha regra axudará. Cando ambos coinciden no túnel, fan falta dúas regras, porque UDP leva a maioría das consultas e TCP toma o relevo cando unha resposta se trunca. Anota ambos os valores, porque son os que as regras nomearán:
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'Abre o camiño exterior antes que o interior
O cliente ten que alcanzar o enderezo público do servidor antes de que exista un túnel, así que a regra para iso senta na ligazón física e debe estar no seu sitio primeiro. Unha política que admite o resolutor pero esquece o servidor deixa o cliente incapaz de construír o túnel, e ese síntoma adoita achacarse a un kill switch. Despois admite os servizos que de verdade querías a través do túnel, unha regra estreita cada vez, en lugar de abrir a interface enteira. As regras estreitas son a razón pola que a denegación pode quedar no seu sitio.
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'A orde importa mentres probas, porque a primeira regra é a que permite que o túnel suba. Engádea, conéctate e confirma que o túnel está activo antes de engadir a regra do servizo, porque facer ambas as cousas á vez fai que un fallo non che diga nada sobre que metade está mal. Substitúe o enderezo de documentación de arriba polo punto de conexión para o que está configurado o cliente.
Remata o lado do cliente desconectando a propósito. A denegación debería seguir rexeitando o tráfico que excluíches a propósito, porque un resolutor que responde mentres o túnel está activo cobre só a metade dunha política que denega en caso de dúbida.
Un cliente que se conecta aínda non está admitido
O servidor ten a súa propia dirección que considerar, e un cliente que completa o aperto de mans aínda non alcanza nada que se execute no servidor ata que o servidor o admita. A regra do listener público só permite que o túnel exista; non deixa entrar o tráfico do túnel. No servidor iso son dúas regras máis unha comprobación de que o servizo escoita de verdade:
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'O grupo da regra debe ser igual ao rango que asigna o servidor, e o número do túnel debe coincidir co que o servidor creou, porque unha regra para outra interface é indistinguible de ningunha regra. limit é deliberado para un porto administrativo, porque limita as conexións repetidas en lugar de admitilas sen límite. A comprobación do listener separa un porto pechado dun paquete descartado, que desde o cliente parecen idénticos. As regras numeradas tampouco son toda a imaxe: as regras before de UFW e calquera liña de nftables escrita a man coinciden antes e aínda poden rexeitar un paquete que a lista parece permitir.