VPN di Balik NAT yang Tidak Bisa Anda Konfigurasi: Apa yang Masih Berfungsi

Setiap titik akhir terowongan memerlukan alamat dan port yang dapat dijangkau sisi lain, dan router yang tidak Anda kelola adalah alasan biasa mengapa syarat itu gagal. Bagian menariknya bukanlah bahwa ada trik, melainkan bahwa setiap trik bergantung pada sifat tabel pemetaan yang tidak Anda lihat dari klien. Dua sifat itu menentukan hampir segalanya: bagaimana pemetaan dibuat, dan apakah ia menerima paket dari alamat yang tidak pernah dihubungi sisi dalam. Urutkan lingkungan berdasarkan sifat tersebut dan solusi jalan pintas berhenti menjadi cerita rakyat.

Tabel pemetaan menentukan segalanya

Terjemahan alamat jaringan menyimpan tabel tempat alamat dan port internal dicatat terhadap alamat dan port publik. Balasan yang cocok dengan catatan diterjemahkan kembali, dan paket yang datang dari luar tanpa catatan yang cocok sama sekali tidak punya tujuan. Satu perilaku itu menjelaskan mengapa pendengar di balik router tidak dapat dijangkau dari internet. Ini juga menjelaskan mengapa paket pertama di setiap arah harus berasal dari dalam.

Lihat tabel dari sisi router dan solusi jalan pintas menjadi jelas: entah sesuatu membuat entri permanen, entah membuat entri sementara dan menjaganya tetap segar, atau lalu lintas tidak pernah melewati jalur itu. Sisa artikel ini adalah ketiga kasus tersebut secara berurutan. Tidak ada yang di sini bergantung pada fitur vendor di luar apa yang dicatat tabel.

Apa yang bisa dan tidak bisa dilakukan layanan rendezvous

Hole punching UDP memakai catatan keluar sebagai bukaan sementara alih-alih mengalahkan filter. Kedua peer menghubungi layanan rendezvous, yang mempelajari setiap titik akhir publik dan melaporkan titik akhir sisi lain kembali. Lalu keduanya saling mengirim, dan setiap paket keluar membuat atau menyegarkan catatan yang membiarkan balasan masuk. Urutannya yang membuatnya berhasil, dan urutannya juga yang membuatnya rapuh: peer yang mengirim sebelum sisi lain membuat catatannya begitu saja dibuang, sementara percobaan ulang sesaat kemudian berhasil. Layanan itu sendiri tidak membawa lalu lintas VPN, jadi satu-satunya pengaruhnya adalah waktu yang dikoordinasikannya.

Perilaku pemetaan menentukan sisanya, dan RFC 4787 menamai tiga bentuk: independen titik akhir, bergantung alamat, dan bergantung alamat serta port. Pada yang terakhir, port yang harus dibidik peer berubah dengan setiap tujuan, sehingga prediksi tidak lagi andal. Di situlah teknik ini menemui jalan buntu, karena NAT tingkat operator dan firewall korporat yang ketat keduanya menghilangkan prediktabilitas yang dibutuhkan skema, dan berapa pun percobaan ulang tidak mengembalikannya.

Keepalive, reboot, dan titik akhir yang berpindah

Jalur yang dilubangi adalah aliran, bukan pendengar, jadi apa pun yang berjalan di atasnya harus tahan terhadap perubahan. Ia harus menjaga pemetaan tetap hidup dengan lalu lintas berkala, menyadari ketika titik akhir publik berpindah, dan membangun ulang setelah router di-reboot atau alamat dialokasikan ulang. Produk mesh VPN menaruh logika itu di bidang kendali mereka sendiri, sedangkan server biasa menyerahkannya kepada Anda. Keepalive hanya membantu selama pemetaan yang sama bertahan, dan memakan baterai pada klien seluler, karena itu interval agresif tidak gratis.

Laptop yang tidur satu jam biasanya kembali pada titik akhir publik yang berbeda. Apa pun yang membangun ulang jalur harus berjalan lagi dari dalam, yang menaruh syarat yang sama kembali pada klien.

Tiga cara mengakali penerusan yang hilang

Cara pertama meminta router membuat entri itu sendiri, melalui UPnP IGD, NAT-PMP, atau PCP, bila fiturnya ada dan dinyalakan. Cara kedua menyerahkan lalu lintas ke relay beralamat publik, yang selalu berfungsi dan selalu berbiaya bandwidth plus batas kepercayaan yang berbeda. Cara ketiga membalik arah: host internal membuka terowongan keluar ke server publik dan semua hal lain menumpang di dalamnya.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Titik akhir relay membuat pertukaran itu terlihat dalam konfigurasi klien, di mana titik akhirnya adalah relay dan bukan alamat peer itu sendiri. Keepalive persisten menjaga pemetaan tetap hangat, dan prefiks yang diizinkan menentukan apa yang boleh dikirim klien melaluinya. Terowongan terbalik dari host internal adalah gagasan yang sama dengan pemilik berbeda, dan tidak memerlukan perubahan NAT sama sekali. Ketiganya menghapus syarat masuk tanpa mengalahkan firewall yang memblokir lalu lintas tak diminta secara desain, karena lalu lintas tetap dimulai dari dalam.

Cocokkan solusi dengan pemilik router

Jika Anda mengelola router, penerusan UDP statis lebih mudah diaudit daripada skema punching apa pun dan gagal dengan cara yang Anda lihat. Jika tidak, cari tahu apakah vendor menawarkan relay atau bidang kendali terkelola, dan apakah kebijakan mengizinkan pemakaiannya. Jika tidak ada keduanya, pilihan yang tersisa adalah terowongan terbalik atau menerima bahwa titik akhir tidak terjangkau dari luar. Mencatat mana yang Anda pakai lebih penting daripada kedengarannya, karena pilihannya berbeda dalam siapa yang dapat mengamati lalu lintas dan apa yang terjadi ketika pihak ketiga mengubah sesuatu.

Perhatikan apakah jalur yang Anda dapatkan langsung atau melalui relay, karena satu fakta itu memprediksi latensi dan perilaku kegagalan sekaligus. RFC 4787 tetap menjadi acuan perilaku pemetaan di bawah semua ini, dan membaca bagian pemetaannya lebih cepat daripada menguji tiga solusi secara berurutan. Tabel tidak peduli pilihan mana yang Anda ambil; ia hanya mencatat apa yang boleh dilakukan paket berikutnya.