RDP działający tylko przez IPv6 wskazuje na problem z rozpoznawaniem lub trasowaniem adresów IPv4 na docelowym komputerze.
Co oznacza połączenie RDP dostępne tylko przez IPv6
RDP, czyli Remote Desktop Protocol, jest protokołem używanym przez Pulpit zdalny systemu Windows do przesyłania obrazu sesji, dźwięku, klawiatury i myszy między klientem a komputerem docelowym. Domyślnie usługa Pulpit zdalny nasłuchuje na porcie TCP 3389. W nowszych konfiguracjach system może również wykorzystywać transport UDP, jednak podstawowe zestawienie połączenia nadal wymaga prawidłowej komunikacji z usługą RDP. Jeżeli połączenie udaje się wyłącznie przez adres IPv6, a próba użycia adresu IPv4 kończy się błędem, oznacza to różnicę w działaniu obu ścieżek sieciowych, a nie odmienny tryb pracy samego pulpitu zdalnego.
Przyczyną może być brak poprawnego adresu IPv4 na komputerze docelowym, nieprawidłowa brama domyślna, trasa do sieci lokalnej albo filtr blokujący port 3389 dla IPv4. Możliwa jest także sytuacja odwrotna: usługa RDP działa, lecz klient korzysta z nazwy hosta, która otrzymuje z DNS rekord AAAA z adresem IPv6 i rekord A z adresem IPv4, a system wybiera trasę IPv6 jako działającą. Sam fakt, że IPv6 działa, nie potwierdza poprawności konfiguracji IPv4. Wymaga ona osobnego sprawdzenia adresacji, routingu, zapory oraz nasłuchiwania usługi.
Rozdzielenie problemu DNS od problemu z trasą IPv4
Pierwszym etapem diagnostyki jest ustalenie, czy klient łączy się z właściwym komputerem. Nazwa urządzenia może rozwiązywać się jednocześnie do adresu IPv4 i IPv6. Polecenie nslookup nazwa-komputera pozwala sprawdzić odpowiedzi DNS, w tym rekord A dla IPv4 oraz rekord AAAA dla IPv6. W sieci lokalnej wynik może pochodzić także z lokalnego DNS, usługi rozpoznawania nazw systemu Windows albo mechanizmu mDNS. Jeżeli rekord A jest nieaktualny, wskazuje dawny adres lub nie występuje, klient może próbować połączenia z innym adresem niż oczekiwany.
Do rozdzielenia obu protokołów można użyć poleceń ping -4 nazwa-komputera i ping -6 nazwa-komputera. Brak odpowiedzi ICMP nie przesądza jeszcze o awarii RDP, ponieważ zapora systemu Windows może blokować echo, podczas gdy port TCP 3389 pozostaje dostępny. Bardziej miarodajny jest test portu: Test-NetConnection -ComputerName adres_ipv4 -Port 3389. Warto wykonać go także dla adresu IPv6. Pole TcpTestSucceeded pokazuje, czy z danego komputera można zestawić połączenie TCP z określonym portem. Jeżeli test IPv6 kończy się powodzeniem, a IPv4 nie, należy sprawdzać adres IPv4, trasę i reguły zapory, zamiast zmieniać ustawienia samego klienta RDP.
Adresacja, nasłuchiwanie i reguły zapory w Windows
Na komputerze docelowym należy sprawdzić wynik polecenia ipconfig /all. Istotne są adres IPv4, maska podsieci, brama domyślna oraz serwery DNS. Adres zaczynający się od 169.254. oznacza zwykle automatyczną adresację lokalną APIPA i nie zapewnia prawidłowej komunikacji przez typową sieć z routerem. W przypadku stałej konfiguracji błędna maska może sprawić, że komputer uzna host z tej samej sieci za lokalny albo spróbuje wysłać ruch przez niewłaściwą bramę. Przy adresacji automatycznej problem może wynikać z niedostępnego serwera DHCP, konfliktu adresów lub nieprawidłowej konfiguracji karty sieciowej.
Następnie trzeba potwierdzić, czy usługa RDP nasłuchuje na IPv4. Polecenie netstat -ano | findstr :3389 wyświetla lokalne gniazda związane z portem 3389, a kolumna PID pozwala powiązać wynik z procesem. Wpis 0.0.0.0:3389 wskazuje nasłuchiwanie na wszystkich lokalnych adresach IPv4, natomiast konkretny adres oznacza ograniczenie do wybranego interfejsu. Reguły zapory można przejrzeć poleceniem Get-NetFirewallRule, filtrując reguły dotyczące Pulpitu zdalnego. Reguła może zezwalać na ruch IPv6, ale blokować IPv4, mieć ograniczony profil sieciowy albo dopuszczać połączenia tylko z określonego zakresu adresów. Należy również sprawdzić, czy sieć jest oznaczona jako prywatna lub domenowa, ponieważ profil publiczny zwykle stosuje bardziej restrykcyjne zasady zapory.
Praktyczna naprawa po ustaleniu przyczyny
Jeżeli test wykazuje brak łączności IPv4, naprawa powinna rozpocząć się od przywrócenia prawidłowej konfiguracji karty sieciowej i trasy, a nie od wyłączania IPv6. Można odnowić dzierżawę DHCP poleceniami ipconfig /release oraz ipconfig /renew, a następnie ponownie sprawdzić wynik ipconfig /all. Gdy problem dotyczy rozwiązywania nazwy, należy poprawić rekord A albo użyć właściwego adresu IPv4 do testu. Jeśli port 3389 jest dostępny lokalnie, lecz niedostępny z innego komputera, trzeba przeanalizować zaporę Windows oraz urządzenia sieciowe znajdujące się pomiędzy klientem i hostem RDP. Nie należy otwierać portu do Internetu bez jednoznacznej potrzeby i prawidłowego zabezpieczenia dostępu.
Gdy usługa nie nasłuchuje na IPv4, należy sprawdzić włączenie Pulpitu zdalnego, stan usługi Usługi pulpitu zdalnego oraz ustawienia systemowe ograniczające połączenia. Po każdej zmianie trzeba powtórzyć test Test-NetConnection dla adresu IPv4 i dopiero potem uruchomić klienta mstsc.exe. Jeżeli objaw występuje tylko przy nazwie komputera, połączenie bezpośrednio z adresem IPv4 może potwierdzić błąd DNS. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, w tym diagnostyką problemów z konfiguracją sieciową wpływających na dostęp do pulpitu zdalnego.
