Mielőtt egy Juju charm a VPN-eddé válik: identitás, szerződés, portok

Valaki talál egy charmet, amely azt állítja, hogy VPN-t futtat, telepíti, közzéteszi az alkalmazást, és várja, hogy egy ügyfél csatlakozzon. A telepítés sikerül, a port megnyílik, és az alagút mégsem működik, mert három független ígéretet egyetlenbe gyúrtak. A charm egy konkrét szerződésű telepítési megvalósítás. Vizsgálja meg ezeket az ígéreteket külön, és a hiányosságok a bevezetés előtt fognak megjelenni, nem utána.

Első lépés: rögzítse azt az artefaktumot, amelyről olvas

Olvassa el a jelölt saját metaadatait: kiadó, forrástár, csatorna, revízió, bázis és architektúra. Ezután állapítsa meg, ki tartja karban a számítási terhelésen belüli VPN-szoftvert, és ki szállítja a biztonsági frissítéseit, mert ezek gyakran két különböző fél. Egy karbantartatlan upstream egy jól karbantartott charmen belül egy rossz hétre váró támogatási probléma.

juju info CHARM_NAME csatornákat, bázisokat és architektúrákat jelent a Juju 3.6-ban, és a dokumentáció megjegyzi, hogy egy adott revízióra vonatkozó lekérdezés nem kombinálható ezekkel a szűrőkkel. Kérdezze le a revíziót külön, ahelyett hogy olyan kombinációt építene, amelyet a parancs elutasít. Olvassa el a bázist és az architektúrát is, mert egy csatorna többet is lefedhet.

Jegyezze fel a pontosan átvizsgált kombinációt a telepítés mellé. Akkor a csatornát elmozdító frissítés szándékos változás lesz előtte és utána állapottal, nem pedig hétfői meglepetés.

Második lépés: olvassa a konfigurációt szerződésként

Határozza meg a charm szerepét: távoli hozzáférés megszüntetése, csatlakozás meglévő VPN-hez, vagy valami egészen más. Ezután keresse meg, hogyan dokumentálja az ügyfél-regisztrációt, a megbízható kiállítókat, a hitelesítő adatok rotációját és a visszavonást. Ez a négy dönti el, hogy tudja-e üzemeltetni, és a létrehozott ügyfélfájl érzékeny kimenet, nem pedig jegyfájl.

Kövesse azokat az interfészeket és műveleteket, amelyeket a charm valóban kínál. Ne feltételezze, hogy létezik regisztrációs művelet, csak mert egy másik, ugyanahhoz a szoftverhez készült charmen van ilyen.

Kérdezze meg, mit tesz az egyeztetés a kézi szerkesztésekkel. Ha a charm felülír egy konfigurációs fájlt a következő frissítéskor, a kézi javítás élettartama egyetlen frissítés. Kérdezze meg a karbantartókat, hol dokumentált ez a viselkedés, és a csendet tekintse ismeretlennek.

Harmadik lépés: válassza el a figyelőt a továbbított útvonaltól

A külső figyelő az a socket, amely elfogadja az alagutat. A továbbítás az, ami a benne lévő forgalommal történik, a visszaút pedig az, ami a válaszokat visszaengedi. Egy charm szállíthatja az elsőt, és a másik kettőt az infrastruktúra-csapatra hagyhatja.

A kimenet a harmadik darab. Ha az alagút ügyfeleinek ezen a gazdagépen keresztül kell elérniük az internetet, léteznie kell címzési vagy fordítási megoldásnak, és az nem egy port megnyitásával jön létre. Rendeljen gazdát ehhez a darabhoz, mielőtt megérkezik az első ügyfél.

Negyedik lépés: a közzététel tűzfal-művelet

A Juju 3.6-ban egy alkalmazás közzététele módosítja a felhő tűzfal szabályait, és alapértelmezés szerint bármely forrásból engedi a forgalmat a terhelés által megnyitott portokra. A parancs endpoint- és CIDR-választói pontosan azért léteznek, hogy ez az alapértelmezés szűkíthető legyen.

A közzététel nem hoz létre VPN-felhasználókat, nem ellenőrzi a hitelesítő adataikat, és nem telepít továbbítási szabályzatot. Azt sem bizonyítja, hogy a terhelés a várt címen és átvitelen figyel, ezért a közzététel utáni teszt fontosabb a sikeres üzenetnél. Ellenőrizze az egységen figyelő socketet és a felhőszabályt is.

Ötödik lépés: fogadja el négy teszttel

Jóváhagyott telepítés után regisztráljon egy új ügyfelet, és erősítse meg a szándékolt privát szolgáltatást. Ezután vonja vissza azt az identitást, és erősítse meg, hogy a hozzáférés valóban megszűnik, nem csak a következő bejelentkezést utasítják el. Ismételje meg az ellenőrzést egy Ön által nem irányított hálózatból, majd az irodán belülről, mert ez a két út különböző kérdésekre válaszol.

Fejezze be egy frissítéssel és egy újracsatlakozással, mert ott hat egymásra az egyeztetés, a hitelesítő adatok kezelése és a szolgáltatás-újraindítások. Ha a dokumentáció nem tudja megmagyarázni, ki birtokolja e műveletek egyikét, írja ezt le elfogadási hiányosságként, ahelyett hogy karbantartatlan recepttel töltené ki ugyanazon charmnév mögött. A leírt hiányosság döntés; a csendben kitöltött hiányosság jövőbeli kiesés. Adja át annak, aki birtokolja a szolgáltatási döntést, azzal a dátummal, amikor megtalálta.