Egy eszköz router VPN-en át három szabályt igényel, nem kapcsolót

Egy router VPN-en nincs eszközönkénti kapcsoló; a kapcsoló, amit keresel, egy gyorsparancs, amely helyetted írja a szabályalapú útválasztási szabályokat. Abban a pillanatban, amikor egy laptopnak, egy porttartománynak, egy címlistának vagy egy LAN-szegmensnek az alagúton kell mennie, miközben minden más a WAN-on marad, szabályalapú útvonalat építesz, nem funkciót kapcsolsz be. A munkának három mozgó része van, és mindegyik másképp hibázik: a megjelölt tábla útvonal nélkül csendnek látszik, a rossz láncba tett jelölés olyannak tűnik, mintha semmi sem történt volna, a hiányzó NAT-szabály pedig olyan alagútnak, amely csatlakozik és semmit nem szállít. Két további rész hiányzik, mert soha nem jelenik meg a mangle-szabályban, és ezek a DNS és az IPv6.

A mítosz: az alagút kliensbeállítás

A router oldali VPN-kliens egy durva dolgot jól csinál: beteszi a 0.0.0.0/0-t a fő útválasztási táblába, és az alagútra irányítja. A WireGuard ezt az AllowedIPs-ből vezeti le, OpenVPN egy tolt redirect-gateway-ből, és mindkettő megváltoztatja az útvonalat a router mögötti minden hoszt számára. Az AllowedIPs szűkítése vagy a route-nopull hozzáadása megváltoztatja, mit telepít a kliens. Nem változtatja meg, kire vonatkozik a telepítés, mert a kliens soha nem lát eszközöket. Csak csomagokat lát.

Forrás vagy cél szerinti választás útválasztási döntés, ezért a router házirend-rétegéhez tartozik: mangle-szabály plusz második tábla a RouterOS-on, MARK plusz ip rule az OpenWrt-n vagy DD-WRT-n, vagy tűzfalszabály, amelynek átjárója az alagút, a pfSense-en. A Netgate WireGuard-kliens receptje az, amit tippelés előtt érdemes elolvasni, mert azon a platformon a szabály átjárójának, az interfész-hozzárendelésnek és a kimenő NAT-bejegyzésnek mind egyeznie kell, mielőtt egyetlen kliens használja az alagutat.

A mítosz második fele a második router. Egy újabb doboz megvásárlása vagy az eszköz vendég-SSID-re vitele gyakran működik, és az ok nem a hardver: az eszközt a saját alhálózatára teszi, ami megadja azt a forrásválasztót, amelyet a firmware már ért. Ha azt a szegmenst definiálni tudod a saját routereden, a plusz doboz egy olyan problémát old meg, amely nem is volt.

Első rész: alagút, amely nem az alapértelmezett útvonal

A RouterOS-on add hozzá a klienst alapértelmezett útvonal nélkül, és adj az alagútnak saját táblát. Az első útvonal a megjelölt alapértelmezett; a második a hiba fele.

/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

Az unreachable útvonal az oka, amiért a megjelölt tábla legyőzi a fő tábla kivétellistáját. Amikor az alagút elesik, a megjelölt csomagok azonnal unreachable-t kapnak ahelyett, hogy csendben visszaesnének a WAN-ra, így a hiba az alkalmazás hibaüzenetében jelenik meg, nem egy geolokációs oldalon, amelyet egy órával később nézel meg.

A RouterOS 7 szétválasztja azt, amit a 6.x együtt tartott: a táblát a /routing table add name=vpn fib paranccsal deklarálod, majd név szerint hivatkozol rá az útvonalon és a mangle-szabályban. A 6.x-es részlet, amely a tábla meghatározása nélkül írja be a routing-markot, tisztán betöltődik és semmivel nem egyezik. A másik klasszikus két 0.0.0.0/1 fél, vagy két alapértelmezett útvonal azonos távolsággal egy táblában: a kernel az egyiket választja, és a viselkedés újraindítás után megváltozhat.

Második rész: jelölés az útvonalkeresés előtt

A választó dönti el, mely csomagok lépnek be abba a táblába. A RouterOS általában címlistával kezd a célházirendhez, vagy forráscímmel az eszközházirendhez:

/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

A Linux firmware ugyanezt teszi egy netfilter-jelöléssel és egy szabállyal, amely a megjelölt csomagokat az általad feltöltött táblába tereli:

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

A lánc nem stíluskérdés. Mire egy csomag a FORWARD-hoz ér, az útvonalkeresés már megtörtént, így egy ottani MARK vagy DROP csak átírni vagy eldobni tud. A jelölésnek a PREROUTING-ba kell kerülnie a továbbított forgalomhoz, és az OUTPUT-ba a router által létrehozott forgalomhoz, mert ott él a router DNS-e, NTP-je és frissítésellenőrzése. Ez a kimeneti út a szokásos oka annak, hogy egy teljesen alagútba tett beállítás szivárgásteszten még mindig az ISP feloldójától válaszol.

