Ugyanaz a szerver IP, két útvonal: az OpenVPN külső folyamának megjelölése

A szokásos hurokvédelem egy gazdagép-útvonal: a VPN-kiszolgáló nyilvános címére irányuló forgalmat az uplink felé küldi, hogy a titkosított munkamenet soha ne kerüljön a saját belső csatornájába. Ez egészen addig működik, amíg ugyanazon a kiszolgálón egy webes szolgáltatást is el akar érni a belső csatornán keresztül, mert a kivétel a célhoz kötődik, a cél pedig ugyanaz. A kiút, hogy felhagy a cél szerinti osztályozással, és elkezd a szerint osztályozni, melyik foglalat küldte a csomagot.

Kezdje a két folyammal, amelyeket szét akar választani

Az egyik folyam maga a titkosított OpenVPN-átvitel, amelynek az uplink felé kell kilépnie, különben a belső csatorna a saját külső kapcsolatát szállítaná. A másik egy hétköznapi HTTPS-kérés ugyanarra a nyilvános címre, amelyet a belső csatornán belül szeretne, hogy a szolgáltatáshoz belső csatorna forrásából érkezzen. Ugyanaz a cél, sok esetben ugyanaz a portszám, más szükséges útvonal.

Ebben az áttekintésben tegyük fel, hogy az ügyfél a 10.90.0.10 címen van a tun1 felett, a kiszolgáló nyilvános címe 198.51.100.25, és a fő tábla érintetlen, alapértelmezett útvonala a szokásos uplinkre mutat. A kiszolgáló oldalának a belső útvonalon is fogadnia kell a webes szolgáltatást, és vissza kell küldenie a forgalmat a belső csatorna forrásához; attól, hogy egy csomagot nyilvános címre küld, a kiszolgáló figyelője vagy tűzfalszabálya nem változik meg.

Mielőtt bármit módosítana, rögzítse a gazdagép jelenlegi szabályait, és válasszon olyan értékeket, amelyeket senki más nem használ: egy jelölést, egy táblaszámot és három szabályprioritást. Tartson fenn egy visszautat a géphez, amely nem ezen a kapcsolaton keresztül vezet, mert az itteni hiba a saját távoli hozzáférését szünteti meg, nem csak egy böngészőlapot tesz tönkre.

Jelölje meg a foglalatot, amely a borítékot szállítja

Az ügyfélkonfiguráció jelölést kap a titkosított kimenő csomagjaihoz, és felhagy a saját útvonaltelepítéssel, így a helyettesítő házirend lesz az egyetlen, amely az útvonalakat meghatározza:

mark 42
route-noexec
disable-dco

A tízes számrendszerű 42 a tizenhatos számrendszerű 0x2a, és az útválasztási szabályok éppen a tizenhatos alakot fogják egyeztetni. A link-options leírása a mark-ot úgy írja le, mint ami a titkosított kimenő csomagokra vonatkozik Linuxon, azaz éppen arra a foglalatra, amelynek az útvonalát kezelnie kell. Az adatcsatorna-tehermentesítés kikapcsolása ezt a példát a felhasználói tér útvonalán tartja, ahol a jelölés viselkedése a leírt.

A route-noexec elnyomja az OpenVPN automatikus útvonal-hozzáadását és -törlését. Helyettük semmit nem telepít, ezért ettől a pillanattól az útvonalak tulajdonosának minden, a belső csatorna által igényelt útvonalat fenn kell tartania. Ha egy privát cél eltűnik a változtatás után, az a hiányzó helyettesítő házirend, nem a jelölés hibája.

Ne tartson fenn gazdagép-útvonalat a fő táblában a 198.51.100.25 címhez, miközben ezt teszi. Az ilyen útvonal éppen azt a kivételt hozza vissza, amelyet a terv szűkíteni próbál, és a HTTPS-folyam esetében nyerni fog, mielőtt az alábbi házirendek bármelyikét megkérdeznék.

Minden mást küldjön a belső csatorna táblájába

Amint a belső csatorna interfésze létezik és tartja a címét, a házirend így néz ki:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Az első szabály láthatóvá teszi a gazdagép konkrét útvonalait, beleértve bármely jóváhagyott helyi hálózatot, miközben a fő tábla alapértelmezett útvonalát láthatatlanná teszi e keresés számára. Ez a különbség számít: az alapértelmezett elnyomása nem ugyanaz, mint a tábla figyelmen kívül hagyása, és a helyi kivételek, amelyekre még szüksége van, éppen emiatt maradnak meg. Olvassa át ezeket a kivételeket egyenként, ahelyett hogy feltételezné, hogy az eredmény egyetemes vészleállító kapcsoló.

