Nie działa RDP przez VPN

Niedziałające RDP przez VPN wskazuje na zablokowany port 3389 w tunelu VPN lub błędne trasowanie ruchu do podsieci docelowej.

Co oznacza brak połączenia RDP przez tunel VPN

Komunikat „Nie działa RDP przez VPN” oznacza, że komputer kliencki nie może ustanowić sesji Remote Desktop Protocol z komputerem docelowym po zestawieniu wirtualnej sieci prywatnej. Sam fakt, że tunel VPN jest oznaczony jako połączony, nie potwierdza jeszcze poprawnego dostępu do wszystkich podsieci. VPN może uwierzytelniać użytkownika i szyfrować ruch, ale jednocześnie nie przekazywać pakietów do sieci, w której znajduje się komputer zdalny.

Najczęstszą przyczyną jest brak przejścia ruchu do adresu docelowego albo filtrowanie portu używanego przez usługę pulpitu zdalnego. RDP standardowo korzysta z portu TCP 3389. Nowsze wersje klienta i usługi RDP mogą także wykorzystywać transport UDP na porcie 3389, jednak podstawowe zestawienie sesji nadal wymaga poprawnej komunikacji TCP. Zablokowanie portu, nieprawidłowa reguła zapory lub brak trasy do podsieci mogą powodować podobny objaw.

Trasa, adres i rozwiązywanie nazwy komputera

W pierwszej kolejności należy ustalić, czy połączenie jest kierowane do właściwego adresu. Nazwa komputera używana w kliencie Pulpit zdalny może być rozwiązywana przez DNS dostępny wyłącznie wewnątrz sieci firmowej. Jeżeli VPN nie przekazuje zapytań do odpowiedniego serwera DNS, nazwa może wskazywać na nieprawidłowy adres, nie być rozpoznawana albo rozwiązać się na adres publiczny zamiast prywatnego. Testowanie połączenia po nazwie i po znanym adresie IP pomaga rozdzielić problem DNS od problemu routingu lub zapory.

W systemie Windows bieżące trasy można sprawdzić poleceniem route print, a konfigurację interfejsów poleceniem ipconfig /all. W tabeli routingu powinna znajdować się trasa obejmująca adres komputera zdalnego albo całą jego podsieć. Przy konfiguracji split tunneling część ruchu pozostaje kierowana bezpośrednio przez lokalne połączenie internetowe, a tylko wybrane zakresy adresów przechodzą przez VPN. Jeżeli podsieć z komputerem docelowym nie została objęta regułą tunelu, klient RDP będzie próbował korzystać z niewłaściwej bramy.

Sprawdzenie portu 3389 i mechanizmu uwierzytelniania

Dostępność usługi można zweryfikować z komputera podłączonego do VPN za pomocą polecenia Test-NetConnection -ComputerName adres-komputera -Port 3389. Wynik z wartością TcpTestSucceeded : False wskazuje, że połączenie TCP do wskazanego adresu i portu nie zostało ustanowione. Nie określa jednak samodzielnie, czy przyczyną jest zapora na komputerze docelowym, filtr VPN, brak trasy, wyłączona usługa RDP czy urządzenie pośrednie odrzucające ruch.

Na komputerze docelowym należy sprawdzić, czy Pulpit zdalny jest włączony, czy system nasłuchuje na właściwym porcie oraz czy reguły Zapory systemu Windows zezwalają na połączenia z zakresu adresów używanego przez VPN. Jeżeli port RDP został zmieniony, testowanie portu 3389 będzie błędne i trzeba użyć rzeczywistego numeru portu. Dodatkową przeszkodą może być uwierzytelnianie na poziomie sieci, czyli Network Level Authentication. NLA wymaga poprawnego uwierzytelnienia jeszcze przed utworzeniem pełnej sesji pulpitu, dlatego błędne dane, niezgodność domeny, ograniczenia konta lub problem z dostępem do kontrolera domeny mogą wyglądać jak awaria samego RDP.

Diagnostyka warstwy VPN i przywrócenie sesji

Jeżeli adres jest prawidłowy, trasa istnieje, a port 3389 pozostaje niedostępny, trzeba przeanalizować reguły dostępu na koncentratorze lub bramie VPN. W konfiguracji mogą występować listy kontroli dostępu ograniczające ruch między klientami VPN a wybranymi podsieciami. Może być również wymagane zezwolenie na ruch do konkretnego hosta, segmentu sieci albo portu TCP 3389. Samo zestawienie tunelu nie oznacza automatycznie pełnego dostępu do sieci wewnętrznej.

Warto porównać zachowanie połączenia z kilku punktów: po adresie IP, po nazwie DNS, z innym profilem VPN oraz z innym komputerem w tej samej podsieci. Polecenie tracert adres-komputera może pomóc wykryć kierowanie ruchu przez niewłaściwą bramę, choć brak odpowiedzi na poszczególnych etapach nie zawsze oznacza awarię, ponieważ urządzenia sieciowe często filtrują komunikaty diagnostyczne. Przy dużym narzucie szyfrowania VPN znaczenie może mieć także MTU. Zbyt duże pakiety mogą być fragmentowane lub odrzucane, co czasem powoduje częściowe działanie połączenia, na przykład możliwość rozwiązania nazwy przy jednoczesnym zawieszaniu logowania RDP. Po usunięciu błędnej trasy, reguły zapory albo ustawienia profilu VPN należy ponownie sprawdzić port TCP 3389 i dopiero potem uruchomić klienta Pulpit zdalny.