Üzemeltetési útmutató: két OpenVPN-ügyfél külön bevezetése

Két ügyfél egy gazdagépen úgy hangzik, mint még egy szerverblokk és egy második port. Más projektté válik, amint felsorolod mindazt, ami egy ügyfélnek valóban a birtokában van: listener, tunnel pool, identitás, bizalmi fájlok, útvonalak és visszavonási ütemterv. Ha egyet kihagysz, a második ügyfél csendesen örököl egy darabot az elsőből. Készíts kártyát minden ügyfélhez, és töltsd ki, mielőtt az első kliens csatlakozik.

Rendelj teljes erőforrás-kártyát minden ügyfélhez

Foglald le a teljes készletet együtt: nyilvános port, tunnel alhálózat, konfigurációs útvonal, naplócél, a szolgáltatáspéldány neve és az eszköz. A csoportként való elnevezés az, ami megakadályozza a működő fájl klasszikus másolatát, amely még mindig az első ügyfél poolját vagy interfészét tartalmazza. Az értékek példák, nem lefoglalt portok, ezért ellenőrizd, mit használ már a gazdagép. Egy elinduló szolgáltatás nem ugyanaz, mint egy teljes ügyfél.

Tartsd a kártyát a konfiguráció mellett, és frissítsd minden értékváltozáskor. A valóságtól eltávolodó dokumentáció rosszabb, mint a semmi.

Tartsd a bizalmi anyagot minden ügyfélen belül

Ügyfelenként külön kibocsátó hatóság könnyen átgondolhatóvá teszi a határt, és távol tartja az aláírókulcsot az internetnek kitett gazdagéptől. Megosztott gyökér is működhet, de a közös horgony nem tesz két szolgáltatást egy tagsági tartománnyá. Döntsd el, mely láncokat fogad el az egyes listenerek, és mely kliensidentitásokat engedélyezi, majd írd le mindkettőt. Ne húzz le tanúsítványokat a láncról próbálkozás és hiba útján, amíg valami csatlakozik.

A szerver saját privát kulcsa ügyfelenként védett fájlba tartozik, nem olyan sablonkönyvtárba, amelyet a konfigurációval együtt replikálnak.

Válaszd szét a hálózatokat éppúgy, mint a folyamatokat

Két folyamat két porton továbbra is egy gazdagépet és egy útválasztási táblát oszt meg, hacsak nem választod szét őket. Erősítsd meg, mi figyel, mielőtt megbízol a tervben.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

A listener-ellenőrzés megmutatja, melyik folyamat birtokolja az egyes nyilvános portokat, az igazolás pedig azt, hogy egy kliens-tanúsítvány láncolódik-e a szándékolt horgonyhoz. Egyik kimenet sem bizonyítja, hogy A kliense nem érheti el B alhálózatát, ezért határozd meg a forrás- és célpolitikát, a visszatérő útvonalakat és minden szándékosan megosztott szolgáltatást. A hálózati névterek vagy konténerek szétválasztják az útválasztási kontextusokat és csökkentik a véletlen keveredést, de nem jelentenek teljes bérlői határt önmagukban. Válassz erősebb elkülönítési mechanizmust, amikor a fenyegetésmodell megkívánja.

A visszavonást az átadás előtt kézbesítsd

A tanúsítványtelepítés nem teljes, amíg a visszavonásnak nincs kézbesítési útvonala. Az ügyfélbevezetés részeként ellenőrizd a CRL kibocsátóját és érvényességi ablakát.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

A CRL-ellenőrzés jelenti, mikor adták ki a listát és mikor jár le, a szolgáltatás állapota pedig megerősíti, hogy az azt olvasó példány fut. Frissítsd a listát a kibocsátási szabályzat ütemezése szerint akkor is, ha semmi újat nem vontak vissza, mert egy lejárt CRL minden klienst elutasíthat. Tegyél közzé teljes fájlt ahelyett, hogy az olvasók részleges írással találkoznának, és a telepítés előtt érvényesítsd az aláírást. Rögzítsd, ki birtokolja a kibocsátást, a végpont üzemeltetését és a kivonást, hogy az A ügyfél leállítása ne zavarja B-t.

Ezután futtasd az átvételi párt: egy engedélyezett kliens eléri a saját szolgáltatását, és az A hitelesítő adatait a B listener elutasítja. Ez a határ tesztként kifejezve.