IPv6 blokuje połączenia zdalne (np. RDP)

IPv6 blokuje połączenia zdalne (np. RDP) wskazuje na niekompletną konfigurację zapory dla tego protokołu — reguły trzeba zdefiniować osobno dla IPv4 i IPv6.

Na czym polega problem z IPv6 przy połączeniach zdalnych

Komunikat lub sytuacja, w której IPv6 blokuje połączenia zdalne, oznacza, że urządzenie próbujące nawiązać sesję może wybierać adres IPv6, lecz zapora, router albo komputer docelowy nie zezwala na ruch przychodzący przez ten protokół. W przypadku usług takich jak RDP nie wystarczy sprawdzenie, czy połączenie działa po IPv4. Oba protokoły mogą być obsługiwane równocześnie, a system operacyjny, mechanizm DNS lub aplikacja może preferować IPv6.

IPv6 nie jest jedynie alternatywnym zapisem adresu IPv4. Ma własne adresowanie, reguły filtrowania, zakresy dostępu i sposób przechodzenia przez urządzenia sieciowe. Dlatego reguła utworzona dla IPv4 nie musi obejmować IPv6. Jeżeli odpowiednie zezwolenie nie zostało skonfigurowane, połączenie może zostać odrzucone, wygasnąć po dłuższym oczekiwaniu albo działać tylko z wybranych sieci.

W praktyce należy rozróżnić kilka sytuacji: całkowity brak łączności IPv6, błędną publikację adresu w DNS, blokadę na zaporze komputera, filtrowanie na routerze oraz ograniczenie wynikające z sieci VPN lub zdalnego dostępu. Sam fakt, że host ma przypisany adres IPv6, nie oznacza jeszcze, że usługa zdalna jest osiągalna z Internetu.

Jak IPv6 zmienia drogę do usługi zdalnej

W typowym połączeniu aplikacja najpierw ustala adres komputera na podstawie nazwy. Jeżeli dla tej nazwy dostępny jest rekord IPv6, klient może podjąć próbę połączenia właśnie tą drogą. Gdy zapora po stronie komputera docelowego nie ma reguły dla IPv6, pakiety mogą nie dotrzeć do usługi, nawet jeśli identyczna próba przez IPv4 kończy się powodzeniem.

W IPv4 często stosuje się translację adresów na routerze, przez co urządzenie w sieci lokalnej nie jest bezpośrednio widoczne z Internetu. IPv6 może zapewniać urządzeniom globalnie routowalne adresy, ale nie zwalnia to z potrzeby stosowania filtrowania. Ochrona może być realizowana na routerze, zaporze systemowej albo obu tych poziomach. Błędnie ustawiona reguła może zezwalać na połączenia z niepożądanego zakresu lub blokować także prawidłowy ruch.

Znaczenie ma również zakres adresu. Adres lokalny dla łącza nie będzie użyteczny z odległej sieci, a adres tymczasowy może zmieniać się zgodnie z ustawieniami prywatności systemu. Przy połączeniach przez nazwę domenową trzeba sprawdzić, czy publikowany adres AAAA wskazuje na właściwy komputer i czy aktualizuje się po zmianie adresu. W środowisku VPN może dodatkowo występować sytuacja, w której IPv4 jest kierowane tunelem, a IPv6 omija tunel albo jest przez niego odrzucane.

Analiza powinna obejmować oba końce połączenia: komputer klienta i komputer udostępniający usługę. Przydatne jest porównanie rozwiązywania nazwy, sprawdzenie trasy IPv6, weryfikacja nasłuchiwania usługi oraz kontrola logów zapory. Test wykonany wyłącznie z jednej sieci nie zawsze pokazuje rzeczywistą przyczynę, ponieważ operator, router i profil sieciowy mogą stosować inne zasady filtrowania.

Typowe przyczyny i objawy blokady - IPv6 blokuje połączenia zdalne (np. RDP)

