OpenVPN Access Server: indítsa újra a démont vagy alkalmazza a beállítást
A systemctl restart openvpnas újraindítja a démont; a sacli start felemeli a belső szolgáltatásokat. Kövesse a beállítás dokumentációját, majd ellenőrizze az active-n túl is.
Két parancsot másolnak be arra, ami ugyanannak a feladatnak látszik az OpenVPN Access Serveren, és különböző dolgokat tesznek. A systemctl restart openvpnas leállítja és újraindítja az egész terméket. A sacli start felemeli azokat a belső szolgáltatásokat, amelyek az imént módosított konfigurációt olvassák. A választás nem ízlés kérdése: attól függ, mit mond magának a beállításnak a dokumentációja, hogy a munkamenet áthalad-e azon a kiszolgálón, amelyet újraindítani készül, és hogy egyáltalán a megfelelő terméket nézi-e.
Két réteg, egy démon
Az Access Server egyetlen systemd-egységként, openvpnas néven fut, és ez a démon felügyeli a webes felület mögötti belső szolgáltatásokat és a VPN-hallgatókat. A sacli ugyanahhoz a telepítéshez tartozó parancssori felület, a /usr/local/openvpn_as/scripts/sacli helyen, és képes ezeket a belső összetevőket elindítani, leállítani és lekérdezni anélkül, hogy lecserélné az egységet.
Ezért létezik mindkét parancs. A démon újraindítása mindent újrafuttat, beleértve azt a folyamatot is, amely lezárja az ügyfélalagutakat. A sacli start arra kéri a már futó démont, hogy hozza fel az összetevőit, hogy azok beolvassák az új konfigurációt, és a legtöbb tulajdonságváltozás valójában ezt igényli.
Első feltétel: mit mond a beállítás dokumentációja
Azt a beállítást tartalmazó oldalt olvassa, amelyet módosított, ne azt, amelyet múlt hónapban módosított. A ConfigPut-tal írt tulajdonság után általában sacli start következik, és ez a pár a dokumentált alkalmazási lépés. A hallgató szintű viselkedés változása, vagy bármi, amit az oldal szolgáltatás-újraindítást igénylőként ír le, az az osztály, ahol az egység újraindítása helyes.
A két parancs nem felcserélhető, ezért a találgatás hibaformája aszimmetrikus. Ha sacli startot használ, amikor teljes újraindítás kellett volna, egy régi folyamat tovább szolgálja ki az előző konfigurációt, ami úgy tűnik, mintha a beállítás figyelmen kívül maradt volna. Ha teljes újraindítást végez, amikor a sacli start elegendő lett volna, minden csatlakozott ügyfelet ok nélkül dob ki.
Második feltétel: a munkamenete az alagútban van-e
Ha az Access Servert az általa nyújtott VPN-en keresztül adminisztrálja, az újraindítás eltávolítja a shelljét vivő kapcsolatot. A parancs akkor is befejeződhet, miután a munkamenete meghalt, így találgatni kell, hogy sikerült-e. A sacli start ugyanezen okból rövid időre megszakíthat egy munkamenetet, ha az újrainduló összetevő kezeli a forgalmát.
Tartson nyitva egy sávon kívüli útvonalat bármelyik parancs előtt: szolgáltatói konzol, hipervizor-konzol vagy soros munkamenet. Ez a feltétel dönti el, mikor futtatja a parancsot, nem azt, hogy melyiket, és ez az, ami egy kétperces változást kiesési jelentéssé tesz.
Harmadik feltétel: ez-e a termék, amire gondol
Az Access Server nem Community OpenVPN. A közösségi telepítés olyan egységeket futtat, mint az openvpn@server vagy az openvpn-client@profile, a konfiguráció a /etc/openvpn alatt van, és a sacli ott nem létezik. Ha egy megosztott hoszton minden openvpn nevű egységet újraindít, az a módja annak, hogy a nem összefüggő alagutak együtt essenek ki.
Állapítsa meg, mielőtt bármihez hozzányúl: a systemctl status openvpnas --no-pager megválaszolja, hogy az Access Server fut-e, a sacli status felsorolja a belső összetevőit, és a systemctl list-units --type=service felsorolja azokat az egységeket, amelyek nevében openvpn van. Ha az utolsó parancs profilnevű egységeket mutat, a közösségi terméken van, és a többi itt nem vonatkozik Önre.
Alkalmazza, majd ellenőrizze az active-on túl
Az active-et jelentő egységnek futó folyamata van, ami nem ugyanaz, mint egy működő hitelesítési útvonal. Az alkalmazási lépés után ellenőrizze a sacli statusszal azokat az összetevőket, amelyek újraindulását várta, erősítse meg, hogy az értéket a sacli ConfigQuery mentette, majd futtasson egy korlátozott ügyfélbejelentkezést egy tesztfiókkal.
Fejezze be valamivel alkalmazásszinten: érjen el egy privát erőforrást az alagúton keresztül, ne csak egy pinget a kiszolgáló nyilvános címére. Egy kézfogás, amely akkor sikerül, amikor a küldött útvonal vagy a DNS-beállítás hibás, átmegy minden szolgáltatásellenőrzésen, és mégis cserbenhagyja azt, aki a problémát jelentette.
a szolgáltató szolgáltatáskezelési útmutatója a hivatkozás arra, mely műveletek tartoznak a saclihoz, és érdemes megnyitni, mielőtt eldönti, hogy az újraindítás a biztonságos lehetőség.
A döntés egy menetben
Menjen végig ezen a négy soron, és álljon meg az elsőnél, amelyik illik:
- A beállítás oldala a sacli startot említi, vagy épp most futtatta a ConfigPutot: használja a sacli startot.
- Az oldal újraindítást ír elő, vagy a változás a hallgatókat érinti, nem a tulajdonságokat: használja a systemctl restart openvpnas parancsot.
- A shellje ezen a kiszolgálón keresztül érkezik: először biztosítson konzolhozzáférést, majd futtassa azt a parancsot, amelyet a fenti két sor választott.
- Ellenőrzés: sacli status, ConfigQuery az értékre, egy bejelentkezés, egy privát erőforrás. A szolgáltatás állapota önmagában nem a célvonal.
Ezek közül két sor ellenőrzés, kettő pedig művelet, és ez a sorrend értelme. Ha nem tud válaszolni a termékkérdésre, álljon meg: a parancs, amelyet futtatni készült, egy másik telepítéshez tartozik, és az alagút, amelyet lekapcsol, nem az lesz, amelyre gondolt.