Publicar um serviço LAN no próprio endereço do gateway VPN

Apresentar um dispositivo LAN num dos próprios endereços de túnel do gateway requer apenas uma linha de NAT. A ligação continua a falhar, porque o dispositivo que responde não faz ideia de que o endereço do cliente é alcançável através desse gateway. Percorra o pacote do cliente para dentro, depois percorra a resposta de volta para fora, e a metade em falta torna-se óbvia.

Comece pela perspetiva do cliente

O cliente deste exemplo está no conjunto VPN 10.62.0.0/24 e liga-se a 10.62.0.1 na porta 8080. Esse endereço pertence ao próprio gateway, por isso o pacote chega ao kernel do gateway e não a outro par. Atrás do gateway, a LAN é 172.21.4.0/24. O gateway tem 172.21.4.10 e o dispositivo que realmente serve HTTP é 172.21.4.40.

Um endereço que pertence a outro par de VPN não é intercambiável com o endereço de serviço do gateway. Se o cliente se liga ao endereço de um par, não está envolvida nenhuma regra do gateway e todo este percurso é o caso errado.

Delimite a tradução de destino de propósito

A versão estreita apresenta uma porta e reescreve apenas o destino. O pacote mantém o protocolo e a origem, e é isso que torna interessante o resto do percurso.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Uma regra sem critérios de protocolo e porta é a versão ampla: mantém a porta que o cliente escolheu e altera apenas o endereço. Isso é legítimo quando se pretende apresentar o anfitrião completo e errado quando a intenção era um único serviço. Leia a regra de volta e confirme o nome da interface. Uma regra DNAT na interface errada não corresponde a nada, o que produz o mesmo tempo limite que uma regra ausente e desperdiça uma hora a olhar para o dispositivo.

Deixe a fronteira de reencaminhamento concordar

A tradução altera o cabeçalho, mas não concede permissão. Com uma política de descarte predefinida, o fluxo reencaminhado precisa da sua própria aceitação, e a direção de retorno precisa da regra de ligação estabelecida que a sua política provavelmente já tem.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Uma aceitação incondicional para cada fluxo DNAT é mais ampla do que este desenho e também permitirá mapeamentos que alguém acrescente mais tarde. Nomeie o destino e a porta, e deixe o resto fechado. Se os contadores da regra de reencaminhamento ficarem em zero enquanto os contadores de NAT sobem, o pacote está a ser descartado antes da sua regra. Leia a ordem das cadeias em vez de acrescentar uma segunda cópia.

O dispositivo tem de responder de alguma forma

Depois da tradução, o dispositivo vê uma origem em 10.62.0.0/24. A resposta vai para o seu gateway predefinido, que é o router da LAN e não o gateway VPN, a menos que algo lhe diga o contrário. Duas disposições corrigem isso e não são equivalentes. Uma rota no dispositivo ou no router da LAN envia 10.62.0.0/24 para 172.21.4.10 preservando a origem do cliente. Uma tradução de origem limitada esconde o cliente atrás do endereço LAN do gateway.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Escolha conforme o que o serviço precisa. A política por cliente e os registos significativos querem a forma encaminhada; um dispositivo ao qual não se pode dar uma rota, ou um serviço que simplesmente tem de ver um endereço LAN, apontam para a forma traduzida. Não recorra a uma regra masquerade global para pôr uma única resposta a funcionar. Esconde cada cliente de cada destino e quebra silenciosamente as políticas que dependem dos endereços de origem.

Não teste a partir do próprio gateway

Um pedido gerado no gateway para 10.62.0.1 sai pela cadeia OUTPUT, não pela PREROUTING de entrada. A sua falha ou sucesso não diz nada sobre a regra virada para o cliente, e é assim que as pessoas concluem que uma regra a funcionar está avariada.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Execute um pedido real de cliente e leia os dois. A entrada de conntrack mostra a tradução aplicada, e as capturas mostram se o pedido atravessou para a LAN e se voltou uma resposta na direção do túnel. Use uma ligação nova depois de alterar regras, porque o estado existente mantém o mapeamento anterior e continuará a falhar à maneira antiga. Depois confirme toda a conversa: o endereço do dispositivo, a permissão de reencaminhamento e a rota da resposta descrevem o mesmo fluxo.