Uma VPN que se liga mas não alcança nada é geralmente descrita como um problema de firewall, e a solução a que as pessoas recorrem é colocar a interface do túnel numa zona de confiança. Isso funciona no sentido em que o tráfego começa a fluir, mas também admite muito mais do que o serviço pretendido. As duas políticas envolvidas são diferentes: uma admite o transporte externo para um socket à escuta, e a outra autoriza o tráfego desencriptado a alcançar um recurso específico. Tratá-las como uma única definição é o que transforma uma permissão estreita numa permissão ampla. As duas são decididas em locais diferentes, e é por isso que o erro é tão fácil.

Duas políticas, um túnel

A política externa responde a uma pergunta simples: pode um pacote desta origem alcançar o UDP 1194 neste host? A política interna responde a outra: pode o cliente autenticado atrás desse túnel alcançar este destino, com este protocolo, nesta porta? A primeira é sobre um socket, a segunda sobre um caminho, e o firewalld modela-as com objetos diferentes porque são decididas em pontos diferentes. Uma é uma propriedade de um socket neste host, a outra de um caminho através dele.

A consequência prática é que um túnel a funcionar nada diz sobre a segunda política, e uma segunda política correta não torna a primeira desnecessária.

Admita o verdadeiro listener externo

Comece por inspecionar o que já está atribuído em vez de presumir. Leia as zonas ativas, liste a zona que realmente transporta a entrada e verifique a definição do serviço instalado, porque o nome de um serviço descreve um conjunto de portas e nada diz sobre se o listener deste servidor lhe corresponde.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Se o listener for realmente o UDP 1194 nessa zona, abra especificamente essa porta e esse transporte, e depois torne a mesma regra específica persistente depois de a testar. Verifique também as atribuições baseadas na origem, porque uma zona ligada a um intervalo de origens pode capturar o tráfego antes de a zona da interface o ver.

Autorize o destino desencriptado separadamente

Uma ligação a um serviço que corre no próprio servidor VPN é política de entrada local. Uma ligação encaminhada para outro host na LAN precisa de política de encaminhamento, encaminhamento ativado no kernel e uma rota de resposta — três requisitos separados que as pessoas costumam juntar num só. Os objetos de política modernos do firewalld descrevem o tráfego direcionado entre uma zona de entrada e uma zona de saída, e é esse o local correto para expressar que origens VPN podem alcançar que serviços privados.

Defina explicitamente as origens permitidas e deixe tudo o resto cair numa recusa. Uma permissão para o serviço externo não é essa política, por muito que o pareça a disposição das zonas.

Porque confiar na interface é o atalho errado

Colocar a interface do túnel numa zona cujo destino aceita tudo admite todo o tráfego desencriptado para cada serviço que o host expõe, incluindo os que não reviu. Reapontar a zona de confiança para ser restritiva numa máquina em funcionamento é pior, porque outras interfaces e intervalos de origem podem já depender do seu significado e mudarão de comportamento quando a editar. Se precisa de uma política estreita, crie uma; não reutilize uma zona partilhada.

Mantenha também estável a atribuição de zona do túnel através do componente que detém essa configuração. Perder a atribuição ao reiniciar produz uma falha que parece um problema de regra de firewall e na realidade é um problema de persistência.

Verifique três coisas, incluindo uma recusa

Teste a ligação externa a partir de fora, teste um serviço interno autorizado a partir de um cliente ligado e teste um serviço que deve permanecer inalcançável. O terceiro teste é o que distingue uma política de um efeito secundário, e é o que as pessoas saltam porque tudo parece funcionar. Se o serviço recusado responder, admitiu uma zona em vez de um serviço.

Registe a zona, a porta, o transporte e o objeto de política nas notas do servidor. Caso contrário, a próxima alteração neste host começará a partir da mesma suposição.

Artigos relacionados