OpenVPN-kiszolgáló és -kliens egy hoszton: miért esnek ki a kliensek

Adjon hozzá kliensprofilt egy géphez, amelyen már fut VPN-kiszolgáló, és az első áldozat az eredeti szolgáltatás lesz. Az új alagút talán soha nem jön létre, vagy feljön, miközben a kiszolgáló meglévő kliensei csendesen abbahagyják a válaszok fogadását. Két ütközés adja mindkét eredményt: egy már használatban lévő alagútkészlet, és egy új alapértelmezett útvonal, amelyet az új kliensfél telepít, és amely az egész táblát lefedi. Egyik sem ad OpenVPN-hibaüzenetet, ezért a hibát kiszolgálóproblémának olvassák.

Egy gép, két szerep, és két összeegyeztethetetlen válasz arról, hova menjenek a válaszok.

Ugyanaz a készlet, két kiszolgáló: melyik nyer

Minden kiszolgálópéldánynak saját alagút-alhálózatra van szüksége. Egy olyan sor, mint a server 10.8.0.0 255.255.255.0, a második konfigurációba másolva ugyanazt az előtagot adja a két példánynak, és az eredmény vagy az indítás megtagadása, vagy csendes versengés, amelyben az egyik kiszolgáló kliensei olyan címeket kapnak, amelyeket a másik is a sajátjának hisz. A különböző UDP-portok és az eltérő eszköznevek nem segítenek, mert egyik sem nyúl a címterülethez. Módosítsa a második készletet, és módosítsa mindenhol, ahol az útvonalak említik.

Sorolja fel, mi él, mielőtt szerkesztene: a ip -4 addr show listázza az alagúteszközöket, a ss -lunp listázza a hallgatókat, a systemctl list-units pedig megnevezi az egységeket. Az alagútcímekre vetett egyetlen pillantás eldönti, ütköznek-e a készletek.

Mit ad hozzá a kliensprofil a táblához

A kliensfél azonnal írja az útvonalakat, amint csatlakozik. A redirect-gateway def1 kettéosztja az alapértelmezett útvonalat 0.0.0.0/1 plusz 128.0.0.0/1-re, mindkettő az új eszközön keresztül halad, együtt egy hosztútvonallal a távoli kiszolgáló felé, amelyet szándékosan a fizikai interfészhez rögzített. Ez a rögzítés azért van, hogy az alagút megtartsa saját átvitelének útvonalát. Minden más, beleértve azokat a válaszokat, amelyekkel a helyi kiszolgáló a saját klienseinek tartozik, most az új alapértelmezést követi, és a távoli kapcsolaton keresztül távozik.

Tehát a második ütközés nem törött alagút. Ez egy működő alagút a tábla rossz helyén.

Három mód a szerepek szétválasztására

A legkevésbé invazív javítás kiveszi az alapértelmezett útvonalat a kliensprofilból: route-nopull plusz kifejezett route-sorok a távoli előtagokhoz, így a helyi tábla csak ott változik, ahol kérte. A következő lépés egy házirend-szabály, amely mentesíti a helyi alagút-alhálózatot, hagyva, hogy a helyi klienseknek szóló válaszok azon az interfészen távozzanak, amelyen érkeztek, akkor is, ha létezik alapértelmezett útvonal. A legalaposabb megoldás egy külön hálózati névtér a kliensszerep számára, amely teljesen eltávolítja a megosztott táblát, és egy második útválasztási környezet fenntartását igényli.

Bármelyik utat választja, a kivételnek a helyi alagút-alhálózatot kell megneveznie, nem a LAN-t. A helyi kiszolgáló által küldött válasz célja egy alagútcím, ezért a LAN alakú kivétel soha nem illik rá.

Melyik példány a hibás

Állítsa le a klienspéldányt, és tesztelje újra az eredeti klienseket. Az azonnali helyreállás útválasztást jelent, nem kiszolgálót. Hozza vissza a klienst, és kövessen egyetlen választ a ip route get segítségével, amelynek forrás- és céltcímet is megadtak, ami megmutatja, melyik utat választaná a kernel, majd figyelje meg a tcpdump -ni any port 1194 segítségével, melyik interfészt használják valójában a csomagok. A kiszolgáló állapotfájlja, amelyet néhány másodpercenként a status direktíva ír, tartalmazza a csatlakozott kliensek listáját és a bájtok számlálóit mindkét irányban.

Olvassa ezeket a számlálókat egymással szemben. A forgalom, amely elmegy és soha nem jön vissza, útválasztási válasz, nem kézfogási probléma.