Jedno zariadenie cez VPN na routeri si vyžaduje tri pravidlá, nie prepínač

Na VPN na routeri neexistuje prepínač pre každé zariadenie; prepínač, ktorý hľadáte, je skratka, ktorá za vás píše pravidlá smerovania politiky. V okamihu, keď jeden laptop, jeden rozsah portov, jeden zoznam adries alebo jeden segment LAN musí používať tunel, kým všetko ostatné zostáva na WAN, budujete trasu politiky, nie zapínate funkciu. Práca má tri pohyblivé časti a každá zlyháva inak: označená tabuľka bez trasy vyzerá ako ticho, značka v nesprávnom reťazci vyzerá, akoby sa nič nestalo, a chýbajúce pravidlo NAT vyzerá ako tunel, ktorý sa pripojí a nič nepreváža. Chýbajú ešte dve časti, pretože sa nikdy neobjavia v pravidle mangle, a to sú DNS a IPv6.

Mýtus: tunel je nastavenie klienta

VPN klient na strane routera robí jednu hrubú vec dobre: vloží 0.0.0.0/0 do hlavnej smerovacej tabuľky a nasmeruje ju do tunela. WireGuard to odvodzuje z AllowedIPs, OpenVPN a z redirect-gateway, ktorý posiela server, a obe menia cestu pre každý host za routerom. Zúženie AllowedIPs alebo pridanie route-nopull mení to, čo klient nainštaluje. Nemení to, na koho sa inštalácia vzťahuje, pretože klient nikdy nevidí zariadenia. Vidí iba pakety.

Výber podľa zdroja alebo cieľa je rozhodnutie o smerovaní, takže patrí do vrstvy politiky routera: pravidlo mangle plus druhá tabuľka na RouterOS, MARK plus ip rule na OpenWrt alebo DD-WRT, alebo pravidlo firewallu, ktorého bránou je tunel, na pfSense. Recept Netgate na klienta WireGuard je ten, ktorý si treba prečítať pred hádaním, pretože na tejto platforme sa brána pravidla, priradenie rozhrania a záznam odchádzajúceho NAT musia zhodnúť, kým jeden klient použije tunel.

Druhá polovica mýtu je druhý router. Kúpa ďalšej krabice alebo presun zariadenia na hosťovské SSID často funguje a dôvodom nie je hardvér: umiestni zariadenie do jeho vlastnej podsiete, čo vám dá selektor zdroja, ktorému firmware už rozumie. Ak dokážete tento segment definovať na svojom routeri, extra krabica rieši problém, ktorý ste nemali.

Prvá časť: tunel, ktorý nie je predvolenou trasou

Na RouterOS pridajte klienta bez predvolenej trasy a dajte tunelu vlastnú tabuľku. Prvá trasa je označená predvolená; druhá je polovica zlyhania.

/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

Nedosiahnuteľná trasa je dôvod, prečo označená tabuľka poráža zoznam výnimiek v hlavnej tabuľke. Keď tunel padne, označené pakety dostanú okamžite nedosiahnuteľnosť namiesto tichého návratu na WAN, takže porucha sa objaví v chybovej správe aplikácie a nie na stránke geolokácie, ktorú skontrolujete o hodinu.

RouterOS 7 oddeľuje to, čo 6.x držal spolu: tabuľku deklarujete cez /routing table add name=vpn fib a potom na ňu odkazujete podľa názvu na trase a v pravidle mangle. Úryvok pre 6.x, ktorý píše routing-mark bez definovania tabuľky, sa načíta čisto a ničomu nezodpovedá. Ďalší klasický prípad sú dve polovice 0.0.0.0/1 alebo dve predvolené trasy v rovnakej vzdialenosti v jednej tabuľke: jadro vyberie jednu a správanie sa môže po reštarte zmeniť.

Druhá časť: označte pred hľadaním trasy

Selektor rozhoduje, ktoré pakety vstúpia do tej tabuľky. RouterOS zvyčajne začína zoznamom adries pre politiku cieľa alebo adresou zdroja pre politiku zariadenia:

/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

Firmvér Linuxu robí to isté so značkou netfilter a pravidlom, ktoré označené pakety smeruje do tabuľky, ktorú ste 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

Reťazec nie je voľba štýlu. Keď paket dorazí do FORWARD, hľadanie trasy už prebehlo, takže MARK alebo DROP tam môže iba prepísať alebo zahodiť. Značka musí pristáť v PREROUTING pre preposielanú premávku a v OUTPUT pre premávku, ktorú vytvára samotný router, kde žijú DNS, NTP a kontroly aktualizácií routera. Tá výstupná cesta je obvyklý dôvod, prečo plne tunelované nastavenie v teste úniku stále odpovedá z resolvera poskytovateľa.

