Maabot ang serbisyo ng kliyenteng VPN: baliktad na tunnel o DNAT

Kahit ang laptop sa likod ng NAT ng provider ay makapaglilingkod sa isang kasamahan, hangga't ang VPN server ang nagsisilbing tagpuan. Dalawang mekanismo ang nakakarating doon: ang kliyente ay lumalabas at hinihiling sa server na maghawak ng port na nakikinig, o ang server ay naglalathala ng port at isinasalin ito sa tunnel. Pareho nilang nilulutas ang parehong problema sa maabot at magkaiba ang inaasal kapag may failure, pangangasiwa at pag-log. Tatlong kundisyon ang nagtatakda kung alin ang bagay sa iyong setup.

Dalawang hugis, isang tagpuan

Sa unang hugis binubuksan ng kliyente ang isang SSH session palabas at hinihiling sa server na makinig sa piniling port, at ibinabalik ang bawat koneksyon sa session na iyon. Walang ipinapasa sa server at walang pagsasalin ng packet na nangyayari, kaya ang tanging pangangailangan ay SSH account, pinapayagang forwarding at firewall rule para sa port. Nananatiling nakatali ang serbisyo sa loopback sa kliyente, na karaniwang siyang gusto mo.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

Sa ikalawang hugis, pag-aari ng server ang pampublikong port at muling isinusulat ang bawat koneksyon patungo sa address ng tunnel ng kliyente. Kailangan nito ng naka-enable na IP forwarding, pagsasalin ng destinasyon sa papasok at pagsasalin ng pinagmulan sa palabas, at patuloy itong gumagana kapag walang SSH session. Pag-aari ng server ang port at hindi ng session, at ang katangiang iyon ang nagtatakda sa karamihan ng totoong kaso.

Wala sa dalawang hugis ang mas ligtas sa likas na paraan. Pareho nilang inilalantad ang isang port ng serbisyo sa sinumang makakaabot sa pampublikong address ng server, at pareho pa rin silang umaasa sa sariling authentication ng serbisyo.

Kundisyon isa: dapat bang tumagal ang port kaysa sa session

Ang baliktad na forwarding ay nabubuhay nang eksaktong kasingtagal ng SSH session na gumawa nito. Kapag bumagsak ang link, nawawala ang nakikinig at nakikita ng kasamahan ang tinanggihang koneksyon sa halip na mabagal na landas. Ang pangangasiwa sa utos gamit ang systemd unit at restart policy ay nag-aayos nito, at ginagawang agad na nakikita ng ExitOnForwardFailure=yes ang nabigong binding sa halip na mag-iwan ng session na tumatakbo nang walang forwarding.

Ang isinaling port ay nakakaligtas sa mga restart kung napanatili ang mga rule, ngunit umaasa ito sa kliyenteng pananatilihin ang parehong address ng tunnel. Ang dynamic pool na nagbibigay sa laptop ng ibang address pagkatapos ng muling pagkonekta ay tahimik na itinuturo ang rule sa wala. Ireserba muna ang address ng tunnel, pagkatapos isulat ang rule, at ituring ang dalawa na isang pagbabago.

Kung kailangang sumagot ng serbisyo sa alas-tres ng madaling-araw nang walang sinumang nakatingin, ang hugis na may port na inilathala ng server ang may pinakakaunting gumagalaw na bahagi, dahil ang tanging proseso na dapat manatiling tumatakbo ay ang tunnel mismo.

Kundisyon dalawa: kanino ang firewall at ang mga log