A jelöletlen forgalom ezután a belső csatorna táblájára esik, felveszi a belső csatorna forrását, és a VPN-en keresztül távozik. A megjelölt forgalom elbukik az fwmark-teszten a következő két szabályon, és továbbhalad a lista alacsonyabban fekvő szokásos fő kereséséhez, ahol az uplink alapértelmezett útvonala még mindig ott van. A záró unreachable-szabály az, ami megakadályozza, hogy egy jelöletlen folyam csendesen visszaessen az uplinkre, amikor a belső csatorna útvonala hiányzik. A szelektor az elejétől a végéig a jelölés, és a célcím soha nem kerül a döntésbe.

Tartsa ezt az őrt a helyén a kapcsolódások között, és a többi házirenddel együtt telepítse, ne kézzel. Az a szabály, amely az interfésszel együtt eltűnik, nem házirend, hanem véletlen. A házirend törlése a belső csatorna kiesésekor a hiba módját „blokkolt”-ról „szivárgó”-ra változtatja, és egy elavult, később lejáró belső csatorna-útvonal sokkal könnyebben megmagyarázható probléma, mint a rossz interfészen kilépett forgalom.

Lássa a visszaút ugyanazt a jelölést

A kimenő jelölések csak a mechanizmus felét teszik ki, és ez az a rész, amelyet a legtöbb reprodukció kihagy. A titkosított munkamenetre érkező válaszok az uplinkon érkeznek, és visszaútvonal-ellenőrzés alá esnek, amely azt kérdezi, hogy a forrás ugyanazon az úton lenne-e visszairányítva. Segítség nélkül ez a keresés az Ön jelöletlen belső csatorna házirendjét alkalmazza, és arra jut, hogy a csomag a rossz interfészen van.

A javítás a tűzfal tulajdonosáé: mentse el a jelölést a kimenő kapcsolaton, állítsa vissza a megfelelő bejövő csomagokon, és engedélyezze a forrás által ellenőrzött jelöléskezelést az érintett útvonalon. Az, hogy az OpenVPN foglalatjelölést állít be, egyiket sem teszi meg a három közül, és az a recept, amely csak az ügyfélbeállításokat sorolja fel, hiányos. Kérje írásban ezt az integrációt, mert ez a terv legkevésbé látható része, és ezt a legkönnyebb elveszíteni egy újjáépítés során.

A laza visszaútvonal-ellenőrzés sem helyettesítő. A laza módnak továbbra is léteznie kell valamilyen útvonalnak a forráshoz, és az Ön által hozzáadott unreachable-őr szándékosan eltávolít egyet a jelöletlen keresésekhez. Fejezze be és vizsgáltassa felül a kapcsolatjelölés integrációját, mielőtt erre a tervre támaszkodna, és kezelje a gazdagépszűrőket külön kérdésként: a jelölés útválasztási jelzés, nem engedély. Ha az integráció hiányzik, a tünet egy munkamenet, amely létrejön, majd elhallgat, amint a válaszok elkezdenek érkezni.

Bizonyítsa két útvonalkereséssel

Hasonlítsa össze, mit dönt a kernel a két kontextusban, és a dev és src mezőket olvassa, ne a kilépési állapotot:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Az első keresésnek a tun1-re kell feloldódnia a belső csatorna forrásával, a másodiknak pedig az uplinkre. Ezek szintetikus keresések, ezért a házirendet bizonyítják, nem a futó folyamatot: külön erősítse meg a futó ügyfél tényleges átviteli útvonalát, majd tegyen valódi HTTPS-kérést bekapcsolt tanúsítvány-ellenőrzéssel.

Írja le, mit nem fed le a terv, mielőtt késznek nyilvánítja. A DNS, az IPv6 és a szabályok életciklusa külön-külön döntést igényel, és ez egy IPv4-es útválasztási példa, nem teljes adatvédelmi konfiguráció. Az értéke a szelektor: a boríték megkapja az uplink kivételét, és az ugyanazon a címen futó hétköznapi szolgáltatásnak nem kell örökölnie azt.