UFW descarta o servidor DNS da VPN assim que o túnel sobe
A política de negação por omissão do UFW também cobre a interface do túnel. Ordene o tráfego por direção, admita o resolver empurrado em tun0 e depois abra o caminho exterior.
Os nomes deixam de resolver no momento em que a VPN se conecta, enquanto um ping para um endereço público ainda responde e o estado da firewall não mostra nada que pareça errado. Nada mudou na política; o que mudou é que surgiu uma nova interface, e a negação por omissão cobre-a desde o primeiro pacote. UFW decide por direção e interface, portanto uma regra escrita para a ligação sem fios não diz nada sobre o tráfego que sai do túnel. A reparação é um punhado de regras estreitas aplicadas numa ordem concreta.
O sintoma só aparece depois de o túnel estar ativo
Uma política de negação por omissão faz exatamente o que lhe foi dito: tudo o que não tem uma regra correspondente é recusado, em cada interface que existe. O túnel não existia quando as regras foram escritas, por isso nenhuma delas o pode apanhar, e a negação que sempre esteve lá aplica-se agora à resolução de nomes. O tráfego direto para um endereço literal ainda pode funcionar quando o cobre uma permissão mais ampla, e é por isso que um ping para um resolver público tem sucesso enquanto a procura de um nome falha. A lacuna é uma regra para uma interface que a política nunca viu.
Isso também explica porque a falha se inverte de forma limpa: retire o túnel e os nomes voltam a resolver, porque a consulta regressa a uma interface que tem regras. Uma política que só falha enquanto o túnel está ativo não é um problema de DNS, e ajustar o próprio resolver é o que aqui faz perder mais tempo. Leia a lista de interfaces antes de ler a configuração do resolver.
Três direções, três conjuntos de regras diferentes
Uma única sessão toca regras em mais do que uma direção, e um túnel acrescenta uma segunda interface a quase todas. Ordenar o tráfego primeiro por direção e interface torna o resto mecânico, porque cada linha abaixo precisa da sua própria regra no seu próprio lugar. Os exemplos usam tun0 e um pool de 10.8.0.0/24, por isso substitua os nomes e os intervalos pelos da própria 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 |
Duas linhas são frequentemente confundidas porque ambas mencionam o túnel. Uma regra para o resolver admite o tráfego que o cliente envia para o túnel, enquanto uma regra para SSH admite o tráfego que o servidor recebe dele; vivem em máquinas diferentes e falham de forma independente. A linha que mais frequentemente se esquece é a segunda, porque o cliente não pode sequer estabelecer o túnel até o seu tráfego para o endereço público do servidor ser permitido. Trabalhe de cima para baixo e cada falha tem uma única causa provável.
Um resolver empurrado precisa da sua própria regra
Se o túnel transporta DNS depende do que o servidor envia. Um servidor que empurra uma opção de resolver instala um endereço privado na configuração do cliente, e esse endereço só é encaminhável através do túnel. Se o servidor não empurrar nada, o cliente mantém o resolver que já tinha e as regras abaixo não têm nada que admitir. Verifique o estado empurrado e o resultado atual da consulta antes de escrever seja o que for:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedA saída de estado nomeia o resolver em uso e a ligação a que está vinculado, e a procura de rota por trás mostra que interface transportaria uma consulta para esse endereço. Quando o resolver está noutra ligação, o problema é anterior à firewall e nenhuma regra ajudará. Quando ambos concordam quanto ao túnel, são necessárias duas regras, porque o UDP transporta a maioria das consultas e o TCP assume quando uma resposta é truncada. Registe ambos os valores, porque são esses que as regras irão nomear:
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'Abra o caminho exterior antes do interior
O cliente tem de alcançar o endereço público do servidor antes de existir um túnel, por isso a regra para tal está na ligação física e tem de estar no lugar primeiro. Uma política que admite o resolver mas esquece o servidor deixa o cliente totalmente incapaz de construir o túnel, e esse sintoma costuma ser atribuído a um kill switch. Depois admita os serviços que realmente queria através do túnel, uma regra estreita de cada vez, em vez de abrir a interface por completo. As regras estreitas são a razão pela qual a negação pode permanecer no lugar.
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 ordem importa durante os testes, porque a primeira regra é o que permite que o túnel suba. Adicione-a, ligue-se e confirme que o túnel está ativo antes de adicionar a regra do serviço, porque fazer as duas coisas ao mesmo tempo significa que uma falha não lhe diz nada sobre qual metade está errada. Substitua o endereço de documentação acima pelo ponto final para o qual o cliente está configurado.
Termine o lado do cliente desligando de propósito. A negação deveria continuar a recusar o tráfego que excluiu deliberadamente, porque um resolver que responde enquanto o túnel está ativo cobre apenas metade de uma política que nega em caso de dúvida.
Um cliente que se liga ainda não está admitido
O servidor tem a sua própria direção a considerar, e um cliente que completa o handshake ainda não alcança nada que corra no servidor até o servidor o admitir. A regra do listener público só permite que o túnel exista; não deixa entrar o tráfego do túnel. No servidor isso são duas regras mais uma verificação de que o serviço está realmente à escuta:
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 pool na regra tem de ser igual ao intervalo que o servidor atribui, e o número do túnel tem de corresponder ao que o servidor criou, porque uma regra para outra interface é indistinguível de nenhuma regra. limit é deliberado para uma porta administrativa, porque limita as ligações repetidas em vez de as admitir sem limite. A verificação do listener separa uma porta fechada de um pacote descartado, que do lado do cliente parecem idênticos. As regras numeradas também não são toda a imagem: as regras before do UFW e qualquer linha nftables escrita à mão correspondem mais cedo e ainda podem recusar um pacote que a lista parece permitir.