Paano nagiging labasan ng internet ang isang OpenVPN client sa likod ng NAT

Tatlong Linux host, isang disenyo: isang hub ng OpenVPN na naaabot ng publiko, isang laptop ng gumagamit at isang makinang labasan sa likod ng ordinaryong home router na walang ipinapasang papasok. Ang labasan mismo ang tumatawag sa hub. Pagkatapos, pumapasok ang trapikong internet ng gumagamit sa tunel sa laptop at lumalabas sa sariling uplink ng labasan. Lahat ng nakakagulat sa setup na ito ay nagmumula sa isang detalye: ang labasan ang nagpasimula ng koneksyon, kaya umiiral na ang daan papasok at hindi na kailangan ng port forwarding para likhain ito.

Sinusubaybayan ng sumusunod ang daan ng packet at hindi ang pagkakasunod-sunod ng configuration, dahil may kahulugan lamang ang configuration kapag alam mo kung aling bahagi ang may aling desisyon. Bawat layer ay may eksaktong isang desisyon, at naiipon ang mga pagkakamali kung saan ang dalawang layer ay itinuturing na isa.

Dalawang sesyon ng transport, isang panloob na daan

Bawat host ay may sariling panlabas na koneksyon sa hub, at wala sa mga ito ang may alam sa isa. Ang trapiko ng gumagamit patungo sa internet ay hiwalay na panloob na daloy na nagkataong dinadala sa loob ng tunel ng gumagamit at pagkatapos ay inilalabas muli mula sa tunel ng labasan. Ang panloob na daloy na ito ang kailangang i-ruta ng hub, at ito ang kailangang ipasa ng labasan.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Dahil ang dalawang panlabas na koneksyon ay lumalabas mula sa panig ng client, hindi kailanman nakikita ng router ng labasan ang papasok na SYN at hindi kailanman nangangailangan ng patakaran ng NAT ng destinasyon. Kailangan lang nitong panatilihing buhay ang naitatag na transport, na ginagawa na nito para sa anumang pangmatagalang koneksyon. Wala sa pampublikong internet ang kailangang maabot muna ang labasan, kaya hindi problema ang dynamic na address sa uplink na iyon. Kailangan pa ring payagan ng router ang papalabas na sesyon, ngunit iyon ang parehong pahintulot na ginagamit na ng browser.

Ano talaga ang inilalagay ng iroute sa loob ng server

Ang hub ang tanging device na nagpapasya kung aling peer ang may aling destinasyon, at ginagawa nito ang pasyang iyon sa sarili nitong routing table sa user space, hindi sa table ng kernel. Ang entry ng client-config-dir para sa labasan na pinangalanang exit-node ay maaaring mag-angkin ng default na prefix doon:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Sinasabi ng linyang iyon sa proseso ng server na "ang mga panloob na packet na may anumang destinasyon ay pag-aari ng client na ito". Hindi ito nagdadagdag ng default na ruta sa operating system ng hub at hindi ginagawang internet gateway ang hub. Sanggunian ng OpenVPN 2.6 pinapanatili ang panloob na routing na partikular sa client at ang routing ng kernel bilang magkahiwalay na mekanismo, at ang paghihiwalay na iyon ang dahilan kung bakit gumagana ang disenyo nang hindi hinahawakan ang default na ruta ng hub.

Kailangan ng gumagamit ang salamin na tagubilin, na inihahatid bilang push, upang ang kanyang sariling trapiko ay pumasok sa tunel sa halip na lumabas sa lokal na gateway. Sa subnet topology, ang pool ay konektadong ruta sa tun device ng labasan, kaya ang pabalik na direksyon ay hindi nangangailangan ng karagdagang push; ang hindi dapat matanggap ng labasan ay ang redirection sa ibaba, na magpapadala ng sarili nitong uplink traffic pabalik sa tunel na sinusubukan nitong gamitin. Ipadala lamang ito sa gumagamit at basahin ang mga inilapat na ruta sa client sa halip na umasa na napili ang file ng CCD.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Ang kernel ng labasan ang nagpapasa

