Desktop Jauh melalui VPN: kegagalan mana yang anda alami?

Tunel anda aktif, wiki dalaman dimuatkan, dan Desktop Jauh masih enggan menyambung. Gabungan itu normal, kerana VPN menyediakan laluan ke hos manakala perkhidmatan desktop mesti mendengar, dibenarkan oleh firewallnya sendiri dan bersedia mengesahkan akaun. Empat peringkat kegagalan terletak antara tunel yang berfungsi dan sesi yang boleh digunakan, dan setiap satu gagal dengan mesej berbeza. Baca mesej itu dahulu, kerana ia menamakan peringkat.

Empat kegagalan yang kelihatan seperti satu

Peringkatnya tersusun: nama diselesaikan kepada alamat peribadi yang dimaksudkan reka bentuk, port menjawab genggaman tangan TCP, hos menerima sambungan mengikut dasarnya sendiri, dan log masuk sesi berjaya. Setiap peringkat menjadikan peringkat seterusnya tidak dapat diuji, sebab itu menukar tetapan RDP sebelum rangkaian dikemaskan hanya menghasilkan bunyi bising. Gejala kelihatan sama dari sisi pengguna dalam keempat-empat kes. Hanya mesej klien memisahkan mereka.

Laman web dalaman yang berfungsi tidak membuktikan mana-mana satu daripada empat. Ia membuktikan bahawa hos pada rangkaian yang sama menjawab pada port lain dengan perkhidmatan lain. Anggap itu sebagai bukti tentang penghalaan dan tidak lebih.

Uji mengikut urutan dan catat hasilnya. Melompat ke skrin log masuk kerana port menjawab ialah cara menghabiskan sebelah petang pada masalah firewall yang sudah ditemui langkah pertama.

Adakah sesuatu mendengar pada 3389?

Mulakan dengan nama, kerana nama yang diselesaikan kepada alamat salah membatalkan setiap ujian berikutnya. Tanya penyelesai tunel apa maksud nama itu, kemudian bandingkan jawapan dengan alamat peribadi yang dimaksudkan reka bentuk, bukan dengan tindak balas yang berjaya. Nama yang diselesaikan kepada alamat awam ialah keseluruhan masalah, dan tiada perubahan RDP akan membaikinya:

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

Kemudian uji port itu, bukan hos. Genggaman tangan TCP yang selesai pada 3389 memisahkan jangkauan daripada segala yang di atasnya:

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

Jalankan ujian itu dari LAN dan dari tunel, kerana perbezaan antara kedua-dua hasil menyetempatkan kerosakan pada laluan VPN. Terdapat dua firewall pada laluan itu dan mudah dikelirukan: rangkaian mesti membenarkan alamat tunel klien mencapai hos, dan firewall hos sendiri mesti membenarkan sumber yang sama pada port yang mendengar. Peraturan yang terhad kepada subnet LAN tidak meliputi kumpulan klien VPN, dan itulah punca paling biasa bagi tamat masa yang hanya dilaporkan oleh pengguna jauh. Periksa liputan peraturan, bukan kewujudannya.

Laluan balik juga berhak mendapat pemeriksaan yang sama. Balasan memerlukan laluan kembali ke kumpulan klien, bukan ke LAN, dan penterjemahan di hadapan hos mengubah sumber yang akan ditunjukkan log anda. Jika port menjawab satu arah dan tidak arah yang lain, separuh yang hilang biasanya ialah laluan balik.

Baca mesej sebelum membaca konfigurasi

Peringkat ketiga ialah hos menolak sambungan mengikut dasarnya sendiri, yang selalunya kelihatan seperti port yang terbuka dan tertutup serta-merta. Sesuatu menjawab, dan itu maklumat berguna, bukan kesunyian. Jika genggaman tangan selesai dan sesi mati serta-merta, rangkaian baik dan hos yang membuat keputusan. Lihat kebenaran Desktop Jauh sebelum menyentuh rangkaian lagi.

Ciri ini boleh dihidupkan untuk mesin manakala akses terhad kepada kumpulan tertentu, dan pendengar boleh diikat dengan cara yang mengecualikan alamat tempat anda datang. Pengesahan Tahap Rangkaian menambah gerbang yang gagal sebelum desktop dimuatkan, dan teks ralatnya berbeza daripada kata laluan yang salah. Bandingkan mesej klien dengan log peristiwa hos, kerana mesej menamakan gerbang dan log menamakan akaun.

Log masuk sesi ialah sempadannya sendiri

Pengesahan milik perkhidmatan desktop, bukan VPN. Identiti tunel dan akaun desktop ialah kelayakan berasingan dengan dasar penguncian berasingan, jadi tunel yang berfungsi hanya membuktikan tunel menerima anda. Mengunci akaun desktop tidak mengganggu tunel, dan sebaliknya juga benar.

Kekalkan kedua-duanya utuh. Apabila laluan peribadi tiada, betulkan laluan itu, kerana menerbitkan pendengar ke internet menukar pepijat jangkauan dengan desktop yang terdedah. Jangan lemahkan pemeriksaan identiti sesi juga untuk melepasi amaran sijil yang muncul pada masa yang sama. Sijil yang ditandatangani sendiri pada pendengar RDP menghasilkan amaran secara reka bentuk, jadi menerimanya ialah keputusan, bukan langkah.

Kira percubaan sebelum mencuba lagi. Ambang penguncian desktop mengira log masuk gagal secara berasingan daripada kegagalan VPN, dan klien yang mencuba semula mengikut pemasa boleh melepasi ambang semasa anda masih menyunting peraturan. Itulah mekanisme percubaan semula selari yang sama yang mengunci akaun selepas pertukaran kata laluan.

Apa yang boleh dipindahkan sesi, dan di mana ia tinggal

Pelajari aliran log keluar yang diluluskan sebelum anda memerlukannya. Menutup tetingkap mungkin hanya memutuskan paparan manakala sesi terus berjalan mengikut dasarnya yang dikonfigurasikan, yang penting pada hos yang dikongsi atau diaudit. Log keluar dari dalam sesi apabila dasar menghendakinya.

Kemudian tentukan apa yang boleh dibawa oleh sesi, kerana papan keratan, pemacu yang dialihkan, pengalihan pencetak dan pemindahan fail semuanya memindahkan data antara sistem setempat dan jauh di tempat dasar membenarkannya. Aplikasi terbitan yang berjalan di sebelah sana bukan secara automatik sempadan tanpa muat turun, dan sesi yang kelihatan hanya-baca masih boleh membawa papan keratan. Uji tugas sebenar, bukan sambungan: buka fail, gunakan aplikasi dan sahkan pengalihan yang anda perlukan. Panduan Microsoft untuk mencapai desktop jauh dari luar menerangkan pilihan pendedahan yang disokong, dan ia rujukan yang lebih baik daripada pendengar awam yang ditambah di bawah tekanan.