SoftEther VPN Azure: laluan geganti, bukan port terbuka

Pelayan anda berada di belakang penghala yang tidak boleh anda konfigurasikan, jadi rancangan jelas untuk mengusulkan port tidak tersedia. VPN Azure wujud khusus untuk situasi itu, dan ia menyelesaikannya dengan membalikkan arah sambungan pertama: pelayan menghubungi geganti ke luar, dan klien mencapai geganti dan bukan pelayan. Memahami pembalikan itu menjelaskan apa yang diperbaiki oleh perkhidmatan dan setiap had yang akan anda tempuhi kemudian.

Apa yang berubah pada laluan

Dengan pendengar biasa, klien membuka sambungan TCP ke alamat awam yang diusulkan penghala anda ke pelayan. Dengan geganti, pelayan mengekalkan sambungan keluar ke infrastruktur geganti, dan geganti menerima sambungan klien serta menyalurkan muatannya kepada pelayan yang menunggu. Tiada port masuk dibuka, tiada alamat statik diperlukan, dan penghala kekal tidak disentuh. Dari sudut pandangan tembok api, pelayan ialah klien keluar biasa, dan itulah sebabnya rangkaian ketat membenarkannya.

Geganti memberikan nama pada domainnya sendiri kepada pelayan itu, dan klien dikonfigurasikan untuk menyambung ke sana.

Nama itu milik perkhidmatan geganti, yang bukan Microsoft Azure VPN Gateway walaupun kedua-duanya dipanggil Azure sesuatu. Menganggapnya sebagai boleh ditukar ganti menghasilkan konfigurasi yang tidak mungkin berfungsi.

Protokol mana yang bertahan melalui geganti

Geganti mengangkut protokol SoftEther, dan projek mendokumenkan SSTP sebagai pilihan klien, yang berguna kerana Windows menyertakan klien SSTP. Namun ia tidak menjadi pengangkut umum untuk setiap pendengar pada hos: pendengar OpenVPN, responden IPsec dan perkhidmatan L2TP masing-masing memerlukan titik akhir sendiri yang boleh dicapai, dan tiada satu pun diangkut melalui geganti semata-mata kerana pelayan SoftEther disambungkan.

Oleh itu profil klien menunjuk kepada nama geganti dan bukan alamat pelayan, dan profil sedia ada yang dibina untuk sambungan langsung tidak akan berfungsi tanpa perubahan. Semak senarai klien yang disokong untuk versi yang anda jalankan sebelum mereka bentuk sekitar protokol yang tidak diangkut oleh geganti.

Apa yang geganti tidak lakukan untuk anda

Geganti ialah pengangkut. Ia tidak mencipta pengguna, hab maya, dasar akses atau laluan, dan ia tidak tahu apa-apa tentang rangkaian peribadi di belakang pelayan anda. Jika klien jauh mesti mencapai subrangkaian LAN, pelayan masih memerlukan konfigurasi jambatan atau penghalaan, laluan balik dan dasar tembok api yang menjadikannya berfungsi. Pelan alamat bertindih di kedua-dua hujung juga tidak kelihatan kepada geganti dan kekal menjadi masalah anda untuk diselesaikan.

Tetapan keselamatan yang disokong juga terpulang kepada anda. Dokumentasi projek mengandungi contoh platform yang lebih lama, dan menyalin tetapan sifer atau sijil lama daripada tangkapan skrin lama ialah cara yang baik untuk membina terowong yang tiada siapa dapat mengaudit. Gunakan panduan semasa untuk versi yang anda jalankan.

Pengesahan sijil dan pengesahan pengguna kekal menjadi tanggungjawab pelayan, dan geganti tidak pernah menggantikan mana-mana daripadanya.

Kendalikannya sebagai kebergantungan

Ketersediaan kini merangkumi pihak ketiga. Apabila geganti tidak dapat dicapai, klien tidak boleh menyambung tidak kira betapa sihatnya pelayan anda, dan kegagalan itu kelihatan seperti masalah klien dari luar. Pantau laluan geganti secara berasingan daripada kesihatan pelayan, dan simpan sandaran terdokumentasi seperti pendengar langsung pada alamat lain untuk hari ia penting.

Kependaman mengikut geografi geganti dan bukan kedekatan pengguna anda, yang wajar diukur sebelum menjanjikan prestasi interaktif melaluinya.

Sahkan identiti pelayan dan kemudian laluan aplikasi sebenar, bukan sekadar sepanduk sambungan berjaya, dan semak sama ada sumber yang anda perlukan boleh dicapai melalui keluarga alamat yang diangkut oleh geganti. Catat nama geganti, protokol yang digunakan dan sandaran, kerana ketiga-tiga fakta itu menjawab kebanyakan soalan masa depan tentang pautan ini.