Wi-Fi dla gości nadal korzysta z głównej trasy: daj mu własne wyjście

Utworzyłeś sieć dla gości, dodałeś do niej trasę, a goście nadal wychodzą przez twoje zwykłe połączenie internetowe. Tunel działa, główna LAN działa, a urządzenia gości zgłaszają adres z zakresu, który przydzieliłeś, więc nic nie wygląda na zepsute. Zwykle brakuje nie trasy, ale selektora: router wybiera ścieżkę, zanim weźmie pod uwagę, przez który interfejs przyszła paczka, a jeśli nic wyraźnie nie pasuje do ruchu gości, ten ruch dziedziczy wartość domyślną. Rozwiązaniem jest segment, reguła polityki i ścieżka powrotna, w tej kolejności.

Objaw: goście nadal wychodzą przez WAN

Wskazówką jest adres wyjścia. Urządzenie gościa, które dociera do internetu przez tunel, zgłosi adres dostawcy tunelu, a urządzenie, które odziedziczyło wartość domyślną, zgłosi twoje zwykłe połączenie. Porównaj obok siebie urządzenie gościa i urządzenie głównej LAN, ponieważ ciekawy jest przypadek, gdy różnią się od tego, co skonfigurowałeś, i pasują do siebie.

Drugą wskazówką jest brak jakiegokolwiek ruchu na interfejsie tunelu, gdy goście przeglądają. Jeśli liczniki się nie poruszają, polityka nigdy nie została zastosowana, a dostrajanie samego tunelu nie pomoże.

Krok 1: prawdziwy segment, nie tylko nazwa

Nazwa SSID nie tworzy izolacji. Sprawdź, czy sieć gości kończy się na własnym interfejsie, VLAN-ie lub moście, i czy zakres adresów różni się od zaufanej LAN. W wielu konsumenckich punktach dostępowych SSID gości jest mostkowany do tego samego segmentu co wszystko inne, co uniemożliwia resztę pracy, dopóki nie zostanie to poprawione.

Następnie potwierdź zakres gości i jego serwer DHCP, a ustawienia resolwera trzymaj powiązane z tym segmentem, a nie z całym routerem. Podsieć gości, która istnieje tylko jako komentarz w regule zapory, nie jest segmentem, a router nie będzie miał interfejsu do dopasowania.

Nie mostkuj gości do głównej LAN, żeby ułatwić konfigurację VPN. To zamienia izolację, której chciałeś, na skrót routingu, i to jest zwykły powód, dla którego sieć gości kończy z dostępem do drukarki i NAS-a.

Krok 2: wybierz tunel według źródła

Tabele routingu są wybierane według celu, więc reguła „wyślij 0.0.0.0/0 do tunelu” dotyczy wszystkich. Routing polityczny dodaje drugi wymiar: wybierz tabelę według adresu źródłowego. Na routerze opartym na Linuksie to dodatkowa reguła plus dedykowana tabela, a kolejność ma znaczenie, bo wygrywa pierwsza pasująca reguła:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

To ostatnie polecenie odpowiada na pytanie bezpośrednio: którego interfejsu użyje to źródło dla tego celu. Uruchom je przed zmianą i po niej, a dowiesz się, czy polityka zadziałała, nie dotykając przeglądarki.

Większość firmware'ów routerów wyraża to samo jako regułę interfejsu lub wybór bramy oparty na źródle. Niezależnie od składni używanej przez twoją platformę zasada jest identyczna: dopasuj interfejs wejściowy lub prefiks źródła, a następnie nadpisz trasę tylko dla tego dopasowania. Reguła dopasowana według celu nie potrafi odróżnić gościa od urządzenia domowego.

Krok 3: ścieżka powrotna i tłumaczenie

Paczka, która wychodzi przez tunel, musi wrócić. Albo partner tunelu zna trasę powrotną do prefiksu gości, albo router tłumaczy źródło gości na adres tunelu. Wybierz jedno i zapisz to, bo tryby awarii wyglądają różnie: brakująca trasa powrotna daje połączenie, które się nawiązuje i nigdy nie odpowiada, a brakujące tłumaczenie często nie daje niczego.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Jeśli wybierzesz tłumaczenie, pamiętaj, że partner widzi teraz jeden adres dla wszystkich gości, więc każda polityka na klienta na drugim końcu znika. Jeśli zachowasz adresy, oba końce potrzebują prefiksu gości w swoim routingu i polityce, co jest więcej pracy i bardziej przewidywalne.

IPv6 potrzebuje własnej reguły. Polityka napisana dla IPv4 nie obejmuje drugiej rodziny, a urządzenie gościa z działającym IPv6 chętnie z niej skorzysta, podczas gdy twoja starannie prowadzona trasa IPv4 stoi bezczynnie. Rozprowadź obie rodziny albo wyłącz IPv6 w segmencie gości, ale nie zakładaj, że napisana reguła łączona obejmuje to, co urządzenie naprawdę robi. Testuj z klientem, który ma włączone obie rodziny, bo to jest przypadek, który projekt musi przetrwać. Laptop preferujący IPv6 wygląda poprawnie w teście tylko IPv4, a w rzeczywistym przecieka.

Testuj izolację, nie tylko przeglądanie

Przeglądanie dowodzi, że wyjście się zmieniło. Nie dowodzi, że segment jest odizolowany, a izolacja jest powodem, dla którego sieć gości istnieje. Z urządzenia gościa spróbuj dotrzeć do interfejsu administracyjnego routera, hosta zaufanej LAN i usługi, która powinna zostać odrzucona; wszystkie trzy powinny zawieść, a porażka powinna być decyzją polityki, a nie przekroczeniem czasu, którego nikt nie potrafi wyjaśnić.

Następnie przetestuj urządzenie głównej LAN i potwierdź, że jego wyjście się nie zmieniło. To regresja, którą ten projekt powoduje najczęściej: szeroka reguła przeznaczona dla gości, zastosowana do każdego interfejsu, bo dopasowanie napisano według celu.

Na koniec zdecyduj, co się dzieje, gdy tunel jest wyłączony. Goście albo nie mają internetu, albo wracają do ścieżki, którą akceptujesz, a pozostawienie tego bez decyzji oznacza cichy powrót do zwykłego połączenia, czyli dokładnie ten wyciek, któremu polityka gości miała zapobiegać. Przepis na routing ruchu internetowego przechodzi tę samą selekcję ścieżki dla routera opartego na pfSense.

DNS pochodzący z routera to przypadek, który zaskakuje ludzi na końcu. Jeśli goście używają routera jako resolwera, zapytania samego routera podążają za trasą routera, a nie regułą gości, więc wyszukiwania mogą wychodzić przez zwykłe połączenie, podczas gdy ruch aplikacji nie. Trzymaj segment, resolwer i politykę awarii w jednej notatce, a następna osoba sprawdzi wszystkie trzy bez ponownego wyprowadzania projektu.