Masquerade o policy routing: trapiko ng LAN sa pamamagitan ng VPN gateway

Ang paglalagay ng buong LAN sa likod ng VPN tunnel ay ang madaling bahagi; ang pagpapasya kung paano nakikita ng malayong panig ang mga kliyenteng iyon ay hindi. Isinusulat muli ng masquerade ang bawat pinagmulan ng LAN patungo sa address ng tunnel ng gateway, kaya isang peer lang ang sinasagot ng malayong dulo. Pinapanatili ng policy routing ang orihinal na mga address at hinihiling na malaman ng malayong panig kung paano maabot ang mga ito. Wala sa dalawa ang default; ang pagpili ay nagmumula sa kung kanino ang malayong panig at kung mahalaga ang pagkakakilanlan bawat aparato.

Nangangako ng magkaibang bagay ang dalawang disenyo

Binabawasan ng masquerade ang LAN sa isang nakikitang host: ang gateway. Sinasagot ng malayong network ang nag-iisang address na iyon, at isinasalin ng gateway ang mga sagot pabalik sa kliyenteng nagpasimula ng daloy. Hindi kailangan ng ruta patungo sa iyong mga pribadong prefix sa malayong panig, kaya nananatili ang disenyong ito sa provider na tumatangging magdala sa mga ito. Nagiging pinagmulan din ng bawat koneksyon ang gateway, kaya hindi maihihiwalay ng malayong panig ang dalawang kliyente.

Pinapanatili ng policy routing ang address ng bawat kliyente nang buo. Nakikita ng malayong network ang tunay na pinagmulan at maaari nitong i-log, ilapat ang patakaran bawat host, o ipadala ang sagot nang direkta sa address na iyon. Ang visibility na iyon ang buong punto, at may kasamang obligasyon: kailangang may ruta ang malayong panig para sa LAN prefix na bumabalik sa tunnel. Planoin ang rutang iyon bago paganahin ang patakaran, dahil aakyat pa rin ang tunnel at ang mga sagot lang ang mawawala.

Kasing-iba ng mga pangako ang mga paraan ng pagkasira. Ang nawawalang masquerade rule ay gumagawa ng mga packet na lumalabas na may pribadong pinagmulan at hindi na bumabalik. Ang nawawalang ruta ng pagbabalik ay nagbibigay ng parehong sintomas sa policy routing, ngunit ang pagwawasto ay para sa malayong router, hindi sa gateway.

Masquerade: isang peer sa malayong panig

May pagkakasunod-sunod ang landas ng masquerade na mahalaga. Kailangang nakabukas ang forwarding bago maging kapaki-pakinabang ang anumang NAT rule, kailangang payagan ng filter table ang pagdaan sa dalawang direksyon, at saka lang nalalapat ang pagsasalin sa interface ng tunnel.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Kailangan pa rin ng mga kliyente ng landas patungo sa gateway. Maaaring ang gateway ang kanilang default router, o may dala silang partikular na ruta para sa malayong prefix; kung nananatiling default ang hiwalay na router, kailangan ng router na iyon ng static na ruta patungo sa mga destinasyon ng tunnel, kung hindi ay napupunta ang packet sa maling hop bago pa ito makita ng gateway.

Ang DNS ay hiwalay na desisyon. Ang resolver sa malayong panig ay sumasagot lamang kung makakabalik ang sagot nito sa kliyente. Sa ilalim ng masquerade, lumilitaw na galing sa gateway ang query, kaya kumpleto na ang ruta ng pagbabalik ng resolver; sa ilalim ng policy routing, kailangan ng resolver ng parehong ruta ng pagbabalik gaya ng anumang malayong serbisyo.

Policy routing: panatilihin ang pinagmulan, magdagdag ng ruta ng pagbabalik

