Połączenie z udziałem nie działa przez VPN

Połączenie z udziałem niedziałające przez VPN wskazuje na brak trasy do podsieci lokalnej udziału w konfiguracji tunelu VPN.

Dlaczego udział sieciowy przestaje być dostępny po zestawieniu VPN

Połączenie z udziałem sieciowym przez VPN wymaga czegoś więcej niż samego poprawnego zalogowania do tunelu. Komputer musi otrzymać trasę prowadzącą do podsieci, w której znajduje się serwer plików lub komputer udostępniający zasób. Jeżeli tunel obejmuje wyłącznie ruch do określonych adresów, a podsieć lokalna udziału nie została do niego dodana, system może nadal próbować kierować pakiety przez zwykłą kartę sieciową. W takiej sytuacji VPN jest aktywny, lecz adres udziału pozostaje nieosiągalny.

Przykładowo, udział zapisany jako \\192.168.10.20\dokumenty wymaga trasy do sieci 192.168.10.0/24, jeżeli serwer ma adres 192.168.10.20. Gdy klient VPN otrzymuje trasę tylko do sieci 10.8.0.0/24, pakiety przeznaczone dla 192.168.10.20 nie trafią do właściwego interfejsu tunelowego. Podobny efekt może wystąpić przy konflikcie adresacji, gdy sieć lokalna klienta i sieć po drugiej stronie VPN używają tego samego zakresu, na przykład 192.168.1.0/24. System nie ma wtedy jednoznacznej podstawy do wyboru odpowiedniej drogi.

Trasa, DNS i adres używany przez udział

Najpierw należy ustalić, czy problem dotyczy routingu, rozwiązywania nazwy, czy samego dostępu do usługi plikowej. Udział może być otwierany przez nazwę, na przykład \\serwer-biuro\projekty, albo przez adres IP. Jeżeli dostęp po adresie IP działa, a po nazwie nie, prawdopodobną przyczyną jest brak dostępu do firmowego DNS, błędny suffix DNS albo nieprawidłowa odpowiedź z lokalnego serwera nazw. Jeżeli nie działa także adres IP, należy sprawdzić trasę, zaporę i dostępność portu usługi.

W systemie Windows podstawowe informacje można zebrać poleceniami ipconfig /all oraz route print. Pierwsze pokazuje adresy interfejsów, bramy i serwery DNS, a drugie pozwala sprawdzić, czy istnieje wpis kierujący ruch do podsieci udziału przez interfejs VPN. Do sprawdzenia rozwiązywania nazwy można użyć nslookup serwer-biuro. Test Test-NetConnection 192.168.10.20 -Port 445 wskazuje, czy z bieżącej konfiguracji można nawiązać połączenie TCP z portem używanym przez SMB. Wynik testu nie potwierdza jeszcze uprawnień do konkretnego katalogu, ale pomaga oddzielić problem transportowy od problemu uwierzytelniania.

W konfiguracji VPN spotyka się tunel pełny oraz tunel dzielony. W tunelu pełnym cały ruch może być kierowany przez VPN, natomiast w tunelu dzielonym tylko wybrane sieci są przesyłane przez bramę VPN. Przy tunelu dzielonym konieczne jest dodanie właściwej podsieci udziału, a czasem także osobnych tras do kilku segmentów sieci. Sama zmiana domyślnej bramy nie zawsze rozwiązuje problem, ponieważ serwer VPN może wymagać reguły routingu również po swojej stronie.

SMB, zapora i ograniczenia połączenia

Udziały plikowe systemu Windows są zwykle udostępniane przez SMB. Współczesne połączenia SMB korzystają przede wszystkim z TCP na porcie 445. Jeżeli zapora na komputerze klienckim, serwerze plików albo urządzeniu pośredniczącym blokuje ten port dla zakresu adresów VPN, udział nie otworzy się mimo obecności prawidłowej trasy. Reguły zapory mogą rozróżniać profil sieci, adres źródłowy, adres docelowy oraz interfejs, dlatego połączenie z sieci lokalnej może działać, a połączenie przez tunel VPN może być odrzucane.

Po uzyskaniu odpowiedzi z portu 445 pozostają kwestie związane z sesją SMB i uprawnieniami. Odmowa dostępu, monit o hasło albo komunikat o nieprawidłowych poświadczeniach nie oznaczają braku trasy. Należy wtedy sprawdzić nazwę użytkownika, dostęp do udziału oraz uprawnienia systemu plików na komputerze udostępniającym dane. Warto również usunąć nieaktualne zapisane poświadczenia i ponowić logowanie, ponieważ Windows może utrzymywać wcześniejszą sesję SMB z innym kontem.

Niektóre tunele VPN powodują także problemy z dużymi pakietami. Zbyt duża wartość MTU może prowadzić do fragmentacji albo odrzucania pakietów, szczególnie gdy połączenie przechodzi przez kilka warstw enkapsulacji. Objawem bywa możliwość otwarcia małego pliku, lecz zawieszanie kopiowania większych plików lub rozłączanie sesji. Taki przypadek wymaga sprawdzenia parametrów klienta VPN, urządzenia kończącego tunel oraz komunikatów w logach, bez zmieniania przypadkowo ustawień na wszystkich urządzeniach.

Metodyka przywrócenia dostępu do zasobu

Diagnostykę warto prowadzić od warstwy podstawowej do aplikacyjnej. Najpierw należy zapisać adres IP klienta, adres serwera udziału, maskę, bramę oraz zakres podsieci po drugiej stronie tunelu. Następnie trzeba sprawdzić wpis w tablicy routingu i ustalić, przez który interfejs przechodzi ruch. Kolejny etap obejmuje test DNS oraz portu 445. Dopiero gdy serwer jest osiągalny, ma sens analiza mapowania dysku, poświadczeń i uprawnień do katalogu.

Jeśli brakuje trasy, administrator konfiguracji VPN powinien dodać odpowiednią sieć do parametrów tunelu lub do polityki tunelu dzielonego. Jeżeli trasa jest obecna, należy porównać adres źródłowy widziany po stronie serwera z regułami zapory. Gdy nazwa serwera nie jest rozpoznawana, trzeba zweryfikować, czy klient po połączeniu VPN otrzymuje właściwe serwery DNS i czy zapytania do nich są kierowane przez tunel. W przypadku konfliktu podsieci konieczna może być zmiana adresacji jednej z sieci albo zastosowanie kontrolowanego mechanizmu translacji, zależnie od możliwości użytego rozwiązania VPN.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, obejmującą diagnostykę problemów z konfiguracją sieci, dostępem do udziałów oraz działaniem oprogramowania na komputerach użytkowych. Przy złożonych przypadkach potrzebne są informacje o systemie, sposobie zestawiania VPN, adresie zasobu, komunikacie błędu i tym, czy udział działa bez tunelu. Nie należy publikować haseł ani kluczy dostępowych; do analizy wystarczają parametry techniczne i odpowiednio zanonimizowane komunikaty diagnostyczne.