Port Forward vs Akses VPN: Ke Mana Paket Sebenarnya Pergi

Port forward menulis ulang tujuan dan berhenti di situ; VPN membungkus paket lebih dulu. Lihat lapisan mana yang diubah masing-masing dan artinya bagi HTTPS.

Dua rancangan, satu aplikasi HTTPS, dan paket menempuh rute berbeda di masing-masing. Port forward mengubah ke mana paket dikirim dan membiarkan sisanya. VPN membawa paket itu di dalam paket lain lebih dulu, sehingga pendengar aplikasi melihat sumber berbeda dan muatan maksimum yang lebih kecil. Enkripsi yang diperdebatkan orang ada di kedua kasus, karena aplikasinya tetap HTTPS; yang berbeda adalah siapa yang boleh membuka koneksi dan apa yang dapat diamati jaringan di antaranya. Perbedaan itu menyelesaikan sebagian besar pertanyaan praktis.

Aturan DNAT menulis ulang tujuan dan berhenti di situ

Di gateway Linux, menerbitkan layanan berarti aturan di rantai PREROUTING tabel nat, atau padanannya di nftables. Aturan mencocokkan alamat dan port publik, lalu menulis ulang tujuan ke alamat privat aplikasi. Alamat sumber, port sumber, dan muatan tidak tersentuh, dan conntrack mencatat pemetaan agar balasan ditulis ulang saat keluar. Perilaku ini adalah model terjemahan alamat tradisional yang dijelaskan 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 bahwa koneksi datang melalui terjemahan. Ia melihat alamat sumber asli klien, yang berguna untuk log akses dan batas laju, dan ia menjawab ke alamat privat karena conntrack membalik pemetaan. Tidak ada yang mendekripsi atau mengenkripsi ulang di jalur itu: TLS tetap berjalan antara klien dan sertifikat aplikasi sendiri.

Aturan itu juga menetapkan mode kegagalan yang akan Anda temui nanti. Jika gateway meneruskan tetapi host aplikasi tidak punya rute kembali ke klien, balasan keluar dengan sumber yang salah dan jabat tangan macet. Jika aturan kedua cocok lebih dulu, urutan menentukan hasil, dan iptables -t nat -L -n -v menunjukkan penghitung yang membuktikan aturan mana yang mengambil paket.

Terowongan membungkus paket sebelum pendengar melihatnya

VPN sama sekali tidak menerbitkan aplikasi. Klien membangun paket luar yang dialamatkan ke alamat publik gateway, mengenkripsi paket dalam di dalamnya, dan gateway mendekripsi serta merutekan paket dalam ke tujuan privat. Dengan WireGuard transport luar adalah UDP, biasanya di port tinggi; dengan OpenVPN lewat TCP 443 paket luar tampak seperti TLS bagi apa pun yang mengawasi jalur.

Di dalam terowongan, paket dalam mempertahankan alamat privat: alamat terowongan klien, misalnya 10.8.0.6, dan aplikasi di 10.20.30.40. Karena itu pendengar melihat sumber dari kumpulan terowongan, dan setiap klien berbagi gateway itu sebagai lompatan berikutnya. Log akses di balik VPN sering menampilkan gateway alih-alih pengguna justru karena alasan ini, kecuali gateway mempertahankan sumber asli.

Pembungkusan memakan ruang tajuk, dan itulah satu-satunya perbedaan tingkat mekanisme dengan akibat yang dapat diukur. Tajuk IP luar ditambah UDP ditambah tajuk WireGuard sendiri memakan MTU jalur, jadi paket besar harus dipecah atau tumpukan TCP dalam harus membatasi MSS-nya. Transfer yang berjalan di jalur diteruskan bisa macet di terowongan ketika perangkat tengah membuang ICMP yang seharusnya 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

Paparan ditentukan di pintu masuk, bukan oleh cipher

Kedua rancangan berakhir di pendengar TLS yang sama, jadi keduanya mewarisi sertifikat, versi protokol, dan login aplikasi yang sama. Yang berubah adalah siapa yang diizinkan memulai jabat tangan. Dengan port forward publik, host mana pun yang mencapai 203.0.113.10:443 mendapat jabat tangan TCP dan TLS ClientHello bahkan sebelum otorisasi aplikasi Anda diperiksa. Dengan akses hanya lewat terowongan, pendengar hanya dapat dijangkau dari alamat yang dirutekan gateway ke terowongan, dan SYN orang asing mati di kebijakan gateway.

Perbedaan itu soal keterjangkauan, bukan kerahasiaan. Layanan HTTPS yang diteruskan bukan teks polos, dan VPN tidak menghapus kebutuhan autentikasi aplikasi: penerimaan terowongan menjawab apakah perangkat boleh mengirim paket ke jaringan ini, sedangkan aplikasi berkas menjawab apakah pengguna boleh membaca dokumen. Mencampur keduanya adalah cara tim berakhir dengan VPN yang memberikan seluruh LAN dan aplikasi dengan satu kata sandi bersama.

Periksa pendengar dan kebijakan secara terpisah, karena salah satunya bisa lebih luas dari dugaan Anda:

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 ke 0.0.0.0, aplikasi dapat dijangkau dari mana pun perutean dan kebijakan firewall mengizinkan, dan port forward hanyalah salah satu cara masuk. Mengikat ke alamat privat, atau membatasi rentang sumber di firewall, adalah keputusan terpisah dari memilih VPN, dan itulah keputusan yang benar-benar mempersempit paparan.

Ukur jalurnya, bukan labelnya

Ketika seseorang mengklaim port forward lebih cepat, perbandingan jujur menjaga semua hal lain tetap: klien sama, jaringan akses sama, berkas sama, konfigurasi TLS sama, host aplikasi sama. Jalankan transfer dua kali per jalur dan catat waktu total, jumlah kegagalan, dan daya tanggap, bukan keluaran uji kecepatan yang tidak terkait.

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

Angka-angka itu memisahkan penyiapan koneksi dari waktu transfer, yang penting karena kedua jalur biasanya berbeda dalam latensi pulang-pergi dan MTU, bukan dalam biaya cipher. Pekerjaan TLS terjadi di titik akhir pada kedua rancangan, dan terowongan menambah enkapsulasi, rute berbeda, dan mungkin gateway yang lebih sibuk. Jika jalur terowongan lebih panjang atau gateway-nya terbebani, perbedaannya milik jalur, bukan milik kata enkripsi.

Pilih kebijakan masuk yang benar-benar dibutuhkan layanan, lalu putuskan apakah perbedaan terukur membenarkan mengubahnya. Port forward publik cocok untuk layanan yang ditujukan bagi internet terbuka, dengan pembatasan sumber, TLS yang diperbarui, dan pemantauan di depannya. Akses hanya lewat terowongan cocok untuk alat internal yang penggunanya sudah terdaftar, asalkan perutean gateway dan izin aplikasi keduanya lebih sempit daripada seluruh LAN.

Sebelum menyatakan rancangan selesai, pastikan empat hal: alamat mana pendengar terikat, aturan atau rute mana yang menerima paket, apakah jalur balik bekerja dari alamat asli klien, dan apakah muatan besar bertahan melewati MTU. Masing-masing punya perintah di atas, dan tidak satu pun dijawab oleh kata aman atau oleh bagan bandwidth.

Artikel terkait