Pulpit zdalny przez VPN: w którym błędzie jesteś?

Twój tunel działa, wewnętrzna wiki się ładuje, a pulpit zdalny nadal odmawia połączenia. Ta kombinacja jest normalna, bo VPN zapewnia trasę do hosta, podczas gdy usługa pulpitu musi nasłuchiwać, być dozwolona przez własną zaporę i gotowa uwierzytelnić konto. Między działającym tunelem a użyteczną sesją leżą cztery etapy awarii i każdy kończy się innym komunikatem. Najpierw przeczytaj komunikat, bo nazywa etap.

Cztery awarie, które wyglądają jak jedna

Etapy są uporządkowane: nazwa rozwiązuje się na prywatny adres, który przewiduje projekt, port odpowiada na uzgadnianie TCP, host akceptuje połączenie zgodnie z własną polityką, a logowanie do sesji się udaje. Każdy etap czyni następny niemożliwym do sprawdzenia, dlatego zmiana ustawień RDP przed uporządkowaniem sieci daje tylko szum. Objaw wygląda identycznie z perspektywy użytkownika w każdym z czterech przypadków. Rozdziela je tylko komunikat klienta.

Działająca wewnętrzna strona nie dowodzi żadnej z czterech rzeczy. Dowodzi, że host w tej samej sieci odpowiedział na innym porcie inną usługą. Traktuj to jako dowód o routingu i nic więcej.

Testuj po kolei i zapisz wynik. Przeskoczenie do ekranu logowania, bo port odpowiedział, to sposób na spędzenie popołudnia nad problemem zapory, który pierwszy krok już zlokalizował.

Czy coś nasłuchuje na 3389?

Zacznij od nazwy, bo nazwa rozwiązująca się na zły adres unieważnia każdy późniejszy test. Zapytaj resolver tunelu, co oznacza nazwa, a potem porównaj odpowiedź z prywatnym adresem, który przewiduje projekt, a nie z udaną odpowiedzią. Nazwa rozwiązująca się na adres publiczny to cały problem i żadna zmiana RDP go nie naprawi:

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

Potem testuj port, a nie host. Zakończone uzgadnianie TCP na 3389 oddziela osiągalność od wszystkiego powyżej:

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

Wykonaj ten test z sieci LAN i z tunelu, bo różnica między oboma wynikami lokalizuje usterkę na ścieżce VPN. Na ścieżce stoją dwie zapory i łatwo je pomylić: sieć musi zezwalać adresowi tunelu klienta na dotarcie do hosta, a własna zapora hosta musi zezwalać temu samemu źródłu na porcie nasłuchującym. Reguła ograniczona do podsieci LAN nie obejmuje puli klientów VPN i to jest najczęstsza przyczyna przekroczenia czasu, o którym zgłaszają tylko użytkownicy zdalni. Sprawdź zasięg, a nie istnienie reguły.

Ścieżka powrotna zasługuje na tę samą kontrolę. Odpowiedzi potrzebują trasy z powrotem do puli klientów, a nie do sieci LAN, a tłumaczenie przed hostem zmienia źródło, które pokaże twój log. Jeśli port odpowiada w jedną stronę, a w drugą nie, brakującą połową jest zwykle ścieżka powrotna.

Przeczytaj komunikat, zanim przeczytasz konfigurację

Trzeci etap to host odrzucający połączenie zgodnie z własną polityką, co często wygląda jak port, który natychmiast się otwiera i zamyka. Coś odpowiedziało, a to jest użyteczna informacja, nie cisza. Jeśli uzgadnianie się zakończyło, a sesja natychmiast umarła, sieć jest w porządku i decyduje host. Sprawdź uprawnienia pulpitu zdalnego, zanim znowu dotkniesz sieci.

Funkcja może być włączona dla maszyny, podczas gdy dostęp jest ograniczony do określonych grup, a nasłuch może być powiązany w sposób wykluczający adres, z którego przyszedłeś. Uwierzytelnianie na poziomie sieci dodaje bramę, która zawodzi przed wczytaniem pulpitu, a jej tekst błędu różni się od błędnego hasła. Porównaj komunikat klienta z dziennikiem zdarzeń hosta, bo komunikat nazywa bramę, a dziennik konto.

Logowanie do sesji to własna granica

Uwierzytelnianie należy do usługi pulpitu, a nie do VPN. Tożsamość tunelu i konto pulpitu to odrębne dane uwierzytelniające z odrębnymi zasadami blokady, więc działający tunel dowodzi tylko, że tunel cię przyjął. Zablokowanie konta pulpitu nie zakłóca tunelu i odwrotnie też jest prawdą.

Zachowaj oba nietknięte. Gdy brakuje trasy prywatnej, napraw trasę, bo publikowanie nasłuchu w internecie zamienia błąd osiągalności na wystawiony pulpit. Nie osłabiaj też kontroli tożsamości sesji, aby przejść obok ostrzeżenia o certyfikacie, które pojawiło się jednocześnie. Samopodpisany certyfikat na nasłuchu RDP z założenia daje ostrzeżenie, więc jego akceptacja jest decyzją, a nie krokiem.

Policz próby, zanim spróbujesz ponownie. Progi blokady pulpitu liczą nieudane logowania oddzielnie od awarii VPN, a klient, który ponawia według timera, może przekroczyć próg, gdy jeszcze edytujesz regułę. To ten sam mechanizm równoległych ponowień, który blokuje konta po zmianie hasła.

Co sesja może przenosić i gdzie to zostaje

Naucz się zatwierdzonego przepływu wylogowania, zanim będzie potrzebny. Zamknięcie okna może tylko odłączyć widok, podczas gdy sesja nadal działa zgodnie ze skonfigurowaną polityką, co ma znaczenie na współdzielonym lub audytowanym hoście. Wyloguj się od wewnątrz sesji, gdy polityka tego oczekuje.

Potem zdecyduj, co sesja może przenosić, bo schowek, przekierowane dyski, przekierowanie drukarki i przesyłanie plików przenoszą dane między systemem lokalnym a zdalnym tam, gdzie polityka na to pozwala. Opublikowana aplikacja działająca po drugiej stronie nie jest automatycznie granicą bez pobierania, a sesja wyglądająca na tylko do odczytu może nadal przenosić schowek. Testuj rzeczywiste zadanie, a nie połączenie: otwórz plik, użyj aplikacji i potwierdź potrzebne przekierowanie. Wskazówki Microsoftu dotyczące dostępu do pulpitu zdalnego z zewnątrz opisują obsługiwane opcje ekspozycji i są lepszym źródłem niż publiczny nasłuch dodany pod presją.