Access Server átjáró-felhasználó: egy kliens fiók-LAN-jának útvonalazása

Pingelheti egy OpenVPN-kliens alagútcímét, és mégis elérhetetlen marad a mögötte lévő LAN minden gazdagépe. Az Access Server a VPN-készletből ad címet a kliensnek, és a készlet címe minden, amit a kiszolgáló a sajátjaként ismer. A fiók előtagja külön tény, amelyet deklarálni kell, és még ekkor is kell a fióknak egy továbbító, a központnak pedig egy visszaútvonal. A rossz helyre beírt útvonal megoldásnak látszik, és semmit nem változtat.

Két cím, két különböző tulajdonjogi igény

Amikor a kliens csatlakozik, az Access Server címet ad neki a beállított VPN-készletből, például 10.90.0.0/24. Ez a kiosztás egyetlen gazdagép bérlete. A kapcsolat semmit nem mond arról, hogy ugyanaz a kliens a 10.60.0.0/24 előtt is áll, és a kiszolgáló nem találgat: egy LAN-előtag csak akkor érhető el egy adott kliense keresztül, ha egy adminisztrátor deklarálja.

Ezért nem működik egy statikus útvonal egy másik gépen. Az útvonal azt mondja, küldd a 10.60.0.0/24-et erre a címre, de ha a cím olyan kliensé, amelyet soha nem jelöltek átjárónak, a kiszolgálónak nincs oka ezeket a csomagokat oda kézbesíteni, és a kliens verme eldobhatja őket. A deklaráció és az útvonal egy mechanizmus két fele.

Mit telepít valójában az átjáró beállítás

Az Admin Web UI-ban a deklaráció felhasználói tulajdonság: kapcsolja be a Configure VPN gateway beállítást a connector felhasználón, és írja be a fiók valódi előtagját a Network on the VPN client side mezőbe. Ez a felhasználó ugyanúgy hitelesít, mint bármelyik más, ezért felügyelet nélküli eszközhöz illő hitelesítőadat-szabályzat kell neki, és az automatikus bejelentkezési profilja titok, nem kényelmi fájl.

A jelölőnégyzet mögött a kiszolgáló az előtagot a kliens készletcímén keresztül elérhetőnek tekinti, és az Access Controls alatti útvonalazási konfiguráció dönti el, mit hirdetnek a többi kliensnek: a normál klienseknek küldött útvonalakat és azokat a hozzáférési szabályokat, amelyek engedik a forgalmat a központ hálózataiból a klienscímekre és alhálózatokra. Kapcsolja be az útvonalazást azokra a hálózatokra, amelyeknek el kell érniük a fiókot, és tartsa rövid az engedélyezett listát.

A generált fájlba illesztett Community stílusú direktíva nem vesz részt ebben a modellben. A termék birtokolja a küldött útvonalazási táblát; a kézzel szerkesztett sor a következő generáláskor felülíródik vagy figyelmen kívül marad.

Fejezze be mindkét hálózat visszaútvonalát

Konkrét terv: központ 10.40.0.0/24, fiók 10.60.0.0/24, VPN-készlet 10.90.0.0/24, és az Access Server egy privát címen érhető el a központ oldalán. A központ útválasztójának útvonalakra van szüksége a fiók előtagjához és a készlethez, mindkettő az Access Server felé. Ezek nélkül az alagút viszi a kérést, és a válasz az alapértelmezett átjárón keresztül távozik, ami a klasszikus félig nyitott kapcsolatot adja.

A fiókban a connectornek továbbítania kell a nem hozzá címzett csomagokat: IP-továbbítás az operációs rendszerében, valamint az alagútra és a LAN-interfészekre korlátozott továbbítási engedély; Linuxon ez a net.ipv4.ip_forward=1 a forward lánc szabályaival, Windowson a routing and remote access. Ezután a fiók gazdagépeinek visszaútvonal kell: vagy a connector az alapértelmezett átjárójuk, vagy a meglévő átjáró viszi a központ és a készlet előtagjainak konkrét útvonalait.

A connector saját útvonalazási táblája nem konfigurálja újra a fiók LAN-jának minden gazdagépét. Ha a gazdagépek másik útválasztóra mutatnak, a visszaútvonalak oda tartoznak, és annak el kell fogadnia, hogy a látott forráscím nem a helyi alhálózat szomszédja.

Olvassa a hibát útvonalként, ne engedélyként

Teszteljen rögzített sorrendben. Először egy engedélyezett szolgáltatás az Access Servertől a fiók egy gazdagépéhez, majd ugyanaz a szolgáltatás egy közönséges központi gazdagépről, majd az ellenkező irány, ha a szabályzat engedi. Ha az első átmegy és a második nem, a küldött útvonalak vagy a hozzáférési szabályok a hibásak. Ha mindkettő átmegy, de válasz nem érkezik, vizsgálja a fiókbeli továbbítást és a központi visszaútvonalat.

A gazdagép tűzfala a következő gyanúsított, mert útvonalazott hozzáférésnél a cél a központ vagy a készlet címét látja forrásként. A helyi alhálózatra írt szabály nem fog egyezni, és a csomag eldobódik, miután az útvonalazás tökéletesen működött.

Két terv többet igényel. A telephelyek közötti átfedő előtagok kétértelművé teszik a célt, és újraszámozást vagy fordítást igényelnek, a klaszterezett Access Server pedig minden csomóponttól működő utat kíván a fiók connectorához, nem egy csomópontot, amely az útvonalat tartja. A változtatásokat a termék szokásos mentési és frissítési útvonalán alkalmazza, csatlakoztassa újra a connectort, és ellenőrizze újra mindkét végpontról; minden gép teljes újraindítása nem része az eljárásnak.

Az Access Server site-to-site útmutatója ugyanezeket a beállításokat sorolja fel terméksorrendben; érdemes egyszer követni, mielőtt a tervet a saját előtagjaihoz igazítja.