Forrásalapú útválasztás két VPN-poolhoz: mit hagy ki a szabálya

Két klienspool, egy átjáró, és a terv triviálisnak látszik: az egyik szabály a gyors uplinkre küldi az első poolt, a másik a partneralagúton át a másodikat. Aztán a szabályok a helyükön vannak, és a második pool továbbra is az alapértelmezett útvonalon megy ki. A szabály nincs elrontva. A csomag forrása nem az, amire a szerző a keresés pillanatában számított, mert a fordítás és a keresés ugyanazon csomag útjának különböző pontjain történik, és a sorrend ellentétes azzal a mentális ábrával, amit a legtöbben rajzolnak.

A keresés a forrás átírása előtt történik

A VPN-kliensről továbbított csomagnál a kernel rögzített sorrendet futtat. A csomag megérkezik az alagút interfészre, áthalad a preroutingen, ahol a conntrack és a DNAT él, majd megszületik az útválasztási döntés, majd a továbbítás, majd a postrouting, ahol az SNAT utolsóként érvényesül. Az from alakú szabályt ez alatt az útválasztási döntés alatt nézi meg a rendszer, azaz a kliens eredeti címét látja, nem a lefordítottat.

A masquerade-szabály hozzáadása tehát nem változtatja meg, melyik házirend illeszkedik a kimenő folyamra. Amit megváltoztat, az az, amit a távoli vég lát, és ezáltal az, milyen visszaút létezik. Ez két külön következmény, és a változásfelülvizsgálatok folyton összekeverik őket. Válasszuk szét őket, és a terv általában egy percen belül nyilvánvalóvá válik.

A válaszirányban jelenik meg a lefordított cím a szabályokban. Az átjáróhoz visszatérő csomag a lefordított címre van címezve, és ha vannak cél vagy a belépő interfész alapján működő házirend-szabályok, akkor azt az értéket fogja egyeztetni. Ugyanaz a kapcsolat, irányonként más igazságforrás.

A két különböző forrású poolnak tehát valóban külön táblákra van szüksége, és a terv helyes. Amit a fenti táblázat kizár, az az a rövidítés, hogy a hibakeresés a távoli oldal által kapottak megfigyelésével és a szabály abból való kikövetkeztetésével történjen.

Az átjáróról indított teszt nem a pool tesztje

Az átjáró által maga generált forgalom soha nem halad át a preroutingen, mert nem egy interfészen érkezett. A kimeneti útvonalon kerül átirányításra, forrásként az átjáró saját címével, és a kliens tartományra épülő from szabály nem fog illeszkedni. Ezen a területen minden jegy, amely szerint a dobozról működik, a kliensről nem, ugyanennek a ténynek az ismétlése.

Szimulálja a klienst ahelyett, hogy közelítené. Az útválasztási keresés közvetlenül kérdezhető, forrás és belépő interfész megadásával:

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

Futtassa poolonként egyszer. Ha a két parancs ugyanazt az interfészt adja vissza, a szabályok nem választják szét a poolokat, és az ok vagy egy hiányzó szabály, vagy egy mindkettőre illeszkedő magasabb prioritású szabály. Ha különböző interfészeket adnak vissza, de a kliens továbbra is hibázik, a hiba a keresés után van, és abbahagyhatja a szabályok vizsgálatát.

Prioritás, nem pozíció a fájlban

A szabályok növekvő prioritási sorrendben értékelődnek, és a szám számít, nem az, ahogy begépelte őket. A local tábla a 0 prioritáson, a main tábla a 32766-on, az alapértelmezett szabály pedig a 32767-en van, ezért az alapértelmezett prioritással hozzáadott szabály a lista vége felé kerül, és szinte mindentől kikap.

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

A kifejezett prioritás láthatóvá teszi a szándékolt sorrendet a fájlban és a felülvizsgálatban. Azt is megakadályozza, hogy egy későbbi kiegészítés csendben egy meglévő szabály elé ugorjon, ami a leggyakoribb oka annak, hogy egy működő házirend egy nem kapcsolódó változtatás után leáll.

A hiányos táblára mutató illeszkedő szabály a másik csapda. Ha a 201-es tábla tartalmaz alapértelmezett útvonalat, de a cél felé nem, a csomag eldobásra vagy rossz helyre küldésre kerül, és a szabály izoláltan teljesen helyesnek látszik. A táblát olvassa, ne csak a szabályt. A szabály egy mutató, és az üres tábla a semmibe mutató mutató.

A visszaútnak mégis léteznie kell

A forrás-házirend kiválaszt egy kijáratot. Nem hoz létre visszautat. Ha a második pool a partneralagúton át lép ki, a partnernek tudnia kell, hogyan érje el a 172.31.8.0/24-et, vagy visszafelé vezető útvonallal az átjáróhoz, vagy olyan lefordított címek fogadásával, amelyeket már ismer.

A kettő közötti választás látható következményekkel járó tervezési döntés. A kliens tartomány visszairányítása megőrzi az egyes kliensek identitását a partnernél, és megköveteli, hogy elfogadja a prefixét. A fordítás elrejti a poolt egyetlen cím mögé, és megköveteli, hogy a partner csak azt a címet fogadja el, azon az áron, hogy az ön és az ő naplója már nem ért egyet abban, ki kapcsolódott.

Bármit is választ, írja le a pool definíciója mellé. A csak valaki emlékezetében létező visszaút pontosan az a dolog, ami addig él, amíg a partner nem módosít egy tűzfalat, és utána egy napot vesz igénybe az újjáépítése.

Ne fogja meg az átjáró saját alagútját a házirendben

A klienseknek írt szabályok arra a forgalomra is vonatkoznak, amit az átjáró generál, kivéve ha kizárja. Egy jelölésre vagy a kimeneti interfészre épülő széles szabály elkaphatja az átjáró saját kapcsolatát a partnerhez, és akkor a házirendet szállító alagutat a házirend irányítja át. Ez hurkot vagy kiesést okoz, amely szolgáltatói hibának látszik.

Szűkítse minden szabályt a lehető legjobban: forrás-prefix, belépő interfész és ahol támogatott, olyan jelölés, amelyet csak klienscsomagok hordoznak. Utána minden szabályváltozás után tesztelje az átjáró saját kapcsolatát, mert a hiba önmagára hivatkozó, és kliensoldali teszten nem jelenik meg.

Az ip-rule kézikönyvoldala dokumentálja a szelektor és a prioritás szemantikáját. Kombinálja poolonkénti keresésteszttel, és a terv ellenőrizhetővé válik, ami a különbség az egy évig kitartó házirend-útválasztás és aközött, amit mindenki fél megérinteni.