Miért nem érhető el az OpenVPN-ügyfél mögötti alhálózat?

A szerver tunelcímére küldött pingek sikeresek, az ügyfél saját útvonaltáblája helyesnek tűnik, és az ügyfél mögötti LAN továbbra is elérhetetlen. Az ügyfél útvonaltáblája helyesnek tűnik, a szervernek van a tunelre mutató útvonala, és a csomagok mégis eltűnnek. Ez egy layer-3 tunel klasszikus tünete, amely nem tudja, hogy az egyik ügyfele egyben átjáró is.

A tun interfésznek nincs ügyfelenkénti következő ugrása. A kernel egyetlen interfészt lát sok partnerrel, ezért azt a döntést, hogy melyik ügyfél kapjon csomagot egy távoli LAN felé, az OpenVPN folyamaton belül kell meghozni. Ezt a döntést iroute konfigurálja, és nélküle a csomagnak nincs hová mennie.

A szerver ügyfél szerint irányít, nem interfész szerint

Amikor a szervernek csomagot kell küldenie egy ügyfél tunelcímére, a válasz egyértelmű: a cím az adott ügyfél munkamenetéhez tartozik. Amikor a cél az ügyfél mögötti teljes alhálózat, a cím senkihez nem tartozik, akit a szerver ismer, és a kernel tunelre mutató útvonala csak annyit mond: "ezen az interfészen át", anélkül hogy megmondaná, melyik partner.

OpenVPN ezt belső útvonaltáblával oldja meg, amely egy cél-előtagot adott ügyfélhez rendel. Ez a tábla iroute-bejegyzésekből épül fel, ezért a szerver gazdagépén egy egyszerű útvonal nem elég. A kernel útvonala eljuttatja a csomagot a tunelinterfészhez; a belső hozzárendelés dönti el, melyik munkamenet kapja meg. Ezért sem jelenik meg a javítás soha a kernel útvonalkimenetében.

Ha a hozzárendelés hiányzik, a csomag megérkezik a szerverhez, illeszkedik a tunelútvonalhoz, és eldobják, mert egyetlen ügyfél sem igényli a célt. Semmi sem naplóz tiszta hibát, ezért a hiba csendes fekete lyuknak tűnik, nem irányítási huroknak.

Az ügyfelet megnevező iroute-bejegyzés megírása

Az iroute ügyfélspecifikus konfigurációs fájlban él, nem a szerver fő konfigurációjában. Irányítsa a szervert egy könyvtárra a client-config-dir beállítással, majd hozzon létre egy fájlt, amelynek neve az ügyfél tanúsítványának közös neve, és tegye bele az előtagot.

Egy fióktelep esetében, amelynek LAN-ja 10.20.0.0/24, és amelynek tanúsítvány-közös neve branch-router, az adott útvonalon lévő fájl egy ilyen sort tartalmaz: iroute 10.20.0.0 255.255.255.0. A fő konfigurációnak csak a könyvtárbeállításra van szüksége; az előtag az ügyfélnél él.

A közös név a törékeny rész. Egy más subjecttel kiállított tanúsítvány, vagy olyan telepítés, amely a felhasználókat felhasználónév alapján hitelesíti, miközben a fájl a tanúsítványról van elnevezve, olyan fájlt eredményez, amelyet soha nem olvasnak. Ellenőrizze, milyen nevet jelent a szerver ténylegesen a munkamenethez, és fontolja meg azt a beállítást, amely a nem illeszkedő ügyfelet meghiúsítja ahelyett, hogy csendben, útvonalai nélkül csatlakozna. A fájl átnevezése a tanúsítványhoz ötperces javítás, amely egy nagyon hosszú estét előz meg.

Egy ügyfél több előtagot is birtokolhat. Adjon hozzá egy iroute-sort hálózatonként, és tartsa a listát az adott ügyfél többi beállítása mellett, hogy a hozzárendelés ellenőrizhető maradjon.

A visszatérő útvonal kiépítése mindkét irányban

A csomagok eljuttatása a távoli LAN-ra a munka fele. Az ügyfélnek a LAN forgalmát is a tunelbe kell küldenie, ami általában útvonal ügyfélhez történő küldésével történik: egy ilyen sor, mint push "route 10.8.0.0 255.255.255.0", minden ügyfélnek megmondja, hogyan érje el a szerveroldali hálózatot. A fióktelep esetében az egyenértékű útvonal a tunelre mutat mindenhez, amit a szerveroldalon el kell érnie.

A visszirányhoz tulajdonos kell a távoli oldalon. Ott valakinek ismernie kell a visszautat: statikus útvonal a LAN routerén, amely a VPN-poolt a szerverre irányítja, vagy címfordítás a szerveren, mielőtt a forgalom belép a LAN-ba. A statikus útvonal láthatóan megtartja az eredeti címeket a naplókban és hozzáférési szabályokban, de a LAN tulajdonosának együttműködését igényli; a fordítás önálló, de elrejti, ki csatlakozott valójában.

A továbbítást engedélyezni kell a szerver gazdagépén. Enélkül a kernel elfogadja a csomagot a tunelből, és megtagadja átadását a LAN-interfésznek, ami az ügyfél szempontjából pontosan úgy néz ki, mint egy hiányzó iroute.

Az elérhetőség ellenőrzése a megfelelő próbákkal

Rétegenként teszteljen ahelyett, hogy a távoli végpontot pingelné és találgatna. A szerverről ellenőrizze, hogy létezik az előtag belső hozzárendelése, és hogy a kernel útvonala a tunelre mutat. Az ügyféltől erősítse meg, hogy a küldött útvonal telepítve van, és hogy a LAN-cím felé vezető alapértelmezett útja a tunel.

Utána figyelje a csomagokat. A tunelinterfészen végzett rögzítés megmutatja, hogy a szerver az ügyfél felé továbbít-e, a LAN-interfészen végzett rögzítés pedig azt, hogy továbbít-e. Ha az első csomagokat mutat, a második semmit, akkor a továbbítás vagy egy szűrő a probléma; ha egyik sem mutat semmit, a keresés korábban hiúsult meg.

Két tunellel összekötött szerver mindkét oldalon ugyanazt a szabályt ismétli: mindegyiknek kell egy iroute a másik pooljához, és mindegyiknek kell az az útvonal és továbbítás, amely szimmetrikussá teszi az utat. Az irányítás és a szabályzat itt külön kérdés. Az irányítás eldönti, hová mehet a csomag, míg egy FORWARD-szabály eldönti, szabad-e, így a két iroute-sorral rendelkező ügyfél mindkét előtagot eléri, hacsak egy szűrő másként nem rendelkezik.