Két OpenVPN-alagút egy Linux-gazdagépen: kié az útvonal?

Két profil csatlakozva van, és az egyik csendesen olyan forgalmat visz, amely a másiknak szól. Egy Linux-gazdagép mindkét OpenVPN-klienst futtathatja egyszerre nehézség nélkül. Amit nem tud megtenni, az az, hogy helyetted eldöntse, melyik folyamat melyik előtagot igényelheti. Ezt a döntést még a második alagút felépülése előtt meg kell hozni, nem azután, hogy egy erőforrás abbahagyja a válaszadást.

Kezdje azzal a munkával, amelyet a második kapcsolatnak el kell végeznie

Az egyik profilon elérhető iroda és a másikon elérhető laboratórium esetében mindkét alagútnak fenn kell lennie, és egyiknek sem szabad mindent igényelnie. Egyetlen makacs alkalmazásnak, amelynek a második profilon kell kilépnie, házirend-szabályra van szüksége, nem egy második alapértelmezett útvonalra. Egy tartalék kapcsolatnak egyszerre csak egy futó alagútra van szüksége, ezért a tartaléknak nem kellene a géppel együtt indulnia.

Ez három különböző konfiguráció, és összekeverednek, mert mindhárom ugyanúgy kezdődik: egy második profil és egy sikeres kapcsolat. Először írja le a szándékolt elrendezést, aztán konfiguráljon afelé. Egy mondat a szándékról egy óra csomagrögzítést takarít meg.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Az első parancs a futó példányokat listázza, beleértve azokat is, amelyeket kézzel, a kezelőn kívül indítottak. A második az aktuális alapértelmezett igényt nyomtatja ki, és ez az az állapot, amelyet később meg kell magyaráznia.

Az átfedő poolok az útvonalazás előtt eltörnek

Két szerver vígan oszt ki címeket ugyanabból a 10.8.0.0/24-ből. A kliens ekkor két interfészt tart egy előtagon belül, és semmi sem mondja meg, melyik cél melyikhez tartozik, a kapott viselkedés útvonalhibának tűnik, de valójában számozási hiba. Egy pool újraszámozása egy konfigurációs szerkesztésbe kerül; minden későbbi útvonal-megkerülés egy hétvégébe. Ellenőrizze a poolt, mielőtt útvonalat ad hozzá.

Nézze meg a helyi LAN-t is. Egy 192.168.1.0/24-es otthoni LAN, amelyet az egyik alagút szintén feltár, ugyanazt a kétértelműséget okozza, és a tünet egy hosztnév, amely feloldódik, miközben a kapcsolat soha nem jön létre. Ez névfeloldási hibának tűnik, amíg ki nem nyomtatja az útvonalakat.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Hasonlítsa össze mindkét kimenetet a két szerverkonfigurációval, mielőtt hozzányúl a klienshez. Ha az előtagok átfednek, álljon meg és számozza újra, mert semmilyen újraindítás nem választja szét őket.

Adjon minden profilnak saját egységet és minden előtagnak tulajdonost

Minden profil saját példánynevet és saját konfigurációs fájlt kap, így az office nevű példány az office.conf fájlt tölti be, míg a lab nevű a lab.conf fájlt. Erősítse meg ezt a leképezést a szolgáltatáskezelőn keresztül, ahelyett hogy egy könyvtárlistának hinne, mert egy drop-in megváltoztathatja, melyik fájl töltődik be. A rossz leképezés azt jelenti, hogy azt a profilt hangolja, amelyik nem fut.

Aztán döntse el, ki telepíti az útvonalakat. Amikor a szerverek inkompatibilis készleteket pusholnak, vagy utasítsa el a pusholást és maga listázza az előtagokat, vagy engedje, hogy az egyik profil megtartsa az alapértelmezést, a másikat pedig házirend-szabályokkal irányítsa. Két folyamat, amelyek mindketten alapértelmezettet telepítenek, csendes győztessel és a döntés írásos nyoma nélkül végződik.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Az első megmutatja az egységet minden olyan felülírással, amely megváltoztatja az argumentumait. A második megmutatja, hogy a profil egyáltalán elfogadja-e a pusholt útvonalakat, és ez a kapcsoló dönt minden továbbit.

A jelölések azon az interfészen tartják a válaszokat, ahonnan érkeztek

Amikor minden alagút más forrásokat szolgál ki, egy válasz a rossz kapcsolaton hagyhatja el a gépet, és a kapcsolat meghal az első csomag után. A tartós minta az, hogy a beérkező csomagokat a bemeneti interfész szerint megjelöljük, a jelölést a válaszon visszaállítjuk, és minden jelölésnek saját alapértelmezett átjárós táblát adunk.

A laza fordított útvonal-szűrést általában lazítani kell az érintett interfészeken, mert egy válasz jogszerűen olyan kapcsolaton érkezik, amelyet a fő tábla soha nem választana. Tartsa szűken a jelöléseket, hogy soha ne fogják el az alagutak saját titkosított forgalmát, mert az az alagutat önmagán keresztül küldené.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Olvassa el a meglévő szabályokat, mielőtt újat ad hozzá. A duplikált prioritások és az elfelejtett táblák a szokásos oka annak, hogy egy jelölési házirend teljesen hatástalannak tűnik.

Bizonyítsa az elkülönítést egy kapcsolat leállításával

Mindkét alagút fennállása alatt jegyezze fel minden interfész címét, az egyik hoszt felé vezető útvonalat minden alagút mögött, és azt az utat, amelyet egy független cél vesz. A kerneltől kérje a keresést, ne egyetlen táblát olvasson, mert egy tábla soha nem mutatja a végső döntést.

Aztán állítson le egy példányt, és figyelje, ahogy az interfésze és az útvonalai eltűnnek, miközben a másik tovább működik. A túlélő megszakadása azt jelenti, hogy a kettő még mindig osztozik egy eszköznéven, útvonalon vagy tűzfalszabályon, amelyet senki nem választott szét.

Hozza vissza a leállított profilt, és ismételje meg ugyanezeket az ellenőrzéseket. Amikor egy alagút csak az újraindítás utáni első indítást éli túl, életciklus-hibát lát, nem útvonaltervet.