Menjangkau workstation di balik NAT tanpa penerusan port

Dua titik akhir di balik NAT operator dan router kantor yang terkunci tidak menyisakan port masuk untuk diteruskan, dan refleksnya adalah tetap meminta satu. Pertanyaan yang lebih baik adalah sisi mana yang bisa menelepon keluar dan layanan terjangkau mana yang diizinkan membawa lalu lintas. Empat rancangan menjawab pertanyaan itu secara berbeda, dan gagal dengan cara berbeda ketika jalur diblokir. Memilih di antaranya adalah perbandingan jaminan, bukan nama protokol.

Empat rancangan, empat janji berbeda

Tabel di bawah adalah versi singkatnya. Baca kolom tengah sebagai janji yang bisa Anda uji, dan kolom kanan sebagai janji yang tidak dibuat siapa pun.

Baris mana yang berlaku bergantung pada tugasnya, bukan pada preferensi. Satu sesi desktop jarak jauh, satu shell administratif, dan akses ke seluruh subnet privat adalah tiga kebutuhan yang tidak memerlukan titik masuk yang sama, meskipun kebetulan melibatkan mesin yang sama.

Hub mengubah siapa yang menelepon keluar, bukan apa yang diizinkan

Dalam rancangan hub berbasis rute, laptop jarak jauh dan workstation, atau gateway situs di depannya, masing-masing membuka terowongan keluar ke layanan yang dapat dijangkau keduanya. Tidak ada yang menerima koneksi tanpa diminta di router workstation, dan itulah tepatnya sebabnya rancangan ini bertahan terhadap NAT dan tetap bekerja ketika situs tidak memiliki alamat statis. Hub lalu merutekan lalu lintas antara dua alamat dalam menurut kebijakannya sendiri.

Biayanya adalah hub harus ada, harus terjangkau dari kedua sisi, dan seseorang harus mengoperasikannya. Penyaringan keluar harus mengizinkan transport, dan jaringan yang memblokirnya akan menggagalkan rancangan meskipun tidak diperlukan penerusan port.

Bagian halusnya adalah keterjangkauan dan otorisasi merupakan keputusan terpisah yang diambil di tempat berbeda. Rute ke sebuah prefiks tidak mengatakan apa pun tentang layanan mana di workstation yang boleh dipakai identitas itu, dan aturan firewall yang mengizinkan terowongan tidak mengatakan apa pun tentang apakah akun bisa masuk. Konfigurasikan keduanya, uji keduanya, dan simpan keputusan otorisasi pada sistem yang memiliki sumber daya itu, bukan pada tabel perutean.

Traversal hanya bekerja bila kedua tumpukan menerapkannya

Traversal antarrekan adalah kemampuan sistem tertentu, bukan pengaturan yang memperbaiki VPN. Interactive Connectivity Establishment mengumpulkan beberapa alamat kandidat dan menguji pasangan hingga satu berhasil: kandidat host pada antarmuka lokal, kandidat reflektif server yang dibangun dari apa yang diungkap NAT, dan kandidat yang diteruskan melalui relai. Alamat privat saja bukan jalur, karena sisi lain tidak dapat merutekan ke sana.

Kasus yang melalui relai perlu dipahami sebelum dibuang. RFC 8656 menjelaskan TURN sebagai protokol di mana klien meminta alamat transport yang diteruskan kepada server dan server meneruskan lalu lintas antara klien itu dan rekannya. Jadi relai yang membawa data, yang secara hakiki berbeda dari direktori yang hanya membantu titik akhir bertemu. Bertukar alamat relai dengan rekan adalah langkah koordinasi yang harus dilakukan aplikasi.

Yang tidak dapat Anda janjikan adalah jalur langsung. NAT simetris dan sebagian firewall perusahaan menggagalkan pelubangan lubang, dan ketika itu terjadi sistem atau kembali ke relai atau gagal. Anda juga tidak dapat menyimpulkan bahwa dua titik akhir yang diterjemahkan tidak akan pernah bisa berbicara; tumpukan yang didukung dengan cadangan relai ada justru karena keduanya sering bisa. Putuskan apakah ketersediaan atau kelangsungan langsung lebih penting, lalu periksa jalur mana yang sebenarnya dipilih penerapan itu alih-alih mengasumsikan kasus yang menguntungkan.

Broker lebih sempit daripada jaringan

Ketika kebutuhannya satu aplikasi, broker aplikasi atau koneksi balik yang dimulai workstation bisa menjadi jawaban terkecil. Workstation menelepon keluar ke broker, broker mengautentikasi pengguna jarak jauh, dan hanya sesi aplikasi itu yang dibawa. Tidak ada rute ke subnet workstation yang dibuat, sehingga kompromi sesi jarak jauh tidak mewarisi jalur ke setiap perangkat di sampingnya.

Kesempitan itu punya harga: setiap aplikasi tambahan membutuhkan integrasinya sendiri, dan apa pun yang diasumsikan aplikasi tentang jaringan lokal, seperti berbagi berkas yang dibukanya di server terdekat, mungkin tidak terjangkau. Broker juga memusatkan kebijakan dan pencatatan di satu tempat, yang berguna sampai tempat itu menjadi gangguan.

Bandingkan batas kepercayaan, lalu uji jalurnya

Hub yang mengakhiri terowongan dapat membaca lalu lintas yang dirutekannya. Relai dapat membawa pertukaran yang dilindungi secara mandiri ketika aplikasi mengenkripsi ujung ke ujung, dan broker biasanya mengakhiri sesi yang disajikannya. Tetapkan di mana perlindungan benar-benar berakhir sebelum memutuskan bahwa dua rancangan setara karena keduanya terenkripsi.

Lalu periksa apa yang benar-benar dapat dijangkau workstation ke luar, karena setiap rancangan di atas bergantung padanya. Jalankan ini di workstation, ganti nama host yang ingin Anda gunakan.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Terima rancangan hanya setelah operasi jarak jauh yang dimaksud berhasil di bawah identitas yang diizinkan, identitas yang tidak disetujui ditolak, dan perilaku ketika jalur langsung atau relai tidak tersedia diketahui serta terdokumentasi. Sertakan sambung ulang dan konteks penyalaan normal workstation, karena sesi yang dimulai di kantor lewat LAN tidak menguji apa pun yang menjadi sandaran akses jarak jauh.