Politika zariadenia potrebuje zhodu, ktorá neklže. Rezervujte adresu v DHCP alebo priraďte rozhranie k vyhradenému segmentu; adresa, ktorá sa neskôr presunie na iné zariadenie, ticho aplikuje tunel na nesprávneho klienta. Most pre každé SSID s vlastnou podsieťou je trvácnejšia verzia tej istej myšlienky a dáva aj pravidlám IPv6 miesto na život.

Tretia časť: NAT, DNS a výnimka pre LAN

Premávka, ktorá odchádza tunelom, potrebuje zdrojovú adresu, na ktorú druhá strana odpovie. Obmedzte preklad na rozhranie tunela: out-interface=VPN_NAME na RouterOS, -o tun0 na Linuxe, zodpovedajúci záznam odchádzajúceho NAT na pfSense. Pravidlo masquerade bez tohto obmedzenia prepisuje premávku, ktorú ste chceli nechať na pokoji, a príznakom je, že zariadenie mimo tunela stratí verejnú adresu.

Výnimka pre LAN spôsobuje viac vlákien podpory ako samotný tunel. Ak označená tabuľka obsahuje iba predvolenú trasu, cieľ tlačiarne alebo NAS z vybraného zariadenia sa zhoduje s tou predvolenou a zmizne v tuneli. Pridajte trasu LAN do tej istej tabuľky alebo vylúčte lokálnu podsieť v selektore; oboje funguje a vylúčenie sa ľahšie udrží správne, keď neskôr pridáte VLAN.

DNS ide samostatnou cestou. Dotazy, ktoré router preposiela, pochádzajú z routera a nasledujú OUTPUT, nie preposielanú značku, takže plne tunelovaný laptop stále môže prekladať mená cez poskytovateľa. Nasmerujte klientov na resolver dostupný cez tunel alebo označte premávku port-53 samotného routera, a potom skontrolujte preloženú adresu, namiesto toho aby ste predpokladali, že odpoveď cestovala spolu s webovou požiadavkou.

Keď pravidlo sedí, ale aplikácia stále používa WAN

Zoznamy cieľov rýchlo starnú. Meno sa preloží na adresu, ktorá v zozname nie je, takže požiadavka ide cez WAN, kým každý test, ktorý ste na uvedenej adrese urobili, fungoval. Obnovte zoznam z toho istého resolvera, ktorý používa klient, a uprednostnite selektor založený na zdroji, keď naozaj chcete všetku premávku z jedného zariadenia.

IPv6 je tiché obchádzanie. Zariadenie má druhú rodinu adries s vlastnou predvolenou trasou a vlastnou sadou pravidiel a zhoda iba s adresou IPv4 je polovica politiky. Použite ten istý selektor na ip6tables alebo ekvivalent nftables, alebo zámerne vypnite IPv6 v tom segmente, a nie náhodou.

Aj nadviazané spojenia sú dôležité. Záznam conntrack vytvorený pred zmenou pokračuje po starej ceste, kým nevyprší, takže prehliadač, ktorý zostal otvorený počas úpravy, vyzerá presne ako pravidlo, ktoré sa nikdy nepoužilo. Otvorte nové spojenie alebo vymažte stav, kým politiku posúdite.

Overte s dvoma zariadeniami a reštartom

Otestujte zariadenie, ktoré má byť v tuneli, a zariadenie, ktoré nemá, a porovnajte druhý skok namiesto čísla rýchlosti. Traceroute z každého ukáže buď bránu tunela, alebo bránu poskytovateľa na druhom skoku; ak obe vyzerajú rovnako, značka alebo tabuľka nerobia to, čo pravidlo hovorí. Na test použite nové spojenia.

Potom reštartujte. Poradie štartu je miesto, kde sa funkčná politika pokazí, pretože klient musí byť hore pred inštaláciou nedosiahnuteľnej trasy a uložený snapshot, ktorý obnoví starú sadu pravidiel, prepíše vašu tabuľku. Skontrolujte, že každé pravidlo je v uloženej konfigurácii a že označená predvolená trasa existuje po štarte, nielen po tom, čo ste ju napísali.

Ak niečo zlyhá, najprv odoberte značku a pozrite sa, či sa vráti normálna premávka, potom odoberte tabuľku. Toto poradie vám povie, či naháňate problém so smerovaním alebo s firewallom, a nechá domácnosti fungujúcu tlačiareň, kým prácu dokončíte.