Gdy zdalny pulpit Windows nagle przestaje łączyć się z serwerem, pierwszym podejrzanym bywa port, na którym nasłuchuje usługa RDP. W tym artykule pokazuję, że domyślny port 3389 to dopiero początek: sprawdzimy TCP i UDP, konfigurację zapory, zmianę numeru, testowanie połączenia, Azure oraz bezpieczny dostęp spoza sieci.
Port 3389 działa poprawnie tylko wtedy, gdy usługa, zapora i sieć są zgodnie skonfigurowane
- 3389/TCP i 3389/UDP to standardowe porty używane przez Remote Desktop.
- Test-NetConnection sprawdza połączenie TCP, ale nie potwierdza działania transportu UDP.
- Zmiana numeru portu wymaga aktualizacji rejestru, Windows Firewall, NAT-u i reguł NSG w Azure.
- Ukrycie usługi na innym porcie ogranicza przypadkowe skany, lecz nie zastępuje VPN, MFA ani ograniczenia adresów IP.
- Przy połączeniu używaj składni mstsc /v:serwer:port, jeśli RDP działa na niestandardowym numerze.
Jaki port wykorzystuje zdalny pulpit Windows
Domyślnie Remote Desktop nasłuchuje na porcie 3389. W praktyce wykorzystywane są dwa transporty: TCP 3389 oraz UDP 3389. TCP odpowiada za niezawodne zestawienie połączenia, a UDP może poprawić płynność sesji przy przesyłaniu obrazu, dźwięku i interakcji z pulpitem.
Najważniejsze jest rozróżnienie portu docelowego i źródłowego. Komputer zdalny, czyli host Windows lub Windows Server, nasłuchuje na 3389. Komputer, z którego uruchamiasz klienta RDP, zwykle korzysta z tymczasowego portu źródłowego przydzielanego przez system.
| Element połączenia | Typowy port | Znaczenie |
|---|---|---|
| Host RDP | TCP 3389 | Podstawowe zestawienie sesji zdalnego pulpitu |
| Host RDP | UDP 3389 | Opcjonalny transport poprawiający responsywność |
| Klient RDP | Port dynamiczny | Port źródłowy wybierany przez system kliencki |
| Router lub NAT | Zależny od konfiguracji | Przekierowanie ruchu z sieci zewnętrznej do hosta |
Jeżeli otworzysz wyłącznie TCP, połączenie często nadal będzie działać, ale sesja może zachowywać się gorzej przy słabszej sieci. Z kolei brak TCP 3389 zwykle oznacza całkowity brak możliwości zestawienia standardowego połączenia.
Jak sprawdzić, czy usługa nasłuchuje na właściwym porcie
Najpierw sprawdzam konfigurację na komputerze docelowym. Samo włączenie Pulpitu zdalnego nie gwarantuje, że usługa faktycznie nasłuchuje, a tym bardziej że ruch przepuszcza zapora.
Kontrola nasłuchiwania w PowerShell
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetUDPEndpoint -LocalPort 3389Pierwsze polecenie powinno zwrócić aktywne nasłuchiwanie TCP. Drugie pozwala sprawdzić obecność punktu UDP. Jeśli nie ma żadnego wyniku, sprawdź, czy działa usługa Remote Desktop Services oraz czy zdalne połączenia są włączone w ustawieniach systemu.
Get-Service -Name TermService
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnectionsWartość fDenyTSConnections ustawiona na 0 oznacza, że połączenia RDP nie są globalnie wyłączone. Zmiana tej wartości na własną rękę nie zawsze jest konieczna, ponieważ konfigurację można bezpieczniej kontrolować przez ustawienia systemowe lub zasady grupy.
Test z komputera klienckiego
Test-NetConnection -ComputerName serwer-firmowy -Port 3389 -InformationLevel DetailedWynik TcpTestSucceeded: True potwierdza, że klient może nawiązać połączenie TCP z podanym hostem i portem. Nie jest to jednak pełny test sesji RDP. Polecenie nie sprawdza poprawności konta, zasad NLA, certyfikatu ani transportu UDP.
Przy niestandardowym numerze uruchamiam klienta wprost z parametrem portu:
mstsc /v:serwer-firmowy:3390Jeżeli test TCP kończy się niepowodzeniem, sprawdzam kolejno DNS, trasę sieciową, lokalną zaporę Windows, zaporę pośrednią, przekierowanie NAT oraz reguły zabezpieczeń w chmurze. Takie podejście jest szybsze niż przypadkowe wyłączanie zabezpieczeń.
Jak zmienić port RDP w Windows
Zmiana portu może mieć sens, gdy chcę ograniczyć liczbę automatycznych skanów kierowanych na standardowy numer. Nie traktuję jej jednak jako samodzielnego zabezpieczenia. Przed rozpoczęciem pracy wykonuję kopię konfiguracji i upewniam się, że mam alternatywny dostęp do serwera, na przykład przez konsolę dostawcy chmurowego.
Zmiana wartości w rejestrze
Numer portu znajduje się w wartości PortNumber w kluczu konfiguracji RDP:
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-TcpPrzykładowa zmiana na port 3390 w PowerShellu wygląda tak:
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name PortNumber `
-Value 3390W Edytorze rejestru należy zwrócić uwagę, aby wartość była zapisana jako DWORD. Przy ręcznej edycji łatwo pomylić zapis dziesiętny z szesnastkowym, dlatego w praktyce wolę użyć PowerShella albo dokładnie sprawdzić wybraną podstawę liczbową.
Przeczytaj również: Aktualizacja WSL bez błędów. Polecenia i bezpieczny backup
Reguły Windows Defender Firewall
Nowy port trzeba dopuścić w zaporze. Robię to przed przełączeniem usługi, żeby nie odciąć sobie dostępu:
New-NetFirewallRule `
-DisplayName "RDP TCP 3390" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 3390 `
-Action Allow `
-Profile Domain,Private
New-NetFirewallRule `
-DisplayName "RDP UDP 3390" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 3390 `
-Action Allow `
-Profile Domain,PrivateW środowisku produkcyjnym ograniczam regułę do konkretnych adresów lub podsieci. Otwieranie portu na wszystkich profilach i dla dowolnego źródła jest wygodne podczas testu, ale zwykle jest zbyt szerokie na stałe.
Po zmianie konfiguracji trzeba ponownie uruchomić usługę lub cały komputer. Restart usługi może rozłączyć aktywne sesje, dlatego wykonuję go w uzgodnionym oknie serwisowym:
Restart-Service -Name TermService -ForceNastępnie sprawdzam nasłuchiwanie i testuję połączenie z nowym numerem. Jeśli port 3390 jest już zajęty przez inną aplikację, RDP nie uruchomi się prawidłowo. Można to zweryfikować poleceniem:
Get-NetTCPConnection -LocalPort 3390 -ErrorAction SilentlyContinueCo trzeba zmienić poza komputerem z Windows
Najczęstszy błąd polega na zmianie portu wyłącznie w rejestrze. Ruch RDP przechodzi często przez kilka warstw, a każda z nich musi znać nowy numer. Dotyczy to szczególnie serwerów działających w Azure, za routerem NAT albo za firmową zaporą sieciową.
| Miejsce | Co sprawdzić | Typowy problem |
|---|---|---|
| Windows Firewall | Reguły TCP i UDP dla nowego portu | Usługa nasłuchuje, ale zapora odrzuca ruch |
| Router NAT | Przekierowanie portu zewnętrznego na adres hosta | Router nadal kieruje ruch na 3389 |
| Azure NSG | Reguła inbound dla nowego portu | Sieciowa grupa zabezpieczeń blokuje połączenie przed dotarciem do VM |
| Zapora firmowa | Reguły pomiędzy klientem a serwerem | Ruch jest blokowany po drodze |
| Klient RDP | Adres w formacie host:port | Klient próbuje połączyć się nadal z 3389 |
W przypadku maszyny wirtualnej Azure sprawdzam jednocześnie reguły NSG i zaporę wewnątrz systemu. Otwarcie portu w NSG nie wystarczy, jeżeli Windows blokuje go lokalnie. Działa to także w drugą stronę.
Przy dostępie przez router składnia przekierowania powinna jasno wskazywać, czy zmieniam port zewnętrzny, wewnętrzny, czy oba. Na przykład ruch przychodzący na 3390 może być przekierowany do adresu prywatnego serwera na 3390, ale nie jest to jedyna możliwa konfiguracja.
Czy zmiana numeru poprawia bezpieczeństwo
Zmiana domyślnego portu ogranicza część automatycznych skanów, ponieważ wiele botów sprawdza najpierw popularny numer 3389. To jednak tylko utrudnienie rozpoznania usługi, a nie realna ochrona przed ukierunkowanym atakiem. Skanery potrafią sprawdzić cały zakres portów, a po wykryciu RDP numer przestaje mieć znaczenie.
Jeśli mam wpływ na architekturę, nie wystawiam pulpitu zdalnego bezpośrednio do internetu. Preferuję VPN, RD Gateway, Azure Bastion albo dostęp ograniczony do zaufanych adresów IP. Do tego dochodzą silne hasła, uwierzytelnianie wieloskładnikowe, Network Level Authentication, aktualizacje oraz monitoring nieudanych logowań.
W małej sieci domowej zmiana numeru może być dodatkową warstwą porządkową, ale nie powinna zastępować zapory. Na serwerze firmowym bardziej liczy się ograniczenie źródeł ruchu i dostęp przez kontrolowany punkt wejścia niż wybór „mniej oczywistego” numeru.
Unikam także wystawiania RDP na szeroki zakres adresów, nawet jeśli używam niestandardowego portu. Najlepszy efekt daje połączenie kilku mechanizmów: brak publicznego dostępu, VPN lub brama, MFA, aktualny system i rejestrowanie zdarzeń.
Dlaczego połączenie nadal nie działa
Jeżeli port odpowiada, ale klient RDP pokazuje błąd logowania lub rozłącza sesję, problem może nie dotyczyć sieci. Sprawdzam wtedy uprawnienia użytkownika, politykę NLA, licencjonowanie w Windows Server, limit sesji oraz to, czy konto nie jest zablokowane.
Gdy port nie odpowiada, najczęściej winna jest jedna z czterech rzeczy: zły adres hosta, brak reguły w zaporze, błędne przekierowanie NAT albo nieaktualna reguła NSG. Pomocne jest testowanie z różnych punktów sieci, ponieważ test wykonany bezpośrednio na serwerze nie pokazuje, czy ruch przechodzi przez router lub firewall.
- Połączenie działa lokalnie, ale nie z internetu - sprawdź NAT, publiczny adres i zaporę brzegową.
- TCP odpowiada, ale sesja szybko się rozłącza - sprawdź UDP, jakość łącza, polityki RDP i obciążenie serwera.
- Po zmianie portu nie działa nic - wróć do konsoli awaryjnej i zweryfikuj rejestr, usługę oraz reguły zapory.
- Klient zgłasza błąd połączenia z nazwą hosta - przetestuj adres IP, aby oddzielić problem DNS od problemu RDP.
Nie wyłączam całkowicie Windows Firewall „na próbę”, chyba że robię to na izolowanym środowisku testowym i tylko na chwilę. Lepsza diagnostyka polega na sprawdzeniu konkretnej reguły oraz logów odrzuconych połączeń.
Port 3389 to początek konfiguracji, nie jej najważniejszy element
W typowej instalacji wystarczy zapamiętać, że RDP korzysta z TCP i UDP 3389, ale prawidłowe działanie zależy również od usługi systemowej, Windows Firewall, sieci pośredniej oraz ustawień klienta. Zmiana portu na 3390 lub inny dostępny numer jest możliwa, lecz wymaga konsekwentnej aktualizacji każdej warstwy.
Moje praktyczne podejście jest proste: najpierw potwierdzam nasłuchiwanie, potem testuję TCP, sprawdzam zapory i dopiero na końcu analizuję logowanie. Jeśli serwer ma być dostępny spoza sieci, inwestuję przede wszystkim w VPN, MFA i ograniczenie źródeł ruchu, bo te mechanizmy chronią znacznie skuteczniej niż sama zmiana numeru portu.
