Port Forward lawan Akses VPN: Ke Mana Paket Sebenarnya Pergi

Port forward menulis semula destinasi dan berhenti di situ; VPN membalut paket itu dahulu. Lihat lapisan mana yang diubah oleh setiap satu dan apa maksudnya bagi HTTPS.

Dua reka bentuk, satu aplikasi HTTPS, dan paket melalui laluan berbeza dalam setiap satu. Port forward mengubah ke mana paket dihantar dan membiarkan selebihnya. VPN membawa paket itu di dalam paket lain dahulu, jadi pendengar aplikasi melihat sumber berbeza dan muatan maksimum yang lebih kecil. Penyulitan yang diperdebatkan orang ada dalam kedua-dua kes, kerana aplikasi itu masih HTTPS; yang berbeza ialah siapa boleh membuka sambungan dan apa yang boleh diperhatikan oleh rangkaian di antaranya. Perbezaan itu menyelesaikan kebanyakan soalan praktikal.

Peraturan DNAT menulis semula destinasi dan berhenti di situ

Pada get laluan Linux, menerbitkan perkhidmatan bermaksud peraturan dalam rantaian PREROUTING jadual nat, atau setara dengannya dalam nftables. Peraturan itu memadankan alamat dan port awam, kemudian menulis semula destinasi ke alamat peribadi aplikasi. Alamat sumber, port sumber dan muatan tidak disentuh, dan conntrack merekodkan pemetaan supaya balasan ditulis semula semasa keluar. Tingkah laku ini ialah model terjemahan alamat tradisional yang diterangkan dalam 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

Pendengar aplikasi tidak pernah tahu bahawa sambungan itu tiba melalui terjemahan. Ia melihat alamat sumber sebenar klien, yang berguna untuk log akses dan had kadar, dan ia membalas ke alamat peribadi kerana conntrack membalikkan pemetaan. Tiada apa-apa di laluan itu menyahsulit atau menyulit semula: TLS masih berjalan antara klien dan sijil aplikasi itu sendiri.

Peraturan itu juga menetapkan mod kegagalan yang akan anda temui kemudian. Jika get laluan menghantar tetapi hos aplikasi tiada laluan balik kepada klien, balasan keluar dengan sumber yang salah dan jabat tangan tersekat. Jika peraturan kedua padan dahulu, susunan menentukan hasil, dan iptables -t nat -L -n -v menunjukkan pembilang yang membuktikan peraturan mana yang mengambil paket itu.

Terowong membalut paket sebelum pendengar melihatnya

VPN tidak menerbitkan aplikasi sama sekali. Klien membina paket luar yang dialamatkan ke alamat awam get laluan, menyulitkan paket dalam di dalamnya, dan get laluan menyahsulit serta menghalakan paket dalam ke destinasi peribadi. Dengan WireGuard pengangkutan luar ialah UDP, biasanya pada port tinggi; dengan OpenVPN melalui TCP 443 paket luar kelihatan seperti TLS kepada apa-apa yang memerhati laluan.

Di dalam terowong, paket dalam mengekalkan alamat peribadi: alamat terowong klien, katakan 10.8.0.6, dan aplikasi di 10.20.30.40. Oleh itu pendengar melihat sumber daripada kolam terowong, dan setiap klien berkongsi get laluan itu sebagai hop seterusnya. Log akses di belakang VPN sering memaparkan get laluan dan bukan pengguna tepat kerana sebab ini, melainkan get laluan mengekalkan sumber asal.

Pembalutan memakan ruang pengepala, dan itulah satu-satunya perbezaan pada peringkat mekanisme dengan akibat yang boleh diukur. Pengepala IP luar tambah UDP tambah pengepala WireGuard sendiri memakan MTU laluan, jadi paket besar mesti difragmentasi atau tindanan TCP dalam mesti mengehadkan MSS-nya. Pemindahan yang berfungsi pada laluan dihantar boleh tersekat pada terowong apabila peranti pertengahan menggugurkan ICMP yang sepatutnya menandakan MTU lebih kecil.

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