Ang baliktad na hugis ay nag-iingat ng lahat ng patakaran sa dalawang lugar. Ang sshd ay nagpapasya sa pamamagitan ng AllowTcpForwarding kung pinapayagan man ang malayuang forwarding, at ang GatewayPorts ay nagpapasya kung ang nakikinig ay nakatali sa loopback o sa bawat address. Sa default na no ay hindi maabot ng kasamahan sa labas ng server ang port kahit nagtagumpay ang forwarding, at mukhang sirang tunnel iyon gayong address ng binding lang pala.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Ang isinaling hugis ay nangangailangan ng naka-enable na forwarding at dalawang rule, at ang ikalawang rule ang lugar kung saan nagkakamali ang karamihan ng recipe. Ang paglilimita sa pagsasalin ng pinagmulan sa conntrack state na DNAT ay nangangahulugang ang mga koneksyong ginawa ng destination rule lamang ang muling isinusulat, hindi ang bawat packet na ipinapadala ng server sa tunnel.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Sinisira rin ng pagsusulat na iyon ang attribution. Pagkatapos, nakikita ng kliyente ang bawat tumatawag bilang address ng tunnel ng server, na nagbabagsak sa anumang rate limit kada address sa isang balde lamang at nagtatago kung sino ang nagpadala ng ano. Kung mahalaga ang attribution, tapusin ang koneksyon sa server o panatilihin doon ang desisyon sa permit at magpasa ng identity sa header na pinagkakatiwalaan ng serbisyo. Ang pagpili sa pagitan ng dalawang pagbabagong iyon ay nakasalalay sa kung nagbabasa man ang serbisyo ng proxy header.

Kundisyon tatlo: isang port o marami, at kanino ang pangalan

Ang isang serbisyo sa isang port ang kaso kung saan nananalo ang baliktad na forwarding sa pagsisikap. Kailangan mo ng isang utos, isang account at isang firewall rule, at ang paglilinis ay ang pagpatay sa session. Maraming serbisyo sa parehong pampublikong address ang nagtutulak sa iyo patungo sa hugis na inilathala ng server, dahil kailangan ng bawat baliktad na forwarding ang sarili nitong server port at lumalaki ang set sa bawat serbisyo.

Pinalalala ng mga pangalan. Ang baliktad na forwarding ay maaaring nasa likod ng TCP proxy na nagruruta ayon sa SNI, habang ang isinaling port ay karaniwang isang port kada serbisyo. Kung ang serbisyo mismo ang nagtatapos ng TLS at kailangan ang orihinal na hostname, pinapanatili ito ng proxy approach at pinapanatili lamang ito ng DNAT approach kung tinatanggap ng serbisyo ang pangalang iyon sa port na iyon.

Itala kung alin sa tatlong kundisyon ang nagtakda ng hugis. Kung hindi, muling bubuksan ng susunod na taong magdadagdag ng ikalawang serbisyo ang parehong paghahambing na may mas kaunting konteksto.

Magpasya, pagkatapos ay subukan mula sa labas

Subukan ang landas mula sa network na walang rutang patungo sa laptop, at panoorin ang mga counter sa server habang tumatakbo ang kahilingan. Ang pagsubok mula sa server patungo sa sarili nitong pampublikong address ay walang pinapatunayan dito, dahil ang packet ay ginagawa nang lokal at hindi kailanman umaabot sa hook ng pagsasalin ng papasok, kaya maaaring pumasa ang pagsubok habang sira ang tunay na landas.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Ang mga counter na nananatiling flat ay nangangahulugang hindi kailanman umabot ang packet sa rule, na tumuturo sa provider o sa firewall ng host. Ang mga counter na gumagalaw habang tumatanggi ang serbisyo ay tumuturo sa sariling firewall ng kliyente o sa address na pinakikinggan ng serbisyo. Ang tunnel na nagdadala ng packet ngunit walang ibinabalik ay problema sa ruta o sa pabalik na landas, at wala sa tatlong resultang ito ang dapat i-debug sa pamamagitan ng pag-edit sa adapter ng kliyente. Itala kung aling counter ang gumalaw bago ka magbago ng anuman, dahil kailangan ng susunod na pagsubok ang baseline na iyon.

Kapag gumana na ang hugis, itala ang port, may-ari at paraan ng pangangasiwa sa tabi ng configuration ng tunnel. Ang pagbabago sa maabot na umiiral lamang sa shell history ng isang tao ay isang restart ang layo mula sa paulit-ulit na insidente.