Jedno zařízení přes router VPN chce tři pravidla, ne přepínač

Na router VPN neexistuje přepínač pro jednotlivé zařízení; přepínač, který hledáte, je zkratka, která za vás zapíše pravidla směrování podle zásad. Ve chvíli, kdy jeden notebook, jeden rozsah portů, jeden seznam adres nebo jeden segment LAN musí jít tunelem, zatímco vše ostatní zůstává na WAN, stavíte trasu zásady, a ne zapínáte funkci. Práce má tři pohyblivé části a každá selhává jinak: označená tabulka bez trasy vypadá jako ticho, značka použitá ve špatném řetězci vypadá, jako by se nic nestalo, a chybějící pravidlo NAT vypadá jako tunel, který se připojí a nic nepřenáší. Další dvě části se ztrácejí, protože se nikdy neobjeví v pravidle mangle, a to jsou DNS a IPv6.

Mýtus: tunel je nastavení klienta

VPN klient na straně routeru dělá jednu hrubou věc dobře: dá 0.0.0.0/0 do hlavní směrovací tabulky a namíří je do tunelu. WireGuard to odvozuje z AllowedIPs, OpenVPN z vynuceného redirect-gateway a oba mění cestu pro každého hosta za routerem. Zúžení AllowedIPs nebo přidání route-nopull mění to, co klient nainstaluje. Nemění to, na koho se instalace vztahuje, protože klient nikdy nevidí zařízení. Vidí jen pakety.

Výběr podle zdroje nebo cíle je rozhodnutí o směrování, takže patří do politické vrstvy routeru: pravidlo mangle plus druhá tabulka na RouterOS, MARK plus ip rule na OpenWrt nebo DD-WRT, nebo firewallové pravidlo, jehož brána je tunel, na pfSense. Recept na WireGuard klienta od Netgate je to, co je třeba si přečíst, než začnete hádat, protože na této platformě se brána pravidla, přiřazení rozhraní a záznam odchozího NAT musí shodnout, než tunel použije jediný klient.

Druhá polovina mýtu je druhý router. Koupě další krabice nebo přesun zařízení na hostující SSID často opravdu funguje a důvodem není hardware: dá zařízení do vlastní podsítě, což vám poskytne selektor zdroje, kterému firmware už rozumí. Pokud ten segment umíte definovat na routeru, který máte, řeší krabice navíc problém, který jste neměli.

První část: tunel, který není výchozí trasou

Na RouterOS přidejte klienta bez výchozí trasy a dejte tunelu vlastní tabulku. První trasa je označená výchozí; druhá je polovina selhání.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Trasa unreachable je důvod, proč označená tabulka poráží seznam výjimek v hlavní tabulce. Když tunel spadne, označené pakety dostanou okamžitě nedostupné místo toho, aby se tiše vrátily na WAN, takže selhání je vidět v chybové zprávě aplikace, a ne na stránce geolokace, kterou zkontrolujete o hodinu později.

RouterOS 7 odděluje to, co 6.x držel pohromadě: tabulku deklarujete pomocí /routing table add name=vpn fib a pak na ni odkazujete jménem v trase i v pravidle mangle. Úryvek pro 6.x, který vkládá routing-mark bez definice tabulky, se načte čistě a nic nesedí. Další klasický případ jsou dvě poloviny 0.0.0.0/1 nebo dvě výchozí trasy na stejné vzdálenosti v jedné tabulce: jádro vybere jednu a chování se po restartu může změnit.

Druhá část: značka před vyhledáním trasy

Selektor rozhoduje, které pakety do té tabulky vstoupí. RouterOS obvykle začíná seznamem adres pro politiku cíle nebo zdrojovou adresou pro politiku zařízení:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux firmware dělá totéž pomocí netfilter značky a pravidla, které označené pakety nasměruje do tabulky, kterou jste naplnili:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Řetězec není věc stylu. Než paket dorazí do FORWARD, vyhledání trasy už proběhlo, takže MARK nebo DROP tam může jen přepsat nebo zahodit. Značka musí padnout do PREROUTING pro předávaný provoz a do OUTPUT pro provoz, který vytváří sám router, protože tam žijí DNS, NTP a kontroly aktualizací routeru. Právě tato výstupní cesta je obvyklým důvodem, proč plně tunelované nastavení v testu úniku stále odpovídá z resolveru ISP.