Pendedahan ditentukan di pintu masuk, bukan oleh sifer

Kedua-dua reka bentuk berakhir pada pendengar TLS yang sama, jadi kedua-duanya mewarisi sijil, versi protokol dan log masuk aplikasi yang sama. Yang berubah ialah siapa yang dibenarkan memulakan jabat tangan. Dengan port forward awam, mana-mana hos yang mencapai 203.0.113.10:443 mendapat jabat tangan TCP dan TLS ClientHello sebelum kebenaran aplikasi anda disemak. Dengan akses melalui terowong sahaja, pendengar hanya boleh dicapai dari alamat yang dihalakan get laluan ke terowong, dan SYN orang asing mati pada dasar get laluan.

Perbezaan itu tentang kebolehcapaian, bukan kerahsiaan. Perkhidmatan HTTPS yang dihantar bukan teks biasa, dan VPN tidak menghapuskan keperluan pengesahan aplikasi: kemasukan terowong menjawab sama ada peranti boleh menghantar paket ke rangkaian ini, manakala aplikasi fail menjawab sama ada pengguna boleh membaca dokumen. Mencampurkan kedua-duanya ialah cara pasukan berakhir dengan VPN yang memberikan seluruh LAN dan aplikasi dengan satu kata laluan dikongsi.

Periksa pendengar dan dasar secara berasingan, kerana mana-mana satu boleh lebih luas daripada yang anda sangka:

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

Jika ss menunjukkan pendengar terikat pada 0.0.0.0, aplikasi boleh dicapai dari mana-mana yang dibenarkan oleh penghalakan dan dasar tembok api, dan port forward hanyalah salah satu cara masuk. Mengikat pada alamat peribadi, atau mengehadkan julat sumber dalam tembok api, ialah keputusan berasingan daripada memilih VPN, dan itulah keputusan yang benar-benar menyempitkan pendedahan.

Ukur laluan, bukan label

Apabila seseorang mendakwa port forward lebih pantas, perbandingan jujur mengekalkan segala-galanya yang lain: klien sama, rangkaian akses sama, fail sama, konfigurasi TLS sama, hos aplikasi sama. Jalankan pemindahan dua kali bagi setiap laluan dan catat jumlah masa, bilangan kegagalan dan responsif, bukan output ujian kelajuan yang tidak berkaitan.

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

Nombor-nombor itu memisahkan persediaan sambungan daripada masa pemindahan, yang penting kerana kedua-dua laluan biasanya berbeza dalam kependaman pergi balik dan MTU, bukan dalam kos sifer. Kerja TLS berlaku di hujung dalam kedua-dua reka bentuk, dan terowong menambah enkapsulasi, laluan berbeza dan mungkin get laluan yang lebih sibuk. Jika laluan terowong lebih panjang atau get laluannya terbeban, perbezaan itu milik laluan, bukan milik perkataan penyulitan.

Pilih dasar masuk yang benar-benar diperlukan oleh perkhidmatan, kemudian tentukan sama ada perbezaan yang diukur mewajarkan mengubahnya. Port forward awam sesuai untuk perkhidmatan yang ditujukan kepada internet terbuka, dengan sekatan sumber, TLS yang dikemas kini dan pemantauan di hadapannya. Akses melalui terowong sahaja sesuai untuk alat dalaman yang penggunanya sudah didaftarkan, dengan syarat penghalakan get laluan dan kebenaran aplikasi kedua-duanya lebih sempit daripada seluruh LAN.

Sebelum menyatakan reka bentuk selesai, sahkan empat perkara: alamat mana pendengar terikat, peraturan atau laluan mana yang menerima paket, sama ada laluan balik berfungsi dari alamat sebenar klien, dan sama ada muatan besar melepasi MTU. Setiap satu mempunyai arahan di atas, dan tiada satu pun dijawab oleh perkataan selamat atau carta lebar jalur.

Artikel berkaitan