Publique uma porta de cliente VPN atrás de CGNAT: lista de verificação

Coloque um serviço num portátil atrás de NAT de nível de operadora, aponte esse portátil para um VPS através de uma VPN, e ninguém de fora consegue alcançá-lo. Adiciona uma regra NAT de destino no VPS e obtém algo pior do que silêncio: as ligações abrem e depois bloqueiam. A resposta não falta, está a sair pela rota predefinida do próprio cliente, o que significa que o servidor nunca a vê. Faça estas cinco verificações por ordem e pare na primeira que não se verificar.

Confirme que o servidor vai encaminhar sequer

Assinale esta caixa antes de escrever uma única tradução. O analisador de regras aceita uma regra DNAT para um pacote que o kernel recusa encaminhar e depois a via de encaminhamento descarta-o, o que produz um tempo limite que parece um problema de firewall.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Defini-lo num kernel em execução não é o mesmo que defini-lo entre reinícios. Escreva net.ipv4.ip_forward=1 num ficheiro em /etc/sysctl.d/, execute sysctl --system e depois leia o valor de volta em vez de confiar que o ficheiro foi apanhado. Um contentor que gere o seu próprio espaço de nomes de rede precisa do mesmo valor dentro desse espaço, não apenas no anfitrião.

Se a leitura continuar a ser zero, pare aqui. Nada abaixo vai funcionar.

Fixe o endereço do túnel antes de qualquer regra se referir a ele

O conjunto distribui endereços pela ordem das ligações, pelo que uma regra escrita para o aluguer de hoje pode apontar em silêncio para outro cliente na próxima semana. Ligue o endereço à identidade do certificado e não à ordem de chegada.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Esse par é a extremidade do cliente e a extremidade do par de um túnel ponto a ponto, com o servidor ligado ao nome comum do certificado. Numa topologia de sub-rede o segundo valor é lido como máscara de rede, por isso escreva a forma que corresponde à topologia em uso. Depois reconecte o cliente e leia o endereço no próprio cliente, porque a visão do servidor sobre o conjunto não é prova do que o cliente configurou.

Se o endereço mudar após uma reconexão, pare. Uma regra NAT que segue um alvo móvel falhará de forma intermitente e não lhe ensinará nada.

Traduza nos dois sentidos

A tradução de destino envia o pacote de entrada ao cliente. A tradução de origem é o que faz o cliente responder ao servidor e não ao remetente original, e é a regra que as pessoas omitem.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

Sem a segunda regra o cliente responde pela sua ligação ascendente ISP, pelo que o par remoto vê um endereço de origem com quem nunca falou, enquanto o servidor não guarda qualquer entrada de rastreio para a resposta. O observador externo vê um aperto de mão que se completa a meio, e esse é exatamente o sintoma que manda as pessoas à procura de um erro de firewall que não existe.

Leia as duas regras de volta com iptables -t nat -S e confirme que o nome da interface é o que transporta o endereço público. Num anfitrião que já filtra com nftables, escreva a tradução numa cadeia NAT de nftables da família de endereços correspondente em vez de misturar ferramentas.

Deixe passar a tabela de filtros

As tabelas NAT reescrevem cabeçalhos; não concedem permissão. Com uma política DROP predefinida o fluxo encaminhado precisa da sua própria aceitação, além da direção de retorno que a maioria das políticas já cobre com uma regra established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Verifique a política da cadeia FORWARD antes de acrescentar seja o que for, porque a ordem de um DROP precoce decide se a sua regra chega a ser consultada. Num anfitrião cuja filtragem vive em nftables, acrescente a regra equivalente ao gancho forward da tabela inet e confirme que a cadeia base vê realmente o tráfego encaminhado e não apenas a entrada local. Se um contador de pacotes da nova regra ficar em zero enquanto os contadores NAT sobem, o pacote está a ser descartado antes da sua regra. Esse é o sinal para ler a ordem das cadeias, não para acrescentar uma segunda cópia da mesma regra.

Prove-o a partir de uma rede externa

Teste a partir de uma rede não relacionada. Uma sonda de outra máquina na mesma LAN pode passar pelo suporte de NAT em gancho e nunca exercitar o caminho que um cliente remoto usa, pelo que um resultado verde ali prova a coisa errada.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Execute a captura no servidor e no cliente ao mesmo tempo. A captura no servidor mostra se o pacote traduzido sai em direção ao túnel; a captura no cliente mostra se o pedido chega e para onde a resposta está endereçada. Uma entrada de tradução em conntrack -L prova que a regra correspondeu, e a sua ausência prova que o pacote nunca chegou à cadeia NAT.

Os scanners de portas são prova fraca. Reportam a porta como fechada até a aplicação estar ligada e à escuta, por isso use uma ligação real ao serviço real. Quando finalmente funcionar, mantenha a exposição nessa única porta: encaminhar SSH ou um painel de administração porque a primeira regra parecia desconfortável é uma decisão muito maior do que publicar um serviço.