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

Mindkét profil kapcsolódott állapotot jelent, és az egyik csendben a másiknak szánt forgalmat továbbítja. Két kliens egy gazdagépen támogatott elrendezés; két kliens gazda nélkül minden előtaghoz nem az. A munka kevésbé a második tunel felhozásáról szól, és inkább arról, hogy melyik folyamat jogosult melyik útvonalat igényelni. Járja végig az alábbi sorrendet, és a konfiguráció a válaszokból következik.

Kezdje azzal a kérdéssel, mire való a második tunel

Három helyzet néz ki ugyanúgy az állapotsoron, és különböző terveket igényel. A cél szerinti felosztás az egyik előtagot az irodai profilon, a másikat a laborprofilokon keresztül küldi, és egyik sem igényel alapértelmezett útvonalat. Az alkalmazásonkénti felosztás általában egy teljes tunelt tart meg, és bizonyos forgalmat házirend-szabályokkal irányít. A feladatátvétel egyszerre pontosan egy tunelt tart fenn, ami azt jelenti, hogy a másodiknak nem szabad automatikusan indulnia.

Írja le az esetet, mielőtt bármilyen konfigurációs fájlt megnyitna, mert az a válasz dönt el mindent, ami utána jön.

A leggyakoribb elromlott elrendezés két teljes tunel, amelyek mindketten alapértelmezett útvonalat toltak, ahol az utoljára csatlakozó nyer, az első pedig tovább színleli. Ez az állapot szándékosnak tűnik az állapotsorról, és egy napot pazarol el az útválasztási táblázatból. Ha az esetet először megnevezi, lehetetlenné válik, nem csupán valószínűtlenné.

Nézze meg a poolokat az útvonalak előtt

Két kiszolgáló könnyen oszt címeket egyetlen privát tartományból, és amikor ezt teszi, az ügyfél két interfésszel marad egyetlen előtagon belül. Akkor egyetlen cél sem rendelhető interfészhez cím alapján, mert mindkettő egyformán helyesnek tűnik. Számozza újra az egyik poolt, ahelyett hogy szabályt találna ki a holtverseny feloldására.

Ellenőrizze a helyi hálózatot is, mert az otthoni vagy irodai LAN, amely átfed egy tuneltartománnyal, ugyanazt a kétértelműséget teremti a másik oldalról. Hasonlítsa össze a gazdagépen lévő címeket mindkét kiszolgáló konfigurációjával, mielőtt az ügyfelet hibáztatná. A pool módosítása egy labor-kiszolgálón ötperces javítás, míg az átfedő előtag házirend-alapú útválasztási kerülőútja állandó teher mindenkinek, aki később olvassa a konfigurációt. Döntse el, melyiket szeretné, mielőtt kiválasztja, hol avatkozzon be.

Két címcsalád ennek az ellenőrzésnek két fordulóját jelenti. Az IPv6-poolok ugyanolyan csendesen ütköznek, mint az IPv4-esek.

Adjon minden profilnak gazdát

Egy instance profilonként, egy konfigurációs fájl instance-onként és egy név, amely azonosítja a párt. A Debian-stílusú csomagolásban az @ jel utáni név választja ki a fájlt, ezért két profil, amely ugyanazt az instance-nevet használja, soha nem működhet mindkettő. Erősítse meg a leképezést a telepített egységből, nem egy útmutatóból.

systemctl cat [email protected]
ip -4 addr show

Utána döntse el, ki telepíti az útvonalakat, ami házirend-kérdés, nem szintaxis-kérdés.

Amikor a két kiszolgáló összeférhetetlen készleteket tol, vagy adjon hozzá route-nopull és csak azokat az előtagokat sorolja fel, amelyekre minden profilnak szüksége van, vagy hagyja, hogy az egyik megtartsa alapértelmezett útvonalát, és irányítsa a többit házirend-szabállyal. Két folyamat, amely mindkettő alapértelmezett útvonalat telepít, egyetlen győztessel végzi, és senki sem tudja megmondani, miért. Amint a két tunel különböző források forgalmát viszi, egy válasz a rosszon keresztül távozhat, és a minta, amely kiállja, egy kapcsolatjelölés, amely a válaszokon visszaáll, és a saját táblájába irányul. Korlátozza a jelöléseket, hogy a tunelek saját titkosított csomagjai soha ne illeszkedjenek rájuk.

Ellenőrizze tunelenként, majd állítson le egyet

Amikor mindkettő fent van, vegyen három mérést: a címet minden tuneleszközön, az útvonalat egy gazdagéphez, amely mindegyik mögött él, és az utat, amelyet a kettőn kívüli cél választana. Egy egyszerű útvonallista megszűnik a végső keresés leírásáról, amint szabályok kerülnek játékba, ezért kérdezze meg a kernelt, mit választana valójában. Utána állítson le egy instance-t, és nézze, mi tűnik el. Ha az első leállítása zavarja a másodikat, még mindig közös köztük valami: egy útvonal, egy eszköznév vagy egy tűzfal-szabály, amelyet senki sem választott szét.

ip rule show
ip route get 203.0.113.9

Hozza vissza a leállított profilt, és ismételje meg ugyanazokat az ellenőrzéseket, mert egy tunel, amely újraindítás után egyszer működik, és soha többé, útválasztási jelmezbe öltözött életciklus-hiba.

Jegyezze fel a telepítési feljegyzésekben, melyik profil melyik előtagot birtokolja, a pooltartományok mellett. Két tunel szándékos elrendezés, és a következő olvasónak látnia kell a határt, mielőtt bármelyik profilhoz nyúl. E feljegyzés nélkül a határt újra felfedezi az, aki ügyeletben van, amikor a közös előtag végül eltörik.