Publikigi LAN-servon sur la propra adreso de la VPN-pordego

Prezenti LAN-aparaton sur unu el la propraj tunelaj adresoj de la pordego postulas unu linion da NAT. La konekto ankoraŭ malsukcesas, ĉar la respondanta aparato tute ne scias, ke la adreso de la kliento estas atingebla tra tiu pordego. Sekvu la paketon de la kliento enen, poste sekvu la respondon reen eksteren, kaj la mankanta duono fariĝos evidenta.

Komencu per la vidpunkto de la kliento

La kliento en ĉi tiu ekzemplo troviĝas en la VPN-pool 10.62.0.0/24 kaj konektiĝas al 10.62.0.1 sur pordo 8080. Tiu adreso apartenas al la pordego mem, do la paketo alvenas al la kerno de la pordego, ne al alia samtavolano. Malantaŭ la pordego la LAN estas 172.21.4.0/24. La pordego tenas 172.21.4.10, kaj la aparato, kiu efektive servas HTTP, estas 172.21.4.40.

Adreso apartenanta al alia VPN-samtavolano ne estas interŝanĝebla kun la serva adreso de la pordego. Se la kliento konektiĝas al adreso de samtavolano, neniu pordega regulo entute partoprenas, kaj ĉi tiu tuta trairo estas la malĝusta.

Limigu la destinan tradukon intence

La mallarĝa versio prezentas unu pordon kaj reverkas nur la celon. La paketo konservas sian protokolon kaj sian fonton, kaj tio faras la reston de la trairo interesa.

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

Regulo sen kriterioj pri protokolo kaj pordo estas la larĝa versio: ĝi konservas ajnan pordon, kiun la kliento elektis, ŝanĝante nur la adreson. Tio estas legitima, kiam temas pri prezento de la tuta gastiganto, kaj malĝusta, kiam unu servo estis la intenco. Legu la regulon returne kaj konfirmu la nomon de la interfaco. DNAT-regulo sur la malĝusta interfaco kongruas kun nenio, kio produktas la saman tempolimon kiel mankanta regulo kaj malŝparas horon da rigardado al la aparato.

Lasu la plusendan limon konsenti

Traduko ŝanĝas la kaplinion, ĝi ne donas permeson. Kun defaŭlta forĵeta politiko la plusendita fluo bezonas propran akcepton, kaj la revena direkto bezonas la regulon pri establita konekto, kiun via politiko verŝajne jam havas.

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

Senkondiĉa akcepto por ĉiu DNAT-fluo estas pli larĝa ol ĉi tiu dezajno kaj ankaŭ permesos mapigojn, kiujn iu alia aldonos poste. Nomu la celon kaj la pordon, kaj lasu la reston resti fermita. Se la nombriloj sur la plusenda regulo restas nulo dum la NAT-nombriloj kreskas, la paketo estas forĵetata antaŭ via regulo. Legu la ordon de la ĉenoj anstataŭ aldoni duan kopion.

La aparato devas respondi iel

Post la traduko la aparato vidas fonton en 10.62.0.0/24. Ĝia respondo iras al ĝia defaŭlta pordego, kiu estas la LAN-enkursigilo, ne la VPN-pordego, se io ne diras al ĝi alie. Du aranĝoj tion riparas, kaj ili ne estas ekvivalentaj. Enkursigo sur la aparato aŭ sur la LAN-enkursigilo sendas 10.62.0.0/24 al 172.21.4.10 kaj konservas la fonton de la kliento. Limigita fonta traduko anstataŭe kaŝas la klienton malantaŭ la LAN-adreso de la pordego.

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

Elektu laŭ tio, kion la servo bezonas. Politiko por kliento kaj signifoplenaj protokoloj volas la enkursigitan formon; aparato, al kiu oni ne povas doni enkursigon, aŭ servo, kiu simple devas vidi LAN-adreson, montras al la tradukita formo. Ne prenu tutmondan masquerade-regulon por igi unu respondon funkcii. Ĝi kaŝas ĉiun klienton for de ĉiu celo kaj silente rompas la politikojn, kiuj dependas de fontaj adresoj.

Ne testu de la pordego mem

Petos generita sur la pordego al 10.62.0.1 eliras tra la OUTPUT-ĉeno, ne tra la envena PREROUTING. Ĝia malsukceso aŭ sukceso diras nenion pri la klient-frunta regulo, kaj tiel homoj konkludas, ke funkcianta regulo estas rompita.

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

Rulu veran klient-peton kaj legu ambaŭ. La conntrack-enskribo montras la aplikitan tradukon, kaj la kaptaĵoj montras, ĉu la peto transiris al la LAN kaj ĉu respondo revenis al la tunelo. Uzu freŝan konekton post ŝanĝo de reguloj, ĉar ekzistanta stato konservas sian pli frue mapigon kaj daŭre malsukcesos laŭ la malnova maniero. Poste konfirmu la tutan interparolon: la aparata adreso, la plusenda permeso kaj la responda enkursigo ĉiuj priskribas la saman fluon.