Külön kimenet: VPN-készlet az usb0-n, átjáró-forgalom az eth0-n

Az ügyfelek csatlakoznak és hitelesítik magukat, majd a forgalmuk a rossz felső linken lép ki, mert a gépen az egyetlen alapértelmezett útvonal magáé az átjáróé. Ennek az alapértelmezett útvonalnak a lecserélése eltörné a gép saját frissítéseit és felügyeleti hozzáférését, ezért a kiválasztásnak szűkebbnek kell lennie, mint „az összes forgalom”. A működő forma egy házirend-szabály, amely az ügyfélkészlet belső forrás-címére épül, és arra a második útválasztási táblára mutat, amely a tartalék WAN-t birtokolja. Onnantól az ellenőrzőlista a teljességről és a hiba viselkedéséről szól, nem magáról a szabályról.

Erősítse meg, hogy a forrás-cím megéri az útválasztási döntést

Egy forrástartományra illeszkedő házirend-szabály csak akkor lép működésbe, ha a csomag a keresés idején még hordozza azt a forrást. A továbbított ügyfélforgalom igen, amíg valami feljebb nem írta át az útválasztás előtt. Az átjáró által generált forgalom nem, és éppen ezért maradhat az átjáró saját alapértelmezett útvonala a helyén.

Itt félrevezetnek a helyi tesztek. Az átjárón futtatott curl helyben létrehozott folyam az átjáró címével, tehát a fő táblát veszi, és semmit nem bizonyít az ügyfél útvonaláról. Teszteljen csatlakoztatott ügyfélről, vagy generáljon forgalmat olyan forrással, amely valóban a készlethez tartozik.

Kezdje a valós értékek felírásával: a készlet előtagja, az azt hordozó alagút-interfész, a második WAN címe és következő ugrása, valamint a használni kívánt táblaszám. A régi szabályokat minden korábbi kísérletből törölje, mielőtt újakat ad hozzá, mert a különböző prioritású ismétlődő szabályok véletlenszerűnek tűnő hibákat okoznak.

Építsen teljes kiválasztott táblát

A tábla nem alapértelmezett útvonal egy baráttal. Elég útvonalra van szüksége ahhoz, hogy minden keresés benne oldódjon fel, beleértve a WAN-alhálózat kapcsolt útvonalát, hogy a következő ugrás elérhető legyen. Egy 10.77.0.0/24 készlethez a tun1-en, 203.0.113.20/24 WAN-címhez 203.0.113.1 következő ugrással, és a 600-as táblához:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

A szabály minden meglévő mindent elkapó szabálynál alacsonyabb prioritáson ül, így az illeszkedő ügyfelek először a 600-as táblát találják el, és minden más a fő táblába esik. Az ip-rule-referencia teljesen leírja a rendezett keresési modellt és a szelektor szintaxisát.

Gondoljon aztán arra, mi nincs a táblában. Egy cél, amelynek csak a fő táblában van útvonala, például egy eth0-n át elérhető felügyeleti alhálózat, nem található meg a 600-as táblában, és nem esik vissza a fő táblára, ha ott már van alapértelmezett útvonal. Ha ezek az utak számítanak, adja hozzá őket kifejezetten a kiválasztott táblához, ami általában a helyes válasz egy VPN-kimeneti táblához.

Tartsa a hallgató saját forgalmát a házirenden kívül

Az OpenVPN-hallgatónak saját külső kapcsolata van, amely azon a felső linken keresztül halad, amelyen az ügyfél elérte. Ennek a forgalomnak meg kell tartania az érkezési visszautat, és egy széles szabály, amely a szerver nyilvános címét vagy a teljes alagút-interfészt lefedi, behúzhatja a tartalék táblába. Szűkítse a szabályt a belső készletre és semmi másra.

A fordított útvonal szűrése ugyanezen okból érdemel egy pillantást. Amikor az ügyfeleknek küldött válaszok az usb0-n lépnek ki, miközben a kérés másik linken érkezett, egy szigorú rp_filter-beállítás eldobhat olyan csomagokat, amelyeket az útválasztási házirend érvényesnek tart. Ellenőrizze a két interfész tényleges sysctl-értékeit, mielőtt arra jutna, hogy a szabály elbukott.

A sorrend is számít a gépen minden máshoz képest. A Docker-hidak, egy második VPN és a szolgáltatói lemezképből származó meglévő szabályok mind prioritásokat adnak, ezért olvassa el a teljes szabálylistát ahelyett, hogy feltételezné, a 100-as prioritás egyedül áll.

Hangolja össze a továbbítást és a fordítást az útvonallal

Az útválasztás felső linket választ; nem ad engedélyt a továbbításra. A kernelben engedélyezni kell az IPv4-továbbítást, a tűzfalnak pedig el kell fogadnia az ügyféltől a WAN felé irányuló forgalmat és a visszaforgalmat. Egy helyes tábla egy FORWARD-lánccal, amely eldobja a folyamot, ugyanazt a tünetet adja, mint egy hiányzó útvonal, ezért mindkettőt ugyanabban a menetben ellenőrizzük.

Ha a második WAN nem irányít vissza egy privát készletet Önhöz, fordítsa le a forrást azon a kimeneten. Dinamikus című interfész esetén a szokásos választás egy szűk masquerade-szabály, amely a készletre és az interfészre korlátozódik:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Itt a hatókör fontosabb, mint a cél. Egy masquerade-szabály, amely bármely kimenő interfészre illeszkedik, átírja az eth0-n helyesen kilépő forgalmat is, és ez elrejti az útválasztási hibákat ahelyett, hogy javítaná őket. A fordítás az útválasztási döntés után fut, ezért soha nem tudja megjavítani a rossz felső linkre küldött csomagot.

Az alagút többletköltsége is figyelmet igényel, amint az utak eltérnek. Ha az ügyfelek nagy TCP MSS-ben állapodnak meg, és a tartalék WAN MTU-ja alacsonyabb, vagy alagút van benne, a nagy szegmensek elakadnak, míg a kicsik működnek. Az MSS szorítása a továbbítási úton kiszámítható viselkedéssé teszi ezt az alkalmi akadozás helyett.

Döntse el, mi történik, amikor az usb0 eltűnik

Az üres tábla nem hiba esetén záró állapot. Ha az illeszkedő útvonal eltűnik, a keresés a következő szabályra lép, eléri a fő táblát, és felveszi az eth0 alapértelmezett útvonalát. A forgalom, amelynek a második WAN-on kellett volna kilépnie, csendesen az elsőn lép ki, ami egy házirend-alapú útválasztású telepítésnél általában a legkevésbé kívánt eredmény.

Ahol ez a visszaesés elfogadhatatlan, adjon hozzá kifejezett terminális útvonalat a 600-as táblához, például egy blackhole-alapértelmezettet, vagy dobja el a készletet a tűzfalon, amíg az interfész le van állítva. Mindkettő olyan döntés, amelyet le lehet írni; a hallgatás nem.

A tartósság az utolsó pont. Aki mindkét linket birtokolja, legyen az hálózatkezelő, küldőszkript vagy a kapcsolat életciklusa, minden újracsatlakozáskor újra létre kell hoznia az útvonalakat és a szabályt, ismétlődések hozzáadása nélkül. Ellenőrizze egy valódi ügyfél kérésével és az átjárótól induló külön kéréssel, erősítse meg a megfigyelt kimenetet mindkettőnél, majd húzza ki a második WAN-t, és nézze meg, a két tervezett kimenet közül melyik történik meg valóban. Az IPv6-nak saját táblára, szabályra és fordításra van szüksége; a fenti IPv4-szabály semmit nem mond róla.