NAS nieosiągalny przez VPN: adres, droga powrotna czy usługa?

Tunele wstają, klienci dostają adres, a NAS nie odpowiada zupełnie nic. Ten jeden objaw obejmuje trzy niezależne awarie, a kolejność ich sprawdzania decyduje o tym, ile potrwa naprawa. Adresacja jest pierwsza, bo nakładająca się podsieć może wysłać żądanie do obcego urządzenia. Droga powrotna jest druga, bo żądanie, które przychodzi bez odpowiedzi, wygląda dokładnie jak zamknięta usługa. Usługa i uprawnienie są na końcu, i tylko po wykazaniu dwóch pierwszych.

Trzy awarie, które wszystkie czyta się jako nieosiągalność

Wybór adresu, routing powrotny i autoryzacja usługi dają ten sam widoczny komunikat: nic się nie dzieje. Mają różne dowody, różnych odpowiedzialnych i różne poprawki, więc ich rozdzielenie to całe zadanie. Ping, który zawodzi, sam w sobie dowodzi niewiele, a udane odrzucenie TCP jest właściwie dobrą wiadomością.

Czytaj tabelę jako kolejność testów, a nie listę przyczyn. Każdy wiersz ogranicza następny, bo odrzucenie już dowodzi, że adresacja i droga powrotna działają. Spędzić dwadzieścia minut w regułach zapory, zanim sprawdzisz, który interfejs wybrała trasa, to najczęstszy sposób utraty popołudnia. Pracuj od góry do dołu i zatrzymaj się na pierwszym pasującym wierszu.

Warunek pierwszy: czy ten adres to właściwe urządzenie?

Zapisz podsieć NAS i zakres, który VPN przydziela klientom, i porównaj oba z siecią, w której jest teraz twój laptop. W tym omówieniu NAS stoi pod 10.40.7.25, a pula VPN to 10.40.9.0/24, dwa osobne zakresy prywatne w ramach jednego planu lokalizacji; gospodarstwo domowe używające 192.168.0.0/24 lub 10.0.0.0/24 ma znacznie większą szansę na kolizję z jednym z nich.

Gdy sieć lokalna i sieć NAS nakładają się, klient wysyła ten ruch do własnej bramy i może dotrzeć do niepowiązanego urządzenia, które przypadkiem ma ten sam adres. Sprawdź ścieżkę, zanim wpiszesz dane logowania w cokolwiek, co odpowiada.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

Pierwsze polecenie podaje interfejs i bramę, których użyłby kernel, a drugie pokazuje pierwsze skoki, które naprawdę odpowiadają. Jeśli oba się nie zgadzają, wierz wyszukiwaniu, bo to jest ścieżka, którą pójdzie pakiet. Lista skoków kończąca się jeden skok przed NAS to także ustalenie, a nie porażka. Wyszukiwanie, które rozwiązuje się na kartę fizyczną zamiast tunelu, kończy dochodzenie w tym miejscu.

Warunek drugi: czy odpowiedź wraca?

Klient potrzebuje trasy do NAS, a sieć NAS potrzebuje drogi powrotnej do puli VPN. Przekazywanie na bramie, reguły zapory i celowa translacja adresów każda wpływa na tę parę. Notatki strongSwan o przekazywaniu opisują wybór drogi powrotnej i translacji dla prywatnej podsieci za bramą.

Gdy żądanie przychodzi, a odpowiedź wychodzi przez inną bramę, żadna zmiana DNS nie naprawi asymetrii. Przechwycenie po obu stronach rozstrzyga to jednym podejściem i pokazuje też, czy translacja przepisała źródło, na które odpowiedział NAS. Administrator odpowiada za tę granicę: zezwól tylko na potrzebne usługi i zakres klientów VPN, i zapisz, czy wybrano routing, czy translację.

Warunek trzeci: czy usługa istnieje i jest dozwolona?

Strona zarządzania i usługa udostępniania plików to różne punkty końcowe na tej samej maszynie, a jedna może przyjmować połączenia, gdy drugą blokuje zapora hosta, konfiguracja usługi lub uprawnienie do udziału. Urządzenie, które odpowiada odrzuceniem, dowiodło już dwóch pierwszych warunków, co znacznie zawęża trzeci.

Testuj kontem, które naprawdę potrzebuje plików, a nie kontem administratora z instalacji, bo uprawnienia administratora nie naprawią brakującej trasy, a trasa nie może przyznać uprawnienia do udziału. Nazwy też tu należą: nazwa NAS wykryta w domu często zależy od lokalnego multicastu, którego trasowany tunel nie przenosi, więc spróbuj udokumentowanej prywatnej nazwy hosta producenta lub samego adresu, aby oddzielić nazewnictwo od dostępu.

Testuj spoza sieci NAS, potem rozszerzaj powoli

Test wykonany w tej samej sieci LAN ukrywa każdą niekompletną część zdalnej ścieżki, dlatego pierwsza udana próba zdalna zasługuje na notatkę w rejestrze zmian. Wykonuj kontrole z klienta, który dociera do NAS tylko przez tunel, i zachowaj oryginalny tekst błędu z każdej próby.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Gdy ścieżka działa, prześlij nieszkodliwy plik i potwierdź dokładnie to zachowanie odczytu lub zapisu, którego potrzebujesz. Jeśli duże transfery się zatrzymują, a małe przechodzą, pozostałym problemem jest obsługa rozmiaru pakietu lub stabilność połączenia, a nie adresacja.

Nie publikuj portów udostępniania plików ani administracji w internecie, aby obejść niewyjaśnioną awarię. Napraw prywatną ścieżkę, utrzymuj oprogramowanie NAS ze wsparciem i testuj odtwarzanie wszystkiego, co przez nie kopiujesz, zanim zaufasz tej kopii.