Dotarcie do domowego urządzenia przez VPN dostępu zdalnego: pięć bram

Komercyjny VPN z wyjściem do internetu ukrywa twój adres; nie łączy cię z własnym domem. Dotarcie do NAS-a lub drukarki w sieci domowej wymaga bramy znajdującej się w tej sieci oraz klienta, który buduje do niej tunel. Potem pakiet musi przejść pięć kontroli, a każda ich porażka wygląda z zewnątrz tak samo.

Brama 1: klient musi wybrać tunel

Sprawdź, czy prefiks docelowy rzeczywiście jest kierowany do tunelu na kliencie. Profil dzielonego tunelu, który wysyła tylko własną podsieć VPN, wyśle 192.168.x.x prosto z lokalnego interfejsu, gdzie nigdzie nie dotrze. Patrz na tablicę routingu klienta, a nie na nazwę profilu.

To najczęstsza awaria u klientów telefonicznych, które często domyślnie wysyłają tylko DNS albo tylko jeden prefiks. Jeśli brakuje trasy, uścisk dłoni może być doskonały, a urządzenie nadal nieosiągalne.

Przed kontynuowaniem potwierdź, że adres puli klienta i podsieć domowa nie nakładają się.

Brama 2: brama musi przekazywać

VPN kończy się na hoście, który musi przekazać odszyfrowany pakiet do LAN-u. Wymaga to włączonego przekazywania IP i polityki firewalla zezwalającej na przepływ z interfejsu VPN do interfejsu LAN. Na urządzeniu routera jest to zwykle wbudowane; na skrzynce Linux z strongSwan lub WireGuard to dwa ustawienia, o których ludzie zapominają. Sprawdź oba przed testowaniem usługi, bo każde samo daje ten sam limit czasu.

Testuj przechwytywaniem na interfejsie LAN, bo pakiet, który nigdy się tam nie pojawia, został odrzucony lub nigdy nieprzekazany.

To inna awaria niż usługa odmawiająca połączenia, a to rozróżnienie oszczędza dużo czasu. Trzymaj zezwolenie wąskie, ograniczone do usługi i puli VPN, a nie całej podsieci.

Brama 3: ścieżka powrotna decyduje o wszystkim

Cel odpowiada na adres źródłowy, który widział, czyli adres puli klienta albo bramę, w zależności od tego, czy tłumaczysz. Jeśli domyślną bramą celu jest router domowy i nie ma on trasy do puli VPN, odpowiedź wychodzi przez internet i ginie. To klasyczne połączenie jednokierunkowe.

Istnieją dwa legalne rozwiązania: dodać trasę do puli na bramie LAN albo zrobić source-NAT na bramie VPN, aby cel zawsze widział tylko adres bramy. Drugie jest łatwiejsze i traci pierwotną tożsamość źródła.

Wybierz jedno świadomie i zapisz które, bo reguły firewalla i logi zależą od tego. Przewodnik strongSwan po przekazywaniu przechodzi przez stronę Linuksa tej decyzji.

Brama 4: nazwy i nakładanie się prefiksów

Lokalne nazwy wykrywania nie przekraczają granicy routingu, więc urządzenie widoczne w domu pod przyjazną nazwą może być niewidoczne przez tunel. Zapewnij DNS dla strefy prywatnej albo udokumentuj adres. Jakiejkolwiek nazwy użyjesz, musi się ona rozwiązywać na coś, co zdalny klient potrafi trasować. Dlatego urządzenie może być osiągalne po adresie i jednocześnie niewidoczne po nazwie.

Nakładające się prefiksy to druga pułapka: jeśli pula klienta to 192.168.1.0/24 i sieć domowa też, klient traktuje cel jako lokalny i nigdy nie wysyła go przez tunel.

Przenumeruj jedną stronę albo użyj puli z zakresu, którego nigdy nie spotkasz w domu.

Brama 5: testuj spoza domu

Test z kuchni niczego nie dowodzi, bo ruch może nigdy nie opuścić LAN-u. Połącz się z hotspotu mobilnego lub innej sieci, a potem przejdź bramy po kolei: trasa na kliencie, przechwycenie na interfejsie LAN, odpowiedź usługi, przechwycenie odpowiedzi i rozwiązywanie nazw. Pierwsza brama, która nie daje dowodów, wskazuje miejsce pracy.

Jeśli usługa odpowiada, ale nazwa nie, masz problem z DNS, a nie z tunelem.

Zachowaj działającą konfigurację w notatce z pulą, trasą i wyborem NAT, bo następna wymiana routera zresetuje wszystkie trzy.