Nagsisimula ang policy routing sa isang table at isang patakarang pumipili nito. Ang trapikong pumapasok mula sa interface ng LAN ay ipinapadala sa nakalaang table, at ang table na iyon ay may default na ruta sa tunnel. Nananatiling hindi ginagalaw ang pangunahing table, kaya ang trapikong likha ng gateway mismo ay maaaring sumunod sa ibang landas.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Pagkatapos, kailangang i-route ng malayong panig ang LAN prefix pabalik sa tunnel. Iyon ay configuration sa malayong router, hindi sa gateway na ito. Kailangan ding tanggapin ng gateway ang mga sagot na dumarating sa ibang interface kaysa sa inaasahan ng pangunahing table; ang maluwag na reverse-path filtering (rp_filter na nakatakda sa 2) ang karaniwang pagsasaayos kapag itinatapon ng mahigpit na mode ang mga packet na iyon.

Kapag may dalawang aktibong tunnel, i-tag ang bawat daloy sa pagpasok at hayaang piliin ng tag ang table. Ang patakarang tumitingin lamang sa input interface ay nagpapadala ng trapiko ng dalawang tunnel sa iisang table, kaya nananakaw ng ikalawang tunnel ang mga daloy ng una. Subukan ang tag na iyon sa koneksyong nakakalampas sa muling pagkonekta, dahil doon lumilitaw ang pinaghalong patakaran.

Magpasya batay sa pagmamay-ari at sa kung ano ang itinatala ng malayong panig

Kung nagtatapos ang tunnel sa isang provider, gamitin ang masquerade. Hindi iruruta ng operator na iyon ang iyong mga pribadong saklaw ng LAN, at wala siyang dahilan para makilala ang mga indibidwal na kliyente sa likod ng iyong gateway. Isang nakikitang peer lang ang tanging modelong sinusuportahan ng kanyang patakaran, kaya ibigay iyon at panatilihin ang pagsasalin sa iyong gilid. Isang peer ang nakikita ng provider, na siyang eksaktong inaasahan ng kanyang patakaran, at namamana ng mga kliyente mo ang nag-iisang pagkakakilanlang iyon.

Kung pagmamay-ari mo ang dalawang dulo at kumikilos ang malalayong serbisyo sa mga address ng pinagmulan, karapat-dapat ang policy routing sa dagdag nitong ruta. Maaaring makilala ng mga firewall rule, access bawat user at audit log ang mga kliyente. Kung abot lang ang kailangan ng malayong panig, mas simple ang masquerade at inaalis nito ang isang buong klase ng pagkakamali sa ruta ng pagbabalik.

Normal ang mga hybrid na disenyo: policy routing sa loob ng sarili mong network, masquerade sa gilid ng provider. Ang mahalaga ay isulat kung aling hop ang nagsasalin at aling hop ang nagru-route, dahil ang aksidenteng naidagdag na NAT rule para sa isang kliyente ay nagtatago ng pinagmulan sa bawat kliyente sa parehong kadena.

Beripikahin mula sa isang kliyente, pagkatapos mula sa ikalawang kliyente

Patakbuhin ang pagsubok kung saan nagsisimula ang trapiko. Suriin ang rutang ginagamit ng host, panoorin ang packet na lumilitaw sa interface ng tunnel, at siyasatin ang conntrack para sa pagsasalin. Pinatutunayan ng pagkakasunod-sunod na iyon na tinahak ng packet ang inilaan na landas, hindi lamang na nakarating ito sa kung saan.

Ulitin ang pagsubok pagkatapos ng muling pagkonekta. Ang masquerade rule na nagpapangalan sa interface ay nakakalampas sa bagong address ng tunnel; ang patakarang nagpapangalan sa lumang address ay hindi. Pagkatapos, subukan ang ikalawang host ng LAN, dahil ang disenyong gumagana sa isang makina ay madalas nakadepende sa sariling ruta ng makinang iyon, hindi sa patakaran ng gateway.

Isulat ang piniling modelo, ang pinagmulang isinalin o pinanatili, at ang may-ari ng ruta ng pagbabalik sa mga tala ng gateway. Kung hindi, ang susunod na taong magdadagdag ng kliyente o tunnel ay maghuhula, at ang hula ang paraan kung paano nagiging bahagya ang isang gumaganang LAN-to-VPN setup.