OpenVPN em túnel completo: acrescente uma saída de internet do lado do servidor

Um cliente autentica-se, recebe um endereço do pool e alcança os serviços no host VPN, mas todos os destinos públicos expiram. É assim que se parece um túnel sem saída, e assim permanece até que quatro coisas distintas sejam verdadeiras. O cliente tem de aceitar uma rota predefinida, o servidor tem de encaminhar, a firewall tem de permitir o trânsito e as respostas precisam de um caminho de volta ao pool. As quatro falhas partilham um único sintoma, por isso mude um item por tentativa e registe o resultado.

Empurre a rota predefinida e confirme o que o cliente instalou

A linha do lado do servidor é curta, e só afeta os clientes que aceitam opções empurradas. A forma def1 instala duas semi-rotas predefinidas em vez de eliminar a predefinida existente, o que mantém a ligação atual viva e ainda captura todos os destinos.

push "redirect-gateway def1"

Depois de reconectar, leia a tabela de rotas do cliente em vez de confiar no perfil. No Linux as duas entradas /1 aparecem ao lado da predefinida original, e o Windows mostra o mesmo par como 0.0.0.0/1 e 128.0.0.0/1. Um cliente que ignora as opções empurradas, ou um configurado para as recusar, mantém a sua antiga predefinida e nunca envia tráfego de internet para o túnel. Resolva essa questão antes de mudar qualquer coisa no servidor, porque nenhuma regra do lado do servidor consegue compensar.

O encaminhamento é uma definição do servidor, não do VPN

Leia o sinalizador de encaminhamento antes de mexer no encaminhamento de rotas. Um zero ali significa que o núcleo recebe o pacote do cliente e recusa passá-lo adiante, o que se parece exatamente com um bloqueio da firewall do outro extremo. Defina o valor através do diretório de configuração do sistema para que sobreviva a um reinício.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

De seguida, confirme que o próprio host tem uma rota funcional até à saída de internet. Um pedido a partir da shell do servidor prova que o caminho ascendente é utilizável e não diz absolutamente nada sobre encaminhar o pacote de um cliente, por isso trate-os como dois testes separados. Se o servidor não alcançar o destino, nenhuma quantidade de configuração de encaminhamento ajudará.

Permita exatamente o trânsito que pretende, e nada mais

Os pacotes encaminhados atravessam o caminho forward; o tráfego dirigido ao próprio host VPN atravessa input. São decisões distintas, e abrir o caminho input não permite o trânsito através da máquina. Confundi-los é a razão mais comum para uma firewall parecer permitir tudo enquanto os clientes continuam a expirar.

Uma política mínima aceita novas ligações do pool para a interface de saída e aceita respostas que pertencem a fluxos estabelecidos. Coloque-a no proprietário do conjunto de regras que a sua distribuição usa, em vez de acrescentar uma regra duplicada em cada arranque; as regras duplicadas acumulam-se e os contadores deixam de significar algo.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Mudar cada cadeia para aceitar faz o teste passar e retira a razão de existir da firewall. Mantenha o âmbito no pool e na interface de saída, e deixe em paz o encaminhamento não relacionado.

Dê às respostas um lugar para onde ir

Os endereços do pool são privados, por isso um servidor público não lhes pode entregar uma resposta diretamente. Ou o host VPN traduz o endereço de origem na saída, ou um dispositivo a montante mantém uma rota de volta ao pool.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Acrescente exatamente uma camada de tradução. Um segundo NAT mais acima esconde o primeiro e torna ambos os registos quase inúteis quando algo se estraga mais tarde. Se um router a montante já encaminha o pool de volta, acrescentar tradução no host é redundante, e o caminho de regresso passa então a depender da configuração desse router e não da sua.

As instâncias na nuvem acrescentam mais uma porta, porque algumas plataformas descartam pacotes cujo endereço de origem não é o da instância, a menos que essa verificação seja relaxada. Essa definição está fora do convidado e é fácil de esquecer quando uma máquina de teste local funciona.

Prove-o a partir do cliente, não da shell do servidor

Comece com um pedido IPv4 numérico, depois uma consulta de nome, depois a aplicação. Um ping prova o encaminhamento e a tradução;não prova nada sobre a resolução, porque as opções de DNS só produzem efeito quando a integração do cliente as instala.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Registe as alterações e o passo de anulação à medida que avança, para que a política de saída possa ser revertida numa única ação quando um teste falhar. Esta receita abrange apenas IPv4; faça o inventário de IPv6 em separado antes de afirmar que a implementação transporta todo o tráfego.