Jednym z częstych powodów jest utworzenie reguły zapory tylko dla IPv4. Dotyczy to zarówno reguł przychodzących dla usługi zdalnego pulpitu, jak i ograniczeń ustawionych dla konkretnego profilu sieciowego. Reguła może być aktywna w sieci prywatnej, lecz nie działać w profilu publicznym. Zdarza się także, że zezwolenie obejmuje określony zakres adresów, a klient korzysta z innego prefiksu IPv6.

Inną przyczyną bywa filtr na routerze. Niektóre urządzenia traktują ruch IPv6 odmiennie niż IPv4, a po aktualizacji oprogramowania mogą zostać przywrócone domyślne zasady bezpieczeństwa. Problem może też powodować niepoprawna delegacja prefiksu przez operatora, brak trasy zwrotnej albo mechanizm ochronny, który odrzuca pakiety uznane za niepasujące do ustanowionej sesji.

Objawy nie zawsze są jednoznaczne. Połączenie może działać z sieci domowej, ale nie z telefonu lub biura, może łączyć się po ręcznym wpisaniu adresu IPv4, lecz nie po nazwie hosta, albo może być dostępne tylko po wyłączeniu IPv6. Czasami sesja rozpoczyna się poprawnie, ale po pewnym czasie zostaje przerwana z powodu zmiany adresu tymczasowego, utraty trasy lub niezgodności konfiguracji VPN.

Nie należy rozwiązywać problemu przez trwałe wyłączanie IPv6 bez wcześniejszego ustalenia źródła usterki. Takie działanie może ukryć błąd w zaporze lub DNS, a także wpłynąć na inne usługi sieciowe. Bezpieczniejsze jest porównanie reguł dla IPv4 i IPv6, zawężenie do właściwego źródła, sprawdzenie profilu sieci oraz potwierdzenie, że usługa rzeczywiście nasłuchuje na odpowiednim interfejsie.

W jakich sytuacjach warto skorzystać z pomocy serwisu - IPv6 blokuje połączenia zdalne (np. RDP)

Zgłoszenie do serwisu jest uzasadnione, gdy połączenia zdalne przestały działać po zmianie routera, aktualizacji systemu, konfiguracji VPN albo przełączeniu operatora na IPv6. Warto skorzystać z pomocy także wtedy, gdy RDP działa po IPv4, lecz zawodzi przy użyciu nazwy hosta, gdy problem występuje tylko spoza sieci lokalnej lub gdy logi zapory wskazują odrzucenia, których nie da się powiązać z konkretną regułą.

W ramach diagnostyki można ustalić, czy błąd powstaje podczas rozwiązywania nazwy, routingu, filtrowania na routerze, ochrony systemowej czy uruchamiania samej usługi zdalnej. Sprawdzeniu podlegają między innymi rekordy DNS, adresy przypisane do interfejsów, profil sieci, reguły zapory dla obu protokołów, zakresy dozwolonych adresów oraz wpływ tunelu VPN. Wyniki testów z kilku sieci pozwalają odróżnić problem lokalny od ograniczenia po stronie operatora.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić uporządkowanie takiej konfiguracji, gdy potrzebne jest prześledzenie całej ścieżki połączenia i przygotowanie reguł bez osłabiania ochrony komputera. Dla laptopów dostępna jest darmowa diagnoza LAPTOPA, co ułatwia rozpoczęcie sprawdzania ustawień klienta, zapory i dostępu przez VPN.

Po usunięciu przyczyny warto wykonać ponowny test z sieci lokalnej i z zewnętrznego łącza, sprawdzić działanie po nazwie oraz potwierdzić, że reguły pozostają aktywne po restarcie urządzeń. Należy również zachować informację o zastosowanym zakresie adresów i profilu sieciowym, aby przyszłe zmiany routera, DNS lub VPN nie odtworzyły tej samej blokady.