VPN di Sebalik NAT yang Anda Tidak Boleh Konfigurasikan: Apa Masih Berfungsi

Setiap titik akhir terowong memerlukan alamat dan port yang boleh dicapai oleh pihak lain, dan penghala yang anda tidak uruskan ialah sebab biasa keperluan itu gagal. Bahagian yang menarik bukanlah kewujudan helah, tetapi setiap satunya bergantung pada sifat jadual pemetaan yang anda tidak nampak dari klien. Dua sifat itu menentukan hampir segala-galanya: bagaimana pemetaan dicipta, dan sama ada ia menerima paket daripada alamat yang bahagian dalam tidak pernah hubungi. Susun persekitaran mengikut sifat itu dan penyelesaian sampingan berhenti menjadi cerita rakyat.

Jadual pemetaan menentukan segala-galanya

Terjemahan alamat rangkaian menyimpan jadual di mana alamat dan port dalaman direkodkan terhadap alamat dan port awam. Balasan yang sepadan dengan rekod diterjemah balik, dan paket yang tiba dari luar tanpa rekod sepadan tidak mempunyai destinasi sama sekali. Satu tingkah laku itu menjelaskan mengapa pendengar di belakang penghala tidak boleh dicapai dari internet. Ia juga menjelaskan mengapa paket pertama dalam setiap arah mesti berasal dari dalam.

Lihat jadual dari sisi penghala dan penyelesaian sampingan menjadi jelas: sama ada sesuatu mencipta entri kekal, atau mencipta entri sementara dan mengekalkannya segar, atau trafik tidak pernah melalui laluan itu. Selebihnya artikel ini ialah ketiga-tiga kes itu mengikut urutan. Tiada apa di sini bergantung pada ciri vendor melebihi apa yang direkodkan jadual.

Apa yang boleh dan tidak boleh dilakukan perkhidmatan rendezvous

Hole punching UDP menggunakan rekod keluar sebagai bukaan sementara dan bukannya mengalahkan penapis. Kedua-dua rakan menghubungi perkhidmatan rendezvous, yang mempelajari setiap titik akhir awam dan melaporkan titik akhir pihak lain kembali. Kemudian kedua-duanya menghantar ke arah satu sama lain, dan setiap paket keluar mencipta atau menyegarkan rekod yang membenarkan balasan masuk. Urutan itulah yang menjadikannya berfungsi, dan urutan juga yang menjadikannya rapuh: rakan yang menghantar sebelum pihak lain mencipta rekodnya hanya digugurkan, manakala percubaan semula sejurus kemudian berjaya. Perkhidmatan itu sendiri tidak membawa trafik VPN, jadi satu-satunya pengaruhnya ialah masa yang diselaraskannya.

Tingkah laku pemetaan menentukan selebihnya, dan RFC 4787 menamakan tiga bentuk: bebas titik akhir, bergantung alamat, dan bergantung alamat serta port. Pada yang terakhir, port yang perlu disasarkan rakan berubah dengan setiap destinasi, jadi ramalan tidak lagi boleh dipercayai. Di situlah teknik ini menemui jalan buntu, kerana NAT gred pembawa dan tembok api korporat yang ketat kedua-duanya menghapuskan kebolehan ramalan yang diperlukan skema, dan berapa banyak percubaan semula pun tidak mengembalikannya.

Keepalive, but semula dan titik akhir yang bergerak

Laluan yang ditebuk ialah aliran, bukan pendengar, jadi apa sahaja yang berjalan di atasnya mesti bertahan dengan perubahan. Ia mesti mengekalkan pemetaan hidup dengan trafik berkala, menyedari apabila titik akhir awam bergerak, dan membina semula selepas penghala but semula atau alamat diperuntukkan semula. Produk mesh VPN meletakkan logik itu dalam satah kawalan mereka sendiri, manakala pelayan biasa menyerahkannya kepada anda. Keepalive hanya membantu selagi pemetaan yang sama bertahan, dan ia memakan bateri pada klien mudah alih, sebab itu selang agresif bukan percuma.

Komputer riba yang tidur sejam biasanya kembali pada titik akhir awam yang berbeza. Apa sahaja yang membina semula laluan mesti berjalan semula dari dalam, yang meletakkan syarat yang sama kembali pada klien.

Tiga cara mengelilingi pemajuan yang hilang

Cara pertama meminta penghala mencipta entri itu sendiri, melalui UPnP IGD, NAT-PMP atau PCP, apabila ciri itu wujud dan dihidupkan. Cara kedua menyerahkan trafik kepada relay beralamat awam, yang sentiasa berfungsi dan sentiasa berharga lebar jalur serta sempadan kepercayaan yang berbeza. Cara ketiga membalikkan arah: hos dalaman membuka terowong keluar ke pelayan awam dan segala-galanya menumpang di dalamnya.

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

Titik akhir relay menjadikan pertukaran itu kelihatan dalam konfigurasi klien, di mana titik akhir ialah relay dan bukan alamat rakan itu sendiri. Keepalive berterusan mengekalkan pemetaan hangat, dan awalan yang dibenarkan menentukan apa yang klien boleh hantar melaluinya. Terowong songsang dari hos dalaman ialah idea yang sama dengan pemilik berbeza, dan ia tidak memerlukan sebarang perubahan NAT. Ketiga-tiganya menghapuskan syarat masuk tanpa mengalahkan tembok api yang menyekat trafik tidak diminta secara reka bentuk, kerana trafik masih bermula dari dalam.

Padankan penyelesaian dengan pemilik penghala

Jika anda menguruskan penghala, pemajuan UDP statik lebih mudah diaudit daripada mana-mana skema tebukan dan gagal dengan cara yang anda lihat. Jika tidak, ketahui sama ada vendor menawarkan relay atau satah kawalan dihoskan, dan sama ada dasar membenarkan penggunaannya. Jika kedua-duanya tiada, pilihan yang tinggal ialah terowong songsang atau menerima bahawa titik akhir tidak boleh dicapai dari luar. Merekodkan yang mana satu anda gunakan lebih penting daripada kedengarannya, kerana pilihan berbeza dari segi siapa yang boleh memerhati trafik dan apa yang berlaku apabila pihak ketiga mengubah sesuatu.

Perhatikan sama ada laluan yang anda peroleh itu langsung atau melalui relay, kerana satu fakta itu meramalkan kependaman dan tingkah laku kegagalan sekali gus. RFC 4787 kekal sebagai rujukan untuk tingkah laku pemetaan di bawah semua ini, dan membaca bahagian pemetaannya lebih pantas daripada menguji tiga penyelesaian secara berturutan. Jadual tidak mengambil peduli pilihan mana yang anda buat; ia hanya merekodkan apa yang dibenarkan untuk paket seterusnya.