Az eszközházirend olyan egyezést igényel, amely nem csúszik el. Foglald le a címet DHCP-ben, vagy párosíts interfészt egy dedikált szegmenshez; egy később másik eszközre átkerülő cím csendben a rossz kliensre alkalmazza az alagutat. Egy SSID-nkénti híd saját alhálózattal ugyanennek az ötletnek a tartósabb változata, és helyet ad az IPv6-szabályoknak is.

Harmadik rész: NAT, DNS és a LAN-kivétel

Az alagúton kifelé menő forgalomnak olyan forráscím kell, amelyre a távoli oldal válaszol. Korlátozd a fordítást az alagút interfészére: out-interface=VPN_NAME a RouterOS-on, -o tun0 Linuxon, megfelelő kimenő NAT-bejegyzés a pfSense-en. Egy masquerade-szabály e korlátozás nélkül átírja azt a forgalmat, amelyet békén akartál hagyni, és a tünet az, hogy a nem alagútba tett eszköz elveszíti a nyilvános címét.

A LAN-kivétel több támogatási szálat okoz, mint maga az alagút. Ha a megjelölt tábla csak alapértelmezett útvonalat tartalmaz, a kiválasztott eszköz nyomtató- vagy NAS-célja egyezik ezzel az alapértelmezettel, és eltűnik az alagútban. Add hozzá a LAN-útvonalat ugyanahhoz a táblához, vagy zárd ki a helyi alhálózatot a választóban; mindkettő működik, és a kizárást könnyebb helyesen tartani, amikor később VLAN-okat adsz hozzá.

A DNS külön utat jár. A router által továbbított lekérdezések a routerből indulnak, és az OUTPUT-ot követik, nem a továbbítási jelölést, így egy teljesen alagútba tett laptop még mindig az ISP-n keresztül oldhat fel. Irányítsd a klienseket az alagúton át elérhető feloldóra, vagy jelöld meg a router saját 53-as portjának forgalmát, majd ellenőrizd a feloldott címet ahelyett, hogy feltételeznéd, a válasz a webkéréssel együtt utazott.

Amikor a szabály egyezik, de az alkalmazás még a WAN-t használja

A céllisták rosszul öregszenek. Egy név olyan címre oldódik fel, amely nincs a listán, így a kérés a WAN-t veszi igénybe, miközben minden teszt, amelyet a listázott cím ellen futtattál, működött. Frissítsd a listát ugyanabból a feloldóból, amelyet a kliens használ, és részesítsd előnyben a forrásalapú választót, amikor valóban egy eszköz teljes forgalmát akarod.

Az IPv6 a csendes megkerülés. Az eszköznek van egy második címcsaládja saját alapértelmezett útvonallal és saját szabálykészlettel, és csak az IPv4-cím egyeztetése fél házirend. Alkalmazd ugyanazt a választót az ip6tables-re vagy az nftables megfelelőjére, vagy tudatosan kapcsold ki az IPv6-ot azon a szegmensen, nem véletlenül.

A létrejött kapcsolatok is számítanak. A változás előtt létrejött conntrack-bejegyzés a régi úton halad, amíg le nem jár, így a szerkesztés alatt nyitva maradt böngésző pontosan olyan szabálynak látszik, amelyet soha nem alkalmaztak. Nyiss új kapcsolatot, vagy ürítsd az állapotot, mielőtt megítéled a házirendet.

Ellenőrizd két eszközzel és egy újraindítással

Teszteld az alagútba kerülő eszközt és azt, amelyiknek nem kellene, és a sebességszám helyett a második ugrást hasonlítsd össze. Egy traceroute mindkettőből vagy az alagút átjáróját, vagy az ISP átjáróját mutatja a második ugrásnál; ha mindkettő ugyanúgy néz ki, a jelölés vagy a tábla nem azt teszi, amit a szabály mond. A teszthez használj új kapcsolatokat.

Aztán indítsd újra. Az indítási sorrend az a pont, ahol egy működő házirend elromlottá válik, mert a kliensnek futnia kell, mielőtt az unreachable útvonal telepítődik, és egy mentett pillanatkép, amely visszaállítja a régi szabálykészletet, felülírja a tábládat. Ellenőrizd, hogy minden szabály benne van a mentett konfigurációban, és hogy a megjelölt alapértelmezett útvonal az indítás után is létezik, nem csak azután, hogy beírtad.

Ha valami elromlik, először vedd le a jelölést, és nézd meg, visszatér-e a normál forgalom, aztán vedd le a táblát. Ez a sorrend megmondja, útválasztási vagy tűzfalproblémát kergetsz-e, és működő nyomtatóval hagyja a háztartást, amíg befejezed a munkát.