OpenVPN iroute vagy kernelútvonal: melyik hiányzik?

Egy 10.77.20.0/24 címre menő csomag két külön döntést hoz egy OpenVPN-szerveren: az operációs rendszernek át kell adnia a VPN-interfésznek, és az OpenVPN számára tudnia kell, melyik csatlakozott kliens birtokolja ezt az előtagot. A hiányzó kernelútvonal a tunel előtt ejti el, a hiányzó peer-útvonal utána. A két hiba a távoli LAN felől azonosnak látszik, és annak diagnosztizálása, melyik van Önnél, mindkét oldalon egy-egy parancsot igényel.

A klasszikus felhasználói téri adatútvonalon a kernelútvonal juttatja a csomagot a tunelfolyamatba, és az iroute megmondja annak a folyamatnak, melyik peernek kell fogadnia. Egyik sem helyettesíti a másikat, és a csak az egyiket tartalmazó konfiguráció az első pingig ésszerűnek tűnik.

Két döntés, nem egy útvonal

Képzeljen el egy telephelyek közötti kapcsolatot, ahol a 10.77.20.0/24 egyetlen kliens mögött van. A szerver kernelútvonala, például ip route add 10.77.20.0/24 dev tun0, az illeszkedő csomagokat a tuneleszköznek küldi. Ezután az OpenVPN a saját belső tábláját nézi meg, amelyet a kliens konfigurációs könyvtárában lévő iroute bejegyzésekből épített fel, hogy eldöntse, melyik peer-kapcsolat fogadja őket. Kernelútvonal nélkül a csomag soha nem éri el a folyamatot, peer-útvonal nélkül pedig eléri a folyamatot, és sehová nem megy.

Ezt a felosztást könnyű elfelejteni, mert egyetlen útvonal-sor egy kliensprofilban úgy tűnhet, mintha mindkét feladatot ellátná. Nem látja el: az útvonal kitolása megmondja a klienseknek, mit küldjenek a tunelen át, míg az iroute megmondja a szervernek, ki birtokol egy címteret egy kliens mögött. Külön fájlokban élnek, külön oldalak olvassák őket, és ellentétes irányban hibáznak.

Hová tartozik az iroute, és mit mond

A bejegyzés a kliens common_name neve után elnevezett, kliensenkénti fájlba kerül, a client-config-dir alatt, iroute 10.77.20.0/24 formában. A fájlnév egyezése nem kozmetikai: az OpenVPN megkeresi a hitelesített identitást, és pontosan ezzel a névvel olvassa a fájlt, ezért a site-a nevű fájl csak arra a kliensre hat, amelynek közös neve site-a. Adja hozzá a ccd-exclusive beállítást, ha az ilyen fájllal nem rendelkező klienseket egyenesen el kell utasítani, ami akkor a helyes beállítás, ha minden kliens egy telephelyi átjáró. Átjárónként egy fájlt tartson, és a ténylegesen kiadott tanúsítvány tárgya szerint nevezze el.

Tesztelje a bejegyzést a szerverről, mielőtt a távoli LAN-t hibáztatná. Az állapotfájl felsorolja a csatlakozott klienseket a közös neveikkel, és a --verb 4 kapcsolóval futó szerver naplózza az iroute telepítését, amikor a peer csatlakozik. Ha a csatlakozáskor semmi sem jelenik meg, a fájl rossz könyvtárban van, vagy rossz identitást nevez meg.

A csapda: a fájl megvan, az identitás rossz

A helyesnek látszó, de rossz peerhez kapcsolt iroute több időt pazarol, mint egy hiányzó fájl, mert a lemezen minden rendben lévőnek látszik. A tanúsítványok átnevezése, a duplikált közös nevek és az effektív identitást megváltoztató username-as-common-name mindezt előállítják. Ellenőrizze, melyik identitást hitelesítette a szerver, ahelyett hogy melyiket várta: az állapotkimenet a mérvadó, a fájlnév csak keresőkulcs.

Egy útvonal túlélheti a tulajdonosát. A statikus útvonalak és az iroute bejegyzések előtagot írnak le, nem elérhetőségi garanciát, ezért a forgalom tovább irányulhat egy jelenleg leválasztott peer felé.

Fejezze be az útvonalat a peeren túl

A peer birtoklása az útvonal közepe, nem a vége. A kliensnek továbbítania kell a csomagokat a tunelből a saját LAN-jába, ami azt jelenti, hogy azon a hoston engedélyezett az IP-továbbítás, és egy tűzfal-szabály engedi az átjárást. A távoli LAN hostjainak visszaútra van szükségük a tunel címéhez: vagy az átjáró felé mutató útvonalra, vagy szándékosan tervezett NAT-ra a kliens oldalán. Erősítse meg a továbbítási beállítást a kliensen a sysctl net.ipv4.ip_forward paranccsal, ahelyett hogy a disztribúció alapértékét feltételezné.

Ha más VPN-klienseknek el kell érniük ezt az alhálózatot, az elrendezés újra nő: a szervernek client-to-client kell, és ezeknek a klienseknek az előtagot a tunelen át kell irányítaniuk. Ebből semmi sem következik a szerver saját útvonaltáblájából.

Ellenőrizzen egy célállomást valódi forrásból, ne magától a szervertől. Egy ping egy nem kapcsolódó LAN-hosttól a kliens mögötti hostig egyetlen mozdulatban gyakorolja a visszautat, a továbbítási szabályt és a peer birtoklását, míg egy sikeres kézfogás csak az identitást bizonyítja. Ezután válassza le a birtokló peert, és jegyezze fel, mit tesz az útvonal, mert az a válasz az Ön hibamódja.