Ilathala ang serbisyo ng LAN sa sariling address ng VPN gateway

Ang pagpapakita ng device ng LAN sa isa sa sariling tunnel address ng gateway ay nangangailangan lamang ng isang linya ng NAT. Nabigo pa rin ang koneksyon, dahil ang device na sumasagot ay walang ideya na maabot ang address ng kliyente sa pamamagitan ng gateway na iyon. Subaybayan ang packet mula sa kliyente papasok, pagkatapos ay subaybayan ang tugon pabalik palabas, at magiging malinaw ang nawawalang kalahati.

Magsimula sa pananaw ng kliyente

Ang kliyente sa halimbawang ito ay nasa pool ng VPN 10.62.0.0/24 at kumokonekta sa 10.62.0.1 sa port 8080. Pag-aari ng gateway mismo ang address na iyon, kaya dumarating ang packet sa kernel ng gateway at hindi sa ibang peer. Sa likod ng gateway, ang LAN ay 172.21.4.0/24. Hawak ng gateway ang 172.21.4.10 at ang device na talagang naghahain ng HTTP ay 172.21.4.40.

Ang address na pag-aari ng ibang peer ng VPN ay hindi mapagpapalit sa address ng serbisyo ng gateway. Kung kumokonekta ang kliyente sa address ng isang peer, walang anumang tuntunin ng gateway ang kasangkot, at ang buong paglalakbay na ito ay ang maling kaso.

Limitahan ang pagsasalin ng destinasyon nang sadya

Ang makitid na bersyon ay nagpapakita ng isang port at muling isinusulat lamang ang destinasyon. Pinapanatili ng packet ang protocol at pinagmulan nito, at iyon ang dahilan kung bakit kawili-wili ang natitirang paglalakbay.

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

Ang tuntuning walang pamantayan ng protocol at port ay ang malawak na bersyon: pinapanatili nito ang anumang port na pinili ng kliyente at binabago lamang ang address. Ito ay lehitimo kapag buong host ang nais ipakita, at mali kapag isang serbisyo lamang ang intensyon. Basahin muli ang tuntunin at kumpirmahin ang pangalan ng interface. Ang tuntunin ng DNAT sa maling interface ay hindi tumutugma sa anuman, na nagbubunga ng parehong timeout tulad ng nawawalang tuntunin at nag-aaksaya ng isang oras sa pagtingin sa device.

Hayaan ang hangganan ng pagpapasa na sumang-ayon

Binabago ng pagsasalin ang header, hindi ito nagbibigay ng pahintulot. Sa default na patakaran ng pagtatapon, ang naipasang daloy ay nangangailangan ng sarili nitong pagtanggap, at ang direksyon ng pagbabalik ay nangangailangan ng tuntunin ng matatag na koneksyon na malamang ay nasa patakaran mo na.

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

Ang walang kondisyong pagtanggap para sa bawat daloy ng DNAT ay mas malawak kaysa sa disenyong ito at magpapahintulot din sa mga mapping na idadagdag ng iba mamaya. Pangalanan ang destinasyon at ang port, at iwanang sarado ang iba pa. Kung ang mga counter sa tuntunin ng pagpapasa ay nananatiling zero habang tumataas ang mga counter ng NAT, ang packet ay itinatapon bago ang tuntunin mo. Basahin ang pagkakasunod-sunod ng chain sa halip na magdagdag ng pangalawang kopya.

Kailangang tumugon ang device sa anumang paraan

Pagkatapos ng pagsasalin nakikita ng device ang pinagmulan sa loob ng 10.62.0.0/24. Ang tugon nito ay patungo sa default na gateway nito, na siyang router ng LAN at hindi ang VPN gateway, maliban kung may magsabi ng iba. Dalawang kaayusan ang nagwawasto nito at hindi sila pantay. Ang ruta sa device o sa router ng LAN ay nagpapadala ng 10.62.0.0/24 sa 172.21.4.10 habang pinapanatili ang pinagmulan ng kliyente. Ang limitadong pagsasalin ng pinagmulan ay nagtatago ng kliyente sa likod ng LAN address ng 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

Pumili ayon sa kailangan ng serbisyo. Ang patakaran kada kliyente at makabuluhang log ay nais ang rutang anyo; ang device na hindi mabibigyan ng ruta, o serbisyong dapat talagang makakita ng LAN address, ay tumuturo sa isinaling anyo. Huwag abutin ang isang pandaigdigang tuntunin ng masquerade para gumana ang isang tugon. Itinatago nito ang bawat kliyente sa bawat destinasyon at tahimik na sinisira ang mga patakarang umaasa sa mga address ng pinagmulan.

Huwag subukan mula sa gateway mismo

Ang kahilingang nabuo sa gateway patungo sa 10.62.0.1 ay lumalabas sa pamamagitan ng chain ng OUTPUT, hindi sa papasok na PREROUTING. Ang pagkabigo o tagumpay nito ay walang sinasabi tungkol sa tuntuning nakaharap sa kliyente, at ganoon natuklasan ng mga tao na sira ang isang tuntuning gumagana.

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

Magpatakbo ng tunay na kahilingan ng kliyente at basahin ang dalawa. Ipinapakita ng entry ng conntrack ang ginamit na pagsasalin, at ipinapakita ng mga capture kung tumawid ang kahilingan patungo sa LAN at kung may tugon na bumalik patungo sa tunnel. Gumamit ng bagong koneksyon pagkatapos baguhin ang mga tuntunin, dahil pinapanatili ng umiiral na estado ang dating mapping nito at patuloy itong mabibigo sa dating paraan. Pagkatapos ay kumpirmahin ang buong usapan: ang address ng device, ang pahintulot sa pagpapasa at ang ruta ng tugon ay inilalarawan ang parehong daloy.