Směrování podle zdroje pro dva pooly VPN: co vaše pravidlo přehlíží

Dva klientské pooly, jedna brána a plán vypadá triviálně: jedno pravidlo pošle první pool přes rychlý uplink, druhé pošle druhý pool přes partnerský tunel. Pak jsou pravidla na místě a druhý pool stejně odchází přes výchozí trasu. Pravidlo není rozbité. Zdroj paketu není to, co autor v okamžiku vyhledání očekával, protože překlad a vyhledání probíhají v různých bodech cesty téhož paketu a pořadí je opačné než mentální schéma, které si většina lidí kreslí.

Vyhledání probíhá dřív, než se zdroj přepíše

U paketu předávaného od klienta VPN jádro provádí pevnou posloupnost. Dorazí na rozhraní tunelu, projde prerouting, kde žijí conntrack a DNAT, pak se učiní rozhodnutí o směrování, pak předávání, pak postrouting, kde se SNAT aplikuje naposled. Pravidlo tvaru from se konzultuje během tohoto rozhodnutí o směrování, takže vidí původní adresu klienta, nikoli přeloženou.

Přidání pravidla masquerade tedy nemění, která politika odpovídá odchozímu toku. Mění to, co vidí vzdálený konec, a tím i to, která zpětná cesta existuje. To jsou dva různé důsledky a revize změn je neustále zaměňují. Oddělte je a návrh bývá jasný během minuty.

Přeložená adresa se v pravidlech objevuje ve směru odpovědi. Paket vracející se na bránu je adresován přeložené adrese, a pokud máte pravidla politiky vázaná na cíl nebo na rozhraní, kterým dorazil, je to hodnota, kterou budete porovnávat. Stejné spojení, v každém směru jiný zdroj pravdy.

Dva pooly s různými zdroji tedy opravdu potřebují různé tabulky a návrh je správný. Co tabulka výše vylučuje, je zkratka ladit pohledem na to, co vzdálené místo dostalo, a odvozovat z toho pravidlo.

Test z brány není test poolu

Provoz, který brána generuje sama, nikdy neprochází preroutingem, protože nedorazil na žádné rozhraní. Směruje se ve výstupní cestě, se zdrojem v podobě vlastní adresy brány, a pravidlo from vázané na rozsah klientů se neshoduje. Každý tiket v této oblasti, který říká, že to z krabice funguje, ale z klienta ne, je jen převyprávěním tohoto faktu.

Simulujte klienta místo toho, abyste jej aproximovali. Na rozhodnutí o směrování se lze zeptat přímo, se zadaným zdrojem a vstupním rozhraním:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Spusťte to jednou na pool. Pokud oba příkazy vrátí stejné rozhraní, pravidla pooly neoddělují a příčinou je buď chybějící pravidlo, nebo pravidlo s vyšší prioritou, které odpovídá oběma. Pokud vrátí různá rozhraní, ale klient stále selhává, je závada až za vyhledáním a můžete přestat zkoumat pravidla.

Priorita, ne pozice v souboru

Pravidla se vyhodnocují ve vzestupném pořadí priority a rozhoduje číslo, ne pořadí, v jakém jste je napsali. Tabulka local je na prioritě 0, tabulka main na 32766 a výchozí pravidlo na 32767, proto pravidlo přidané s výchozí prioritou skončí blízko konce seznamu a prohraje téměř se vším.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Explicitní priorita zviditelní zamýšlené pořadí v souboru i při revizi. Také brání tomu, aby pozdější přírůstek tiše přeskočil existující pravidlo, což je nejčastější příčina toho, že funkční politika přestane fungovat po nesouvisející změně.

Odpovídající pravidlo ukazující na neúplnou tabulku je druhá past. Pokud tabulka 201 obsahuje výchozí trasu, ale žádnou trasu k cíli, paket se zahodí nebo odejde na špatné místo, a pravidlo samo o sobě vypadá naprosto správně. Čtěte tabulku, ne jen pravidlo. Pravidlo je ukazatel a prázdná tabulka je ukazatel do prázdna.

Zpětná cesta stále musí existovat

Politika zdroje volí výstup. Nevytváří zpětnou cestu. Pokud druhý pool odchází přes partnerský tunel, partner musí vědět, jak dosáhnout 172.31.8.0/24, buď trasou zpět na bránu, nebo tím, že dostává přeložené adresy, které už zná.

Volba mezi tím je návrhové rozhodnutí s viditelnými důsledky. Směrování klientského rozsahu zpět zachovává identitu každého klienta u partnera a vyžaduje, aby přijal váš prefix. Překlad skryje pool za jednu adresu a vyžaduje, aby partner přijal jen tuto adresu, za cenu toho, že se vaše a jeho logy už neshodnou na tom, kdo se připojil.

Ať zvolíte cokoli, zapište to vedle definice poolu. Zpětná trasa, která existuje jen v něčí paměti, je přesně ta věc, která přežije, dokud partner nezmění firewall, a pak zabere den ji zrekonstruovat.

Nechytejte vlastní tunel brány do politiky

Pravidla, která píšete pro klienty, platí i pro provoz, který generuje brána, pokud jej nevyloučíte. Široké pravidlo vázané na značku nebo na výstupní rozhraní může zachytit vlastní spojení brány s partnerem, a pak tunel, který politiku nese, je směrován politikou. To vytvoří smyčku nebo výpadek, který vypadá jako závada poskytovatele.

Vymezte každé pravidlo co nejúžeji: prefix zdroje, vstupní rozhraní a tam, kde je to podporováno, značka, kterou nesou jen klientské pakety. Pak po každé změně pravidel otestujte vlastní konektivitu brány, protože závada je sebereferenční a v testu z klienta se neprojeví.

Manuálová stránka ip-rule dokumentuje sémantiku selektoru a priority. Zkombinujte ji s testem vyhledání pro každý pool a návrh se stane ověřitelným, což je rozdíl mezi politickým směrováním, které vydrží rok, a tím, na které se všichni bojí sáhnout.