Politika zařízení potřebuje shodu, která se neposouvá. Rezervujte adresu v DHCP nebo spárujte rozhraní pro vyhrazený segment; adresa, která později přejde na jiné zařízení, tiše aplikuje tunel na špatného klienta. Most pro každé SSID s vlastní podsítí je trvanlivější verzí téže myšlenky a dává pravidlům IPv6 místo, kde žít.

Třetí část: NAT, DNS a výjimka pro LAN

Provoz, který odchází tunelem, potřebuje zdrojovou adresu, na kterou vzdálená strana odpoví. Omezte překlad na rozhraní tunelu: out-interface=VPN_NAME na RouterOS, -o tun0 na Linuxu, odpovídající záznam odchozího NAT na pfSense. Pravidlo masquerade bez tohoto omezení přepisuje provoz, který jste chtěli nechat být, a symptomem je, že netunelované zařízení ztratí svou veřejnou adresu.

Výjimka pro LAN způsobuje více vláken podpory než tunel sám. Pokud označená tabulka drží jen výchozí trasu, cíl tiskárny nebo NAS z vybraného zařízení odpovídá této výchozí a zmizí v tunelu. Přidejte trasu LAN do stejné tabulky nebo vylučte místní podsíť v selektoru; obojí funguje a vyloučení je snazší udržet správné, když později přidáte VLAN.

DNS jde jinou cestou. Dotazy, které router předává, pocházejí od routeru a řídí se OUTPUT, ne předávanou značkou, takže plně tunelovaný notebook může stále překládat přes ISP. Nasměrujte klienty na resolver dostupný tunelem, nebo označte vlastní provoz routeru na portu 53, a pak zkontrolujte přeloženou adresu, místo abyste předpokládali, že odpověď cestovala s webovým požadavkem.

Když pravidlo sedí, ale aplikace stále používá WAN

Seznamy cílů rychle stárnou. Jméno se přeloží na adresu, která v seznamu není, takže požadavek jde přes WAN, i když každý test, který jste na uvedenou adresu dělali, fungoval. Obnovujte seznam ze stejného resolveru, který používá klient, a když opravdu chcete veškerý provoz z jednoho zařízení, dejte přednost selektoru podle zdroje.

IPv6 je tichý obchvat. Zařízení má druhou rodinu adres s vlastní výchozí trasou a vlastní sadou pravidel a shoda jen na adrese IPv4 je polovina politiky. Použijte stejný selektor na ip6tables nebo ekvivalent v nftables, nebo IPv6 v tomto segmentu vypněte záměrně, ne náhodou.

Ustavená spojení také hrají roli. Záznam conntrack vytvořený před změnou sleduje starou cestu, dokud nevyprší, takže prohlížeč, který zůstal otevřený během úprav, vypadá přesně jako pravidlo, které se nikdy nepoužilo. Otevřete nové spojení nebo vyprázdněte stav, než politiku posoudíte.

Ověřte dvěma zařízeními a restartem

Otestujte zařízení, které má být v tunelu, i to, které nemá, a porovnejte druhý hop místo čísla rychlosti. Traceroute z každého ukáže na druhém hopu buď bránu tunelu, nebo bránu ISP; pokud oba vypadají stejně, značka nebo tabulka nedělá to, co pravidlo říká. Pro test použijte nová spojení.

Pak restartujte. Pořadí při startu je místo, kde se z funkční politiky stane rozbitá, protože klient musí být aktivní dřív, než se nainstaluje trasa unreachable, a uložený snímek, který obnoví starou sadu pravidel, přepíše vaši tabulku. Zkontrolujte, že každé pravidlo je v uložené konfiguraci a že označená výchozí trasa existuje po startu, ne jen poté, co jste ji napsali.

Pokud něco selže, nejprve odeberte značku a podívejte se, zda se normální provoz vrátí, potom odeberte tabulku. Toto pořadí vám řekne, zda řešíte problém směrování, nebo problém firewallu, a nechá domácnost s funkční tiskárnou, dokud práci dokončíte.