Publicar un servizo LAN no propio enderezo da pasarela VPN

Presentar un dispositivo LAN nunha das direccións de túnel propias da pasarela require unha soa liña de NAT. A conexión segue fallando, porque o dispositivo que responde non ten idea de que o enderezo do cliente é alcanzable a través desa pasarela. Percorra o paquete desde o cliente cara a dentro e despois percorra a resposta de volta cara a fóra, e a metade que falta vólvese obvia.

Comece pola perspectiva do cliente

O cliente deste exemplo está no grupo VPN 10.62.0.0/24 e conecta a 10.62.0.1 no porto 8080. Ese enderezo pertence á propia pasarela, así que o paquete chega ao núcleo da pasarela e non a outro par. Detrás da pasarela, a LAN é 172.21.4.0/24. A pasarela ten 172.21.4.10 e o dispositivo que realmente serve HTTP é 172.21.4.40.

Un enderezo que pertence a outro par de VPN non é intercambiable co enderezo de servizo da pasarela. Se o cliente se conecta ao enderezo dun par, non intervén ningunha regra da pasarela e todo este percorrido é o caso equivocado.

Limite a tradución de destino a propósito

A versión estreita presenta un porto e reescribe só o destino. O paquete conserva o seu protocolo e a súa orixe, e iso é o que fai interesante o resto do percorrido.

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

Unha regra sen criterios de protocolo e porto é a versión ampla: conserva o porto que o cliente escollese e só cambia o enderezo. Iso é lexítimo cando se pretende presentar todo o host e erróneo cando a intención era un só servizo. Volva ler a regra e confirme o nome da interface. Unha regra DNAT na interface equivocada non coincide con nada, o que produce o mesmo tempo de espera que unha regra ausente e desperdicia unha hora mirando o dispositivo.

Deixe que a fronteira de reenvío estea de acordo

A tradución cambia a cabeceira, pero non concede permiso. Cunha política de descarte predeterminada, o fluxo reenviado necesita a súa propia aceptación, e a dirección de volta necesita a regra de conexión establecida que a súa política probablemente xa ten.

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

Unha aceptación incondicional para cada fluxo DNAT é máis ampla que este deseño e tamén permitirá asignacións que alguén engada máis tarde. Nomee o destino e o porto, e deixe o resto pechado. Se os contadores da regra de reenvío quedan en cero mentres os contadores de NAT soben, o paquete descártase antes da súa regra. Lea a orde da cadea en lugar de engadir unha segunda copia.

O dispositivo ten que responder dalgunha forma

Despois da tradución o dispositivo ve unha orixe dentro de 10.62.0.0/24. A súa resposta vai á súa pasarela predeterminada, que é o encamiñador da LAN, non a pasarela VPN, a menos que algo lle diga o contrario. Dúas disposicións o arranxan e non son equivalentes. Unha ruta no dispositivo ou no encamiñador da LAN envía 10.62.0.0/24 a 172.21.4.10 conservando a orixe do cliente. Unha tradución de orixe limitada agocha o cliente detrás do enderezo LAN da pasarela.

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

Escolla segundo o que necesite o servizo. A política por cliente e os rexistros significativos queren a forma encamiñada; un dispositivo ao que non se lle pode dar unha ruta, ou un servizo que simplemente debe ver un enderezo LAN, apuntan á forma traducida. Non recorra a unha regra masquerade global para facer funcionar unha soa resposta. Agocha cada cliente de cada destino e rompe en silencio as políticas que dependen dos enderezos de orixe.

Non probe desde a propia pasarela

Unha petición xerada na pasarela cara a 10.62.0.1 sae pola cadea OUTPUT, non pola PREROUTING de entrada. O seu fallo ou éxito non di nada sobre a regra que mira ao cliente, e así é como a xente conclúe que unha regra que funciona está rota.

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

Executa unha petición real de cliente e le as dúas cousas. A entrada de conntrack mostra a tradución aplicada, e as capturas mostran se a petición cruzou cara á LAN e se volveu unha resposta cara ao túnel. Use unha conexión nova despois de cambiar regras, porque o estado existente conserva a súa asignación anterior e seguirá fallando á vella maneira. Despois confirme toda a conversa: o enderezo do dispositivo, o permiso de reenvío e a ruta de resposta describen o mesmo fluxo.