A LAN-kliensek figyelmen kívül hagyják az útválasztó VPN-jét, amíg a házirend-alapú útválasztás be nem lép

Az útválasztó az alagútján keresztül éri el az internetet, miközben a mögötte lévő laptop továbbra is az ISP-címet jelenti. Az elfogadási szabályok hozzáadása nem segít, és ez a kudarc tanulságos: a szűrés arra válaszol, áthaladhat-e egy csomag, nem arra, hová megy. Az interfész kiválasztását már megtette egy útválasztási keresés, amely semmit sem tud a klienslistádról. Javítsd a keresést, és a tűzfal már nem gyanús.

Egy szűrőszabály nem választhat interfészt

A Linux útválasztón a csomagfolyam először az útválasztási döntést, majd a forward-horogot futtatja. Mire egy szabály illeszkedik a kimenő alagúteszközre, a kernel már eldöntötte, hogy az alagút a kifelé vezető út. Ha a fő tábla továbbra is a WAN alapértelmezett útvonalát részesíti előnyben, a csomag az ISP felé tart, és az éppen írt elfogadási szabály soha nem látja. Ez az egyetlen sorrendi tény magyarázza, miért nem változtat semmit egy oldalnyi új tűzfalszabály.

A lenti példa egy 192.168.8.0/24-es LAN-t használ a br-lanon, egy tun0 alagúteszközt és egy set-top boxot a 192.168.8.23 címen, amelynek az alagutat kellene használnia.

Olvasd el a keresést, mielőtt szabályokat szerkesztenél

Kérd meg a kernelt, hogy oldjon fel egy útvonalat annak a kliensnek a nevében. A válasz tartalmazza a kimenő eszközt és a kiválasztandó forráscímet, és ez minden, amire a diagnózis megerősítéséhez szükséged van. Ha a válasz a WAN-eszközt nevezi meg, a csomagnak soha nem volt esélye elérni a szabályodat.

ip -4 route get 198.51.100.7 from 192.168.8.23

Ismételd meg a lekérdezést egy olyan kliensre, amelynek a szokásos úton kell maradnia. Ha mindkét válasz ugyanazt az eszközt nevezi meg, még nincs forrás szerinti házirend, és a javítás az útválasztásba tartozik, nem a szűrésbe.

Kapcsolj táblát azokhoz a kliensekhez, amelyeket le akarsz fedni

A házirend-alapú útválasztás egy szabálykeresést illeszt a fő tábla elé. Építs egy táblát, amelynek alapértelmezett útvonala az alagút, majd kösd ezt a táblát egy szelektorhoz: bemeneti interfész, forráscím vagy tűzfaljelölés. A prioritások döntik el a sorrendet, és a fő tábla messze lent, 32766-nál van a listán, így az alacsony számú szabályt nézik először. Az interfész-szelektorok a hídon lévő minden klienst lefednek; a cím-szelektorok egy gépet fednek le.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

A firmware-felületek általában ugyanazokat az objektumokat mutatják, mint egy házirend-alapú útválasztási vagy VPN-házirend oldal. Az ottani eszközlista könnyebben karbantartható, mint a kézzel írt szabályok, és általában túléli a szabályok szintaxisát megváltoztató frissítéseket.

Válaszd meg a szelektort szándékosan. Az interfészszabály rövid és jövőálló, de elkapja az útválasztó saját felügyeleti forgalmát is, amely ezen a hídon érkezik. A forrásszabály pontos, és szerkesztést igényel valahányszor az eszközlista változik. Írd le a választást, mert szüksége lesz rá a következő embernek, aki azt kérdezi, miért viselkedik másképp egy eszköz.

Tartsd a helyi célokat az alagúton kívül

Egy új tábla csak azokat az útvonalakat ismeri, amelyeket beleteszel. A LAN-előtag hiányzik, ezért a nyomtató és a NAS forgalma az alagút alapértelmezett útvonalát követné és eltűnne. Egy throw útvonal lezárja a keresést ebben a táblában, és visszaadja a döntést a fő táblának.

ip -4 route add throw 192.168.8.0/24 table 200

Ha kihagyod ezt az útvonalat, a helyi megosztások elromlanak, és az útválasztó saját felügyeleti munkamenete is eltűnhet, ha a szelektor szélesebb a szándékozottnál. Utána rendezd a forrás kérdését: a még LAN-címeket hordozó alagútcsomagoknak tudnia kell a másik oldalnak egy visszaútról, míg az alagúton végzett masquerading megszünteti ezt a követelményt, és megszünteti a kliens identitását is, amelyet a másik oldal látna.

A futásidőben hozzáadott szabályok és útvonalak újraindítás vagy firmware-frissítés után eltűnnek. Add hozzá őket az útválasztó indítási mechanizmusához, indítsd újra egyszer, és tesztelj újra a kliensről: a nyilvános címét, egy második klienst, amelynek a WAN-on kell maradnia, és az alagút számlálóit egy új kapcsolat során.