Az Access Server elvesztette kötését a hálózati interfész átnevezése után: javítsa a kulcsokat

Átnevezett egy hálózati interfészt, vagy visszaállított egy gépet, amelynek adaptere más néven tért vissza, és most az OpenVPN Access Server daemonja nem indul el. A webes felület talán még válaszol, talán nem, attól függően, melyik komponens volt a régi névhez kötve. A szolgáltatás nem sérült, a konfiguráció nem veszett el; egy beállítás még mindig olyan interfészre mutat, amellyel a gazdagép már nem rendelkezik.

A reflex az újratelepítés, az újrainicializálás vagy az adatbázis szerkesztése, amíg a hiba el nem tűnik. Mindegyik nagyobb változás a hibánál, és az utolsó törölheti azokat a felhasználókat, jogosultságokat és függőségeket, amelyek miatt a szerver mentést érdemelt. Ez kötési probléma, és van rá megnevezett javítás.

Mit mond valójában a tünet

A kötni képtelen daemon általában a saját naplójában mondja meg: a cím nem elérhető, vagy az interfész nem létezik. Az üzenet konkrét: megnevezi a címet, amelyet a daemon megpróbált; hasonlítsa össze a gazdagépen a ip -br addr kimenettel, hogy lássa, átnevezték-e, eltávolították-e, vagy a régi cím nélkül hozták-e fel az interfészt.

Tartsa nyitva végig egy jogosult helyreállítási konzolt. Ha a módosítandó kötés hordozza az egyetlen adminisztratív munkamenetét, elvágta a visszautat. Egy helyi konzol, egy második kezelési cím vagy egy dokumentált sávon kívüli útvonal visszafordíthatóvá teszi a változtatást.

Kérdezze le a konfigurációt, mielőtt szerkeszti

Az Access Server a saját CLI-jén keresztül teszi elérhetővé a konfigurációját. A dokumentált nézet:

sacli ConfigQuery

A verziójához dokumentált adminisztratív környezetben futtassa, ne egy másik gazdagép független shelljéből. Módosítás előtt mentse a jelenlegi értékeket védett helyre, és ne illessze be a teljes kimenetet nyilvános támogatási szálba.

Ez a kimenet a szerverkonfiguráció nézete, nem teljes biztonsági mentés. A felhasználói és csoporttulajdonságokat külön kérdezi le, így a tiszta kötés nem állítja vissza az identitásokat, a visszaállított identitás pedig nem javítja a figyelőt. Rögzítse mindkettőt két külön artefaktumként.

Állapítsa meg, melyik figyelő hibás

Az Access Server egynél több figyelőt futtat. Az OpenVPN daemonok hordozzák az alagútforgalmat, a webszolgáltatás az adminisztrációs és ügyfélportált, más komponenseknek saját portjaik lehetnek. Egy sikertelen böngészőkérés nem mondja meg, melyik hibázott, és a hibaüzenet portszáma sem.

A daemon kötési kulcsai daemononként dokumentáltak, és a hivatalos útmutatóban az érték az interfész azonosítója, bár a kulcsnevek ip_address végződésűek. Olvassa el kétszer ezt a mondatot. Az útmutató azt is elvárja, hogy az UDP és TCP daemonok egy interfészt osszanak meg, így csak egy kulcs javítása részleges javítás.

A megnevezett beállítást módosítsa, ne az egyező sorokat

Az útmutató a ConfigPut parancsot adott kulcsokon dokumentálja, például vpn.daemon.0.server.ip_address és vpn.daemon.0.listen.ip_address. Használja a termék saját módszerét a kulcsnévvel és az új értékkel, a verziójához dokumentált szintaxisban, és csak a diagnosztizált figyelő kulcsait módosítsa.

Amit nem szabad tennie: az adatbázisban megkeresni minden sort, amelynek értéke a régi interfésznév, és az összeset lecserélni. Ez azt feltételezi, hogy a régi név csak figyelőbeállításokban fordult elő, amit a séma nem ígér. Emellett a változtatás áttekinthetetlenné válik.

Két további kísértést érdemes elutasítani. Egy minden interfészen figyelő alapértelmezés visszaállítása kitettségi döntés, nem helyesírás-javítás; a szándékolt helyi kötésnek, a közzétett útvonalnak és az előtte lévő szűrésnek egyeznie kell ezzel a választással. A konfiguráció újrainicializálása átnevezi a problémát ahelyett, hogy megoldaná, mert a friss telepítés épp azokat a felhasználókat és jogosultságokat dobja el, amelyek az átnevezés előtt működtek.

Alkalmazza, majd bizonyítsa, hogy az útvonal működik

Az érték javítása után alkalmazza a termék dokumentált életciklusán keresztül ( életciklus ). Az útmutató a kulcsok beállítása után a sacli start parancsot használja; ez nem teljes gazdagép-újraindítás és nem adatbázis-visszaállítás.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Ellenőrizze a figyelőt, majd létesítsen egy jogosult VPN-kapcsolatot, érjen el egy privát erőforrást, és töltse be az adminisztrációs oldalt a várt útvonalon. Tartsa meg a meglévő felhasználói jogosultságokat és visszavonásokat; egy azokat visszaállító helyreállítás javította a kötést és elvesztette a telepítést. A munka akkor van kész, amikor ugyanaz a szolgáltatás a szándékolt interfészen működik.