Czy zapora blokuje VPN? Sprawdzenie krok po kroku

Przekroczenie limitu czasu nie wskazuje winnego. Przejdź kolejno przez nasłuch, ścieżkę i dziennik zabezpieczeń, a zmień jedną regułę dopiero wtedy, gdy dowody na nią wskazują.

Jedno przekroczenie limitu czasu VPN dowodzi, że nie dotarła żadna użyteczna odpowiedź, i nie dowodzi niczego o przyczynie. Profil może wskazywać zły port, serwer może być wyłączony, a żądanie może dotrzeć bez działającej drogi powrotnej. Każdy z tych przypadków zostawia inny ślad, a to ślad mówi, której reguły dotknąć. Przejdź przez cztery etapy poniżej po kolei. Zatrzymaj się, gdy tylko jeden z nich wyjaśni objaw.

Etap 1: potwierdź serwer i transport

Czytaj nazwę serwera, transport i port z bieżącego profilu operatora, a nie z lokalnej zmiany. Port zmieniony na twoim laptopie nie może utworzyć nasłuchu na publicznym serwerze, a ta niezgodność daje przekroczenie limitu identyczne z blokadą. Jeśli profil oferuje obsługiwany transport alternatywny, zapisz go jako wariant zapasowy, a nie jako rozwiązanie. Rozwiąż nazwę i porównaj odpowiedź z adresem, który operator opublikował.

Nieaktualny rekord DNS wysyła klienta do hosta, który nigdy nie odpowiedział. To kolejna usterka imitująca filtr, a jej wykluczenie kosztuje jedno zapytanie.

Zapisz obie wartości w zgłoszeniu. Każde późniejsze porównanie ich używa, a zgłoszenie bez nich zaczyna dochodzenie od nowa.

Etap 2: udowodnij ścieżkę jednym kontrolowanym porównaniem

Zostaw urządzenie i profil bez zmian i wypróbuj inną zaufaną sieć dostępową. Jeśli tunel tam wstanie, różnicą jest pierwotna ścieżka lub jej polityka. Jeśli na pierwotnej sieci działa drugie zatwierdzone urządzenie, różnicą jest pierwsze urządzenie. Jedno z tych dwóch porównań jest niemal zawsze rozstrzygające.

Najpierw dokończ każde legalne logowanie sieciowe, bo portal przechwytujący wygląda jak blokada, dopóki nie zostanie ukończony.

Testuj port, którego faktycznie używasz, a wynik TCP traktuj jako informację wyłącznie o TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Udany uścisk dłoni TCP na porcie 443 oznacza, że odpowiedział tam nasłuch. Nie mówi nic o nasłuchu UDP na 51820 ani o tym, czy negocjacja się zakończyła.

Etap 3: odczytaj zdarzenia zabezpieczeń z momentu awarii

Zdarzenia zapory to najsilniejszy dostępny dowód i niosą zastrzeżenie, które warto powiedzieć najpierw. Rejestrowanie jest wyłączone w wielu profilach domyślnych, więc sprawdź, czy dany profil zapisuje odrzucenia, zanim odczytasz pusty dziennik jako dowód niewinności. Gdy rejestrowanie jest włączone, zdarzenie podaje regułę, kierunek i adresy, czyli dokładnie to, czego potrzebuje zmiana reguły. Reguły aplikacji i reguły portów to osobne obiekty, a polityka zarządzana może nadpisać ustawienie lokalne. Potwierdź, którego klienta i którą usługę reguła faktycznie obejmuje.

Zbieraj stan profilu i ostatnie zdarzenia z maszyny, która zawiodła, a nie z sąsiedniego hosta.

Porównaj czas zdarzenia z czasem twojej próby testowej, bo pasująca nazwa reguły z innym znacznikiem czasu to zbieg okoliczności.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

Na serwerze, którym administrujesz, zapytaj, czy żądanie w ogóle dotarło do nasłuchu. Pakiet, który przychodzi bez odpowiedzi, to problem przekazywania lub trasy powrotnej. Żądanie, które nigdy się nie pojawia, to problem filtrowania lub adresowania.

Etap 4: sprawdź przekazywanie po podniesieniu tunelu

Zapora może zezwolić na sesję i nadal odmówić wszystkiego, do czego sesja chce dotrzeć. Sysctl przekazywania, reguły NAT i trasy powrotne stoją po uwierzytelnieniu, a szerokie wyłączenie dla portu VPN nie naprawia żadnego z nich. Testuj osobno jeden cel wewnętrzny i jeden cel internetowy, bo zwykle zawodzą z różnych powodów. Jeśli nazwy wewnętrzne zawodzą, a adresy działają, zajrzyj do wypchniętego DNS przed jakąkolwiek regułą.

Uruchom trzy kontrole poniżej na serwerze, gdy klient jest połączony i próbuje zawodzącego żądania.

Liczniki interfejsu tunelu są tu kluczowe, bo pokazują, czy pakiety weszły i czy coś wyszło.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Gdy pakiety docierają do tunelu i nic nie wychodzi w stronę celu, podejrzanym jest przekazywanie lub NAT. Gdy nic nie dociera, sesja stoi, ale klient nie wysyła, a miejscem do zajrzenia jest tablica tras klienta.

Sprawdź poprawkę i usuń to, co nie pomogło

Po zatwierdzonej poprawce powtórz dokładnie ten test, który zawiódł, i zapisz wynik wobec tego samego profilu i urządzenia. Następnie usuń każde tymczasowe wyłączenie, które nie zmieniło wyniku, bo nieużywane wyłączenia się kumulują, a każde z nich to decyzja, której nikt nie pamięta. To, co zostaje, trzymaj wąsko: jeden cel, jeden port, jeden kierunek, jeden właściciel.

Uruchom ponownie te same trzy polecenia i porównaj je z danymi wyjściowymi zapisanymi przed zmianą.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Gdy sieć porównawcza działa, pierwotna sieć nadal zawodzi, a zdarzenia pozostają puste, pozostałym podejrzanym jest ścieżka, a nie host. Przekaż to właścicielowi sieci jako konkretne stwierdzenie, z oboma wynikami porównania w załączniku. To lepsze miejsce na zatrzymanie niż wyłączony profil zapory.

Powiązane artykuły