Hostovská Wi-Fi stále používá hlavní trasu: dejte jí vlastní východ

Vytvořili jste hostovskou síť, přidali pro ni trasu, a hosté přesto odcházejí přes vaše běžné internetové připojení. Tunel běží, hlavní LAN funguje a hostovská zařízení hlásí adresu v rozsahu, který jste přidělili, takže nic nevypadá rozbité. Obvykle nechybí trasa, ale selektor: router rozhoduje o cestě dřív, než zohlední, kterým rozhraním paket přišel, a pokud něco výslovně neodpovídá hostovskému provozu, tento provoz zdědí výchozí nastavení. Oprava je segment, pravidlo zásady a cesta zpět, v tomto pořadí.

Příznak: hosté stále odcházejí přes WAN

Vodítkem je výstupní adresa. Hostovské zařízení, které se dostane na internet tunelem, nahlásí adresu poskytovatele tunelu, a zařízení, které zdědilo výchozí cestu, nahlásí vaše běžné připojení. Porovnejte hostovské zařízení a zařízení hlavní LAN vedle sebe, protože zajímavý případ je, když se liší od toho, co jste nastavili, a navzájem si odpovídají.

Druhým vodítkem je nepřítomnost jakéhokoli provozu na rozhraní tunelu, zatímco hosté prohlížejí. Pokud se počítadla nehýbou, zásada nebyla nikdy použita a ladění samotného tunelu nepomůže.

Krok 1: skutečný segment, ne jen jméno

Jméno SSID nevytváří izolaci. Zkontrolujte, že hostovská síť končí na vlastním rozhraní, VLAN nebo mostu a že rozsah adres se liší od důvěryhodné LAN. Na mnoha spotřebitelských přístupových bodech je hostovské SSID přemostěno do stejného segmentu jako vše ostatní, což znemožňuje zbytek této práce, dokud se to neopraví.

Pak potvrďte hostovský rozsah a jeho DHCP server a nastavení překladače držte spojené s tímto segmentem, ne s celým routerem. Hostovská podsíť, která existuje jen jako komentář v pravidle firewallu, není segment a router nebude mít rozhraní, se kterým by ji spároval.

Nepřemostujte hosty do hlavní LAN, aby se VPN snáze konfigurovala. Měníte tím izolaci, kterou jste chtěli, za zkratku v směrování, a to je obvyklý důvod, proč hostovská síť skončí s přístupem k tiskárně a NAS.

Krok 2: vyberte tunel podle zdroje

Směrovací tabulky se volí podle cíle, takže pravidlo, které říká poslat 0.0.0.0/0 do tunelu, platí pro všechny. Směrování podle zásad přidává druhý rozměr: vyberte tabulku podle adresy zdroje. Na routeru založeném na Linuxu je to dodatečné pravidlo plus vyhrazená tabulka a pořadí je důležité, protože vyhrává první odpovídající pravidlo:

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

Poslední příkaz odpovídá na otázku přímo: které rozhraní tento zdroj pro tento cíl použije. Spusťte jej před změnou a po ní a budete vědět, zda zásada nabyla účinnosti, aniž byste se dotkli prohlížeče.

Většina firmwaru routerů vyjadřuje totéž jako pravidlo rozhraní nebo volbu brány podle zdroje. Ať vaše platforma používá jakoukoli syntaxi, princip je stejný: spárujte vstupní rozhraní nebo prefix zdroje a potom přepište trasu jen pro tuto shodu. Pravidlo spárované podle cíle nedokáže rozlišit hosta od domácího zařízení.

Krok 3: cesta zpět a překlad

Paket, který odejde tunelem, se musí vrátit. Buď protějšek tunelu zná trasu zpět k hostovskému prefixu, nebo router překládá hostovský zdroj na adresu tunelu. Vyberte jedno a zapište to, protože režimy selhání vypadají různě: chybějící zpětná trasa dá spojení, které se naváže a nikdy neodpoví, zatímco chybějící překlad často nevyprodukuje nic.

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

Pokud zvolíte překlad, pamatujte, že protějšek nyní vidí jednu adresu pro každého hosta, takže jakákoli zásada pro jednotlivého klienta na vzdáleném konci mizí. Pokud místo toho adresy zachováte, oba konce potřebují hostovský prefix ve svém směrování a zásadě, což je více práce a více předvídatelné.

IPv6 potřebuje vlastní pravidlo. Zásada napsaná pro IPv4 nepokrývá druhou rodinu a hostovské zařízení s funkčním IPv6 jej rádo použije, zatímco vaše pečlivě směrovaná cesta IPv4 zůstává nečinná. Buď směrujte obě rodiny, nebo vypněte IPv6 na hostovském segmentu, ale nepředpokládejte, že kombinované pravidlo, které jste napsali, pokrývá to, co zařízení skutečně dělá. Testujte s klientem, který má obě rodiny zapnuté, protože to je případ, který musí návrh vydržet. Notebook, který preferuje IPv6, vypadá správně v testu jen s IPv4 a v reálném uniká.

Testujte izolaci, ne jen prohlížení

Prohlížení dokazuje, že se výstup změnil. Nedokazuje, že je segment izolovaný, a izolace je důvod, proč hostovská síť existuje. Z hostovského zařízení zkuste dosáhnout administračního rozhraní routeru, důvěryhodného hostitele v LAN a služby, která má být odmítnuta; všechny tři by měly selhat a selhání by mělo být rozhodnutím zásady, ne časovým limitem, který nikdo nedokáže vysvětlit.

Pak otestujte zařízení hlavní LAN a potvrďte, že jeho výstup se nezměnil. To je regrese, kterou tento návrh nejčastěji způsobuje: široké pravidlo určené hostům použité na každé rozhraní, protože shoda byla napsána podle cíle.

Nakonec rozhodněte, co se stane, když tunel spadne. Hosté buď nedostanou internet, nebo přejdou na cestu, kterou schvalujete, a nechat to nerozhodnuté znamená tichý návrat k běžnému připojení, což je přesně ten únik, kterému měla hostovská zásada zabránit. recept na směrování internetového provozu popisuje stejnou volbu cesty pro router založený na pfSense.

DNS pocházející z routeru je případ, který lidi překvapí nakonec. Pokud hosté používají router jako svůj překladač, dotazy samotného routeru jdou po trase routeru, ne podle hostovského pravidla, takže vyhledávání mohou odejít běžným připojením, zatímco provoz aplikací ne. Držte segment, překladač a zásadu selhání v jedné poznámce a další člověk může zkontrolovat všechny tři, aniž by návrh znovu odvozoval.