Desktop Jarak Jauh lewat VPN: kegagalan mana yang Anda alami?

Tunnel Anda aktif, wiki internal termuat, dan Desktop Jarak Jauh tetap menolak terhubung. Kombinasi itu normal, karena VPN menyediakan rute ke host sementara layanan desktop harus mendengarkan, diizinkan oleh firewall-nya sendiri, dan bersedia mengautentikasi akun. Empat tahap kegagalan berada di antara tunnel yang berfungsi dan sesi yang dapat dipakai, dan masing-masing gagal dengan pesan berbeda. Bacalah pesannya lebih dulu, karena pesan itu menyebut tahapnya.

Empat kegagalan yang tampak seperti satu

Tahapnya berurutan: nama teresolusi ke alamat privat yang dimaksud desain, port menjawab handshake TCP, host menerima koneksi menurut kebijakannya sendiri, dan login sesi berhasil. Setiap tahap membuat tahap berikutnya tak dapat diuji, karena itu mengubah pengaturan RDP sebelum jaringan beres hanya menghasilkan kebisingan. Gejalanya tampak identik dari sisi pengguna pada keempat kasus. Hanya pesan klien yang memisahkannya.

Situs web internal yang berfungsi tidak membuktikan satu pun dari keempatnya. Itu membuktikan bahwa sebuah host di jaringan yang sama menjawab pada port lain dengan layanan lain. Anggap itu sebagai bukti tentang perutean dan tidak lebih.

Uji secara berurutan dan catat hasilnya. Melompat ke layar login karena port menjawab adalah cara menghabiskan satu sore pada masalah firewall yang sudah ditemukan langkah pertama.

Apakah ada yang mendengarkan di 3389?

Mulailah dari nama, karena nama yang teresolusi ke alamat salah membatalkan setiap pengujian berikutnya. Tanyakan kepada resolver tunnel apa arti nama itu, lalu bandingkan jawabannya dengan alamat privat yang dimaksud desain, bukan dengan respons yang berhasil. Nama yang teresolusi ke alamat publik adalah seluruh masalahnya, dan tidak ada perubahan RDP yang akan memperbaikinya:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Lalu uji portnya, bukan hostnya. Handshake TCP yang selesai di 3389 memisahkan jangkauan dari semua yang di atasnya:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Jalankan uji itu dari LAN dan dari tunnel, karena perbedaan antara kedua hasil melokalisasi kesalahan pada jalur VPN. Ada dua firewall di jalur itu dan keduanya mudah tertukar: jaringan harus mengizinkan alamat tunnel klien mencapai host, dan firewall host sendiri harus mengizinkan sumber yang sama pada port yang mendengarkan. Aturan yang dibatasi pada subnet LAN tidak mencakup kumpulan klien VPN, dan itulah penyebab paling umum timeout yang hanya dilaporkan pengguna jarak jauh. Periksa cakupan aturannya, bukan keberadaannya.

Jalur balik pun layak diperiksa dengan cara yang sama. Balasan membutuhkan rute kembali ke kumpulan klien, bukan ke LAN, dan terjemahan di depan host mengubah sumber yang akan ditampilkan log Anda. Jika port menjawab di satu arah dan tidak di arah lain, bagian yang hilang biasanya adalah jalur balik.

Baca pesannya sebelum membaca konfigurasi

Tahap ketiga adalah host menolak koneksi menurut kebijakannya sendiri, yang sering tampak seperti port yang terbuka dan langsung tertutup. Ada yang menjawab, dan itu informasi berguna, bukan keheningan. Jika handshake selesai dan sesi langsung mati, jaringannya baik dan host yang memutuskan. Periksa izin Desktop Jarak Jauh sebelum menyentuh jaringan lagi.

Fitur dapat diaktifkan untuk mesin sementara akses dibatasi pada grup tertentu, dan listener dapat diikat dengan cara yang mengecualikan alamat tempat Anda datang. Autentikasi Tingkat Jaringan menambahkan gerbang yang gagal sebelum desktop dimuat, dan teks galatnya berbeda dari kata sandi salah. Bandingkan pesan klien dengan log peristiwa host, karena pesan menyebut gerbangnya dan log menyebut akunnya.

Login sesi adalah batasnya sendiri

Autentikasi milik layanan desktop, bukan VPN. Identitas tunnel dan akun desktop adalah kredensial terpisah dengan kebijakan penguncian terpisah, jadi tunnel yang berfungsi hanya membuktikan bahwa tunnel menerima Anda. Mengunci akun desktop tidak mengganggu tunnel, dan sebaliknya juga benar.

Jaga keduanya utuh. Saat rute privat tidak ada, perbaiki rutenya, karena mempublikasikan listener ke internet menukar bug jangkauan dengan desktop yang terbuka. Jangan juga melemahkan pemeriksaan identitas sesi untuk melewati peringatan sertifikat yang muncul pada saat yang sama. Sertifikat yang ditandatangani sendiri pada listener RDP menghasilkan peringatan secara desain, jadi menerimanya adalah keputusan, bukan langkah.

Hitung percobaan sebelum mencoba lagi. Ambang penguncian desktop menghitung login gagal terpisah dari kegagalan VPN, dan klien yang mencoba lagi dengan pengatur waktu dapat melewati ambang saat Anda masih menyunting aturan. Itu mekanisme percobaan ulang paralel yang sama yang mengunci akun setelah perubahan kata sandi.

Apa yang dapat dipindahkan sesi, dan di mana ia tinggal

Pelajari alur keluar yang disetujui sebelum Anda membutuhkannya. Menutup jendela mungkin hanya memutus tampilan sementara sesi tetap berjalan menurut kebijakan yang dikonfigurasi, yang penting pada host bersama atau yang diaudit. Keluar dari dalam sesi saat kebijakan mengharapkannya.

Lalu putuskan apa yang boleh dibawa sesi, karena papan klip, drive yang dialihkan, pengalihan printer, dan transfer berkas memindahkan data antara sistem lokal dan jarak jauh di tempat kebijakan mengizinkannya. Aplikasi terbitan yang berjalan di sisi jauh bukan otomatis batas tanpa unduhan, dan sesi yang tampak hanya-baca tetap dapat membawa papan klip. Uji tugas sebenarnya, bukan koneksinya: buka berkasnya, gunakan aplikasinya, dan pastikan pengalihan yang Anda butuhkan. Panduan Microsoft untuk mencapai desktop jarak jauh dari luar menjelaskan opsi pemaparan yang didukung, dan itu referensi yang lebih baik daripada listener publik yang ditambahkan di bawah tekanan.