Sa loob ng labasan, dumarating ang packet mula sa gumagamit sa interface ng tun na naka-address sa ilang internet host. Sinusuri ng kernel ang routing table nito, hinahanap ang tunay na uplink bilang pinakamahusay na tugma at pagkatapos ay naglalapat ng dalawang malayang patakaran: maipapasa ba ang packet na ito, at makakalabas ba ito sa interface na iyon gamit ang source address na iyon. Ang pagpapasa ay isang sysctl, at naka-off ito bilang default sa maraming distribusyon.

Kaya kailangan ng labasan ang palagiang naka-on na pagpapasa ng IPv4, patakaran na tumatanggap sa mga source ng tunel ng gumagamit patungo sa uplink, at ang daan ng sagot pabalik sa tun. Ang pagpapagana ng pagpapasa para sa buong host ay nagbabago rin ng pag-uugali ng lahat ng iba pang niruruta dito, kaya dapat pangalanan ng patakaran ang mga source at interface sa halip na tanggapin ang lahat.

Ang daan pabalik ay binibili ng pagsasalin ng source

Walang ruta ang internet host patungo sa address na 10.90.0.x, kaya itatapon ang mga sagot bago pa man umabot sa labasan. Ang muling pagsulat ng source habang lumalabas ang packet sa uplink ay lumulutas niyon, at binabaligtad ng connection tracking ang muling pagsulat sa pagbabalik.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Ang patakaran sa itaas ay panimulang punto para sa isang uplink interface, hindi patakaran ng firewall. Paikliin ang source sa mga asignasyong talagang pinahintulutan mo, at ihiwalay ang sariling patakaran ng input ng labasan upang ang masking para sa trapiko ng tunel ay hindi tahimik na maglantad ng lokal na serbisyo. Sa host na may dynamic na uplink address, inililigtas ka rin ng masking sa mano-manong pagsubaybay ng address.

Saan maipapatupad ng hub at saan hindi

Sa client-to-client at tradisyonal na datapath sa user space, ipinapasa ng hub ang mga panloob na packet sa pagitan ng mga peer sa loob ng proseso ng server. Hindi kailanman dumadaan ang mga ito sa FORWARD chain ng kernel ng hub, kaya hindi kayang limitahan ng patakaran sa kernel doon ang pagdaan sa pagitan ng mga peer, gaano man ito kaingat na isinulat. Ang pagpapatupad ay dapat manirahan sa sariling patakaran ng server: sino ang pinapayagang kumonekta, aling file ng CCD ang natatanggap, at kung ibinibigay man ang default na pagmamay-ari ng labasan.

Kaya ang default na iroute ay malawak na pasya sa pagtitiwala. Dapat tanggapin ng labasan nang lehitimo ang trapikong pabalik mula sa di-makatwirang address ng internet, at dapat itong maging makinang kontrolado, pinapatch at sinusubaybayan mo. Ang pagbibigay ng parehong pagmamay-ari sa peer na hindi mo ipagkakatiwala ng router ay ang pagkakamaling inaanyayahan ng disenyong ito.

Ang pagiging miyembro ang tunay na kontrol. Sinumang client na makapag-configure ng sariling ruta ay maaaring subukang gamitin ang labasan, kaya ang paglimita kung sino ang makakonekta, o kung aling peer ang saserbisyuhan ng labasan, ay bahagi ng disenyo at hindi naisip lamang pagkatapos.

Bumagsak nang ligtas kapag nawala ang labasan

Patayin ang labasan at mawawala ang panloob na default na pagmamay-ari kasama ng sesyon nito. Ang hindi dapat mangyari ay tahimik na maging kapalit na labasan ang hub: walang default na ruta mula sa pool ng VPN patungo sa uplink ng hub, at walang malawak na patakaran ng masking sa hub na buong galak na magpapasa ng parehong trapiko. Subukan ang kabiguang iyon nang sadya, pagkatapos ay subukan ang pagbangon gamit ang bagong daloy at hindi ang pahinang nakabukas na.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Kung ang trapiko ng gumagamit ay umaabot pa rin sa internet pagkatapos mawala ang labasan, may ibang nagdadala nito at wala ang hangganang nilayon mo. Ituring din ang DNS at IPv6 bilang magkahiwalay na desisyon: ang rutang IPv4 at masking ay walang sinasabi tungkol sa trapikong AAAA, at ang resolver na itinutulak ng hub ay sasagot mula sa lugar kung saan talaga lumalabas ang query.