Port Forward kumpara sa VPN Access: Saan Talaga Pumupunta ang Packet

Dalawang disenyo, isang HTTPS application, at ang packet ay dumadaan sa magkaibang ruta sa bawat isa. Binabago ng port forward kung saan ihahatid ang packet at hinahayaang ganoon ang iba. Ang VPN ay unang nagdadala ng packet na iyon sa loob ng isa pang packet, kaya ang listener ng application ay nakakakita ng ibang pinagmulan at mas maliit na maximum payload. Ang encryption na pinagtatalunan ng mga tao ay naroroon sa parehong kaso, dahil ang application ay HTTPS pa rin; ang naiiba ay kung sino ang makakabukas ng koneksyon at ano ang maaaring maobserbahan ng network sa gitna. Ang pagkakaibang iyon ang nagtatapos sa karamihan ng praktikal na tanong.

Ang DNAT rule ay nagsusulat muli ng destinasyon at doon humihinto

Sa isang Linux gateway, ang pag-publish ng serbisyo ay nangangahulugan ng rule sa PREROUTING chain ng nat table, o ang katumbas nito sa nftables. Tumutugma ang rule sa pampublikong address at port, pagkatapos ay isinusulat muli ang destinasyon sa pribadong address ng application. Hindi ginagalaw ang source address, source port at payload, at itinatala ng conntrack ang mapping para maisulat muli ang mga tugon paglabas. Ang pag-uugali ay ang tradisyonal na modelo ng pagsasalin ng address na inilarawan sa RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Hindi kailanman nalalaman ng listener ng application na dumating ang koneksyon sa pamamagitan ng pagsasalin. Nakikita nito ang tunay na source address ng client, na kapaki-pakinabang para sa access logs at mga limitasyon sa bilis, at sumasagot ito sa pribadong address dahil binabaliktad ng conntrack ang mapping. Walang anumang nagde-decrypt o muling nag-encrypt sa rutang iyon: tumatakbo pa rin ang TLS sa pagitan ng client at ng sariling certificate ng application.

Itinatakda rin ng rule ang mga failure mode na makikita mo mamaya. Kung nagpapasa ang gateway pero walang rutang pabalik sa client ang host ng application, lumalabas ang mga tugon na may maling pinagmulan at natigil ang handshake. Kung may pangalawang rule na tumugma muna, ang pagkakasunod-sunod ang magpapasya sa resulta, at ipinapakita ng iptables -t nat -L -n -v ang mga counter na nagpapatunay kung aling rule ang kumuha ng packet.

Binabalot ng tunnel ang packet bago ito makita ng listener

Hindi inilalathala ng VPN ang application. Bumubuo ang client ng panlabas na packet na naka-address sa pampublikong address ng gateway, ini-encrypt ang panloob na packet sa loob nito, at dine-decrypt ng gateway at itinatapon ang panloob na packet patungo sa pribadong destinasyon. Sa WireGuard, ang panlabas na transport ay UDP, karaniwang nasa mataas na port; sa OpenVPN sa TCP 443, ang panlabas na packet ay mukhang TLS sa kahit anong nagmamasid sa ruta.

Sa loob ng tunnel, pinapanatili ng panloob na packet ang mga pribadong address: ang tunnel address ng client, sabihin nating 10.8.0.6, at ang application sa 10.20.30.40. Kaya nakikita ng listener ang pinagmulan mula sa pool ng tunnel, at ibinabahagi ng bawat client ang gateway na iyon bilang susunod na hop. Madalas ipinapakita ng access logs sa likod ng VPN ang gateway sa halip na ang user dahil mismo sa kadahilanang ito, maliban kung pinapanatili ng gateway ang orihinal na pinagmulan.

May gastos ang pagbabalot sa espasyo ng header, at iyon ang tanging pagkakaiba sa antas ng mekanismo na may masusukat na bunga. Ang panlabas na IP header kasama ang UDP kasama ang sariling header ng WireGuard ay kumakain mula sa MTU ng ruta, kaya ang malalaking packet ay dapat i-fragment o dapat limitahan ng panloob na TCP stack ang MSS nito. Ang isang transfer na gumagana sa forwarded na ruta ay maaaring tumigil sa tunnel kapag nag-drop ang isang intermediate device ng ICMP na magsasabi sana ng mas maliit na MTU.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Ang exposure ay pinagpapasyahan sa pasukan, hindi sa cipher

Parehong nagtatapos ang dalawang disenyo sa parehong TLS listener, kaya parehong nagmamana ng parehong certificate, parehong protocol versions at parehong application login. Ang nababago ay kung sino ang pinapayagang magsimula ng handshake. Sa pampublikong forward, ang anumang host na umabot sa 203.0.113.10:443 ay nakakakuha ng TCP handshake at TLS ClientHello bago pa man tingnan ang authorization ng iyong application. Sa access sa pamamagitan lamang ng tunnel, maaabot lamang ang listener mula sa mga address na itinatapon ng gateway papasok sa tunnel, at namamatay ang SYN ng estranghero sa patakaran ng gateway.

Ang pagkakaibang iyon ay tungkol sa maabot, hindi sa pagiging lihim. Ang forwarded na HTTPS service ay hindi plaintext, at hindi inaalis ng VPN ang pangangailangan ng application authentication: ang pagtanggap sa tunnel ay sumasagot kung ang isang device ay makakapagpadala ng packet sa network na ito, habang ang file application ay sumasagot kung ang isang user ay makakabasa ng dokumento. Ang paghahalo ng dalawa ang paraan kung paano nagtatapos ang mga team sa VPN na nagbibigay ng buong LAN at application na may isang shared password.

Suriin ang listener at ang patakaran nang hiwalay, dahil ang alinman sa dalawa ay maaaring mas malawak kaysa sa inaakala mo:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Kung ipinapakita ng ss na ang listener ay nakatali sa 0.0.0.0, maaabot ang application mula saanman na pinapayagan ng routing at firewall policy, at ang forward ay isa lamang sa mga pasukan. Ang pagtali sa pribadong address, o paglimita sa source range sa firewall, ay hiwalay na desisyon mula sa pagpili ng VPN, at iyon ang desisyong tunay na nagpapaliit ng exposure.

Sukatin ang ruta, hindi ang label

Kapag may nagsasabing mas mabilis ang forward, pinapanatili ng tapat na paghahambing ang lahat ng iba: parehong client, parehong access network, parehong file, parehong TLS configuration, parehong application host. Patakbuhin ang transfer nang dalawang beses sa bawat ruta at itala ang kabuuang oras, bilang ng mga failure at pagiging tumutugon, hindi ang output ng isang walang kaugnayang speed test.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Hinihiwalay ng mga numerong iyon ang pag-set up ng koneksyon mula sa oras ng transfer, na mahalaga dahil ang dalawang ruta ay karaniwang nagkakaiba sa round-trip latency at MTU, hindi sa gastos ng cipher. Nagaganap ang TLS work sa mga endpoint sa parehong disenyo, at ang tunnel ay nagdadagdag ng encapsulation, ibang ruta at marahil mas abalang gateway. Kung mas mahaba ang ruta ng tunnel o puno ang gateway nito, ang pagkakaiba ay pag-aari ng ruta at hindi ng salitang encryption.

Piliin ang pasukan na patakaran na talagang kailangan ng serbisyo, pagkatapos ay magpasya kung ang masusukat na pagkakaiba ay makapagbibigay-katwiran sa pagbabago nito. Ang pampublikong forward ay bagay sa serbisyong para sa bukas na internet, na may mga paghihigpit sa pinagmulan, updated na TLS at monitoring sa harap. Ang access sa pamamagitan lamang ng tunnel ay bagay sa internal na tool na ang mga user ay nakarehistro na, sa kondisyon na ang routing ng gateway at ang mga pahintulot ng application ay parehong mas makitid kaysa sa buong LAN.

Bago mo sabihing tapos ang disenyo, kumpirmahin ang apat na bagay: kung saang address nakatali ang listener, aling rule o ruta ang tumatanggap ng packet, gumagana ba ang pabalik na ruta mula sa tunay na address ng client, at nakakalampas ba ang malalaking payload sa MTU. Ang bawat isa ay may command sa itaas, at wala sa kanila ang sinasagot ng salitang ligtas o ng bandwidth chart.