Dotrzyj do strony administracyjnej routera przez VPN, a nie przez WAN

Strona administracyjna routera otwiera się w dwie sekundy z kanapy, a z pokoju hotelowego kończy się przekroczeniem czasu, choć klient VPN przez cały czas zgłasza połączenie. Masz drogę na zewnątrz, nie drogę powrotną: tunel niesie Twój ruch do internetu i tam się zatrzymuje. Aby dotrzeć do urządzenia we własnej sieci LAN, potrzebna jest sesja kończąca się na czymś, co ma do niej trasę. To decyzja projektowa, nie ustawienie, i ona rozstrzyga, czy reszta pracy jest w ogóle możliwa.

Tę różnicę łatwo zgubić, bo jeden produkt potrafi wykonać oba zadania. Komercyjny klient wyjściowy i serwer dostępu zdalnego mogą mówić tym samym protokołem na tym samym porcie, a różnica polega na tym, która strona posiada przestrzeń adresową za punktem końcowym.

Która strona tunelu posiada sieć LAN

Do zarządzania punkt końcowy musi znajdować się w sieci, do której chcesz dotrzeć, albo mieć do niej autoryzowaną drogę. Router uruchamiający własny serwer VPN spełnia warunek; także mały stale włączony host ze stałym adresem i trasą do sieci LAN. Usługa wyjściowa prowadzona przez firmę trzecią nie spełnia go, ponieważ jej punkt końcowy nie ma interfejsu w Twojej sieci LAN ani reguły, która pozwoliłaby takiemu interfejsowi się pojawić. To sprawdzenie trzeba zakończyć, zanim dotkniesz czegokolwiek innego.

Firmware rzadko oznacza tę różnicę, więc czytaj, co robi funkcja, a nie jaką nazwę protokołu podaje. WireGuard, OpenVPN i IKEv2 występują po obu stronach rynku: jedna kompilacja wysyła ruch domowy na zewnątrz, inna przyjmuje Twoje urządzenie zdalne. Kompilacji tylko klienckiej nie da się zamienić w serwer przez konfigurację, niezależnie od treści menu.

Sprawić, by droga powrotna istniała

Serwer WireGuard na routerze ma adres interfejsu, na przykład 10.8.0.1/24, oraz wpis peera dla laptopa. Klient decyduje, jakie cele wyśle do tunelu, a lista zawierająca tylko podsieć tunelu pozostawia sieć LAN niewidoczną, niezależnie od konfiguracji serwera. Obie strony muszą się zgodzić, a zwykle edytuje się tylko jedną z nich.

wg show wg0 allowed-ips
ip route get 192.168.1.1

Pierwsze polecenie informuje, co każdy peer może wysyłać z punktu widzenia serwera; drugie informuje, dokąd adres z sieci LAN faktycznie trafi na kliencie. Cel z sieci LAN, który rozwiązuje się do interfejsu tunelu, to działający routing, a ten wychodzący przez fizyczną bramę nigdy nie dotrze, cokolwiek powie zapora. Dodaj prefiks sieci LAN do listy dozwolonych klienta, a te same dwa polecenia staną się krokiem weryfikacji zamiast diagnozy.

Ten sam skok dla bram IPsec opisuje dokumentacja strongSwan dotycząca przekazywania, gdzie przekazywanie i reguła source-NAT łączą klienta tunelu z hostem wewnętrznym. Adresacja się różni; wymóg nie.

Kto może otworzyć stronę administracyjną

Kontrola dostępu należy do routera, a nie do zamiaru zachowania ostrożności. Zezwól tylko uwierzytelnionej tożsamości tunelu lub zakresowi źródłowemu, który potrzebuje strony, i czytaj własny łańcuch wejściowy routera oraz wszelką przekazywaną politykę sieci LAN. Reguła, która pozwala przewodowej sieci LAN dotrzeć do strony administracyjnej, nic nie mówi o kliencie przychodzącym przez interfejs tunelu. Napisz wyjątek dla konkretnej tożsamości, a potem utrzymuj drugą tożsamość, której należy odmówić.

Nasłuchujący to druga połowa i jest niewidoczny w wyniku zapory. ss -ltnp pokazuje adres, do którego przypisany jest serwer WWW, a usługa przypisana tylko do adresu sieci LAN nie odpowie na adresie tunelu, niezależnie od tego, jak permisywne są reguły. Przypisanie jej ponownie lub dodanie adresu to zmiana konfiguracji routera, a nie zmiana zapory.

Utrzymuj uwierzytelnianie i walidację transportu włączone w tym samym przebiegu. Osiągalność nie jest zaufaniem, i żadne urządzenie wewnątrz tunelu nie staje się przez to administratorem. Poświadczenia tunelu i konto routera to odrębne uprawnienia z odrębnymi cyklami życia, więc klucz zgubionego laptopa można unieważnić bez resetowania hasła każdego administratora.

Testować z zewnątrz, nie z kanapy

Testuj z sieci, której nie kontrolujesz. Połącz się przez zatwierdzony tunel, otwórz świeżą sesję administracyjną i zmień coś nieszkodliwego, co widzisz odzwierciedlone na stronie. Z kanapy dowodzisz, że sieć LAN działa, co nigdy nie było wątpliwe.

Potem sprawdź odmowy z tą samą starannością. Spróbuj otworzyć stronę bez tunelu i potwierdź, że się nie udaje, oraz potwierdź, że usługa administracyjna w ogóle nie nasłuchuje na adresie WAN. Strona, która tylko nie jest podlinkowana, nie jest kontrolą dostępu, a nasłuchujący na WAN pokazujący formularz logowania nadal jest nasłuchującym na WAN. Jeśli hasło jest jedyną rzeczą między internetem a konsolą routera, projektem jest hasło.

Usługi domowe zasługują na spojrzenie, póki tam jesteś. Zaostrzanie reguł zarządzania często psuje sieć gości lub resolver używany przez urządzenia rodziny, a to wychodzi na jaw dni później jako niepowiązana skarga.

Zachować drogę powrotną, gdy zmieniasz rzeczy

Zanim zdalnie zmienisz trasy lub ustawienia tunelu, przygotuj niezależną drogę powrotną. Istniejąca sesja może przetrwać zmianę, która już blokuje nowe połączenia, i dokładnie tak ludzie zamykają się na zewnątrz, patrząc na sesję, która jeszcze działa. Opcje są konkretne: zaplanowany restart do znanej konfiguracji, dostęp konsolowy lub fizyczny, drugi tunel niezależny od edytowanego ustawienia albo zarządzanie pozapasmowe, jeśli sprzęt je oferuje. Wybierz jedną i udowodnij ją przed oknem serwisowym, nie w jego trakcie.

Prowadź zapis krótko i na bieżąco: który host kończy tunel, które tożsamości mogą dotrzeć do strony, do którego adresu przypisuje się usługa i jak unieważnia się zgubione urządzenie. Ta lista służy też jako plan odtworzenia, bo mówi, gdzie mieszka każda zależność. Brakująca droga powrotna to problem routingu do naprawy i nigdy nie jest powodem, by publikować administrację w sieci WAN.