A RemoteEnable nem VPN-bejelentkezés: a SoftEther-kezelés határainak kijelölése

Az útmutató azt mondja, futtassa a RemoteEnable-t, majd csatlakozzon, és ez úgy olvasható, mintha a két lépés ugyanolyan típusú dolog lenne. Nem az. A RemoteEnable egy másik gépnek ad engedélyt az ezen a számítógépen futó SoftEther VPN kliensszolgáltatás adminisztrálására. A csatlakozás viszont egy VPN-fiók, amely a kiszolgáló felé hitelesít, és abban egyáltalán nem vesz részt semmilyen kezelési engedély.

A mítosz: a RemoteEnable bekapcsolja a VPN-t

A zavar a szomszédságból ered. Egy útmutató bekapcsolja a távoli kezelést, újraindítja a kliensszolgáltatást, majd csatlakozik, és a kapcsolat utána működik, így a két lépés oksági kapcsolatban lévőnek tűnik. Valójában az változott meg, hogy ki beszélhet a szolgáltatással, nem az, hogy a szolgáltatás elér-e egy kiszolgálót. Kapcsolja ki a távoli kezelést egy helyesen beállított kliensen, és a VPN-kapcsolat mégis létrejön.

Az eredeti forrás parancsúgója egyértelmű a hatókörről: távoli kezelés VPN Client Manageren vagy vpncmden keresztül localhoston kívülről. A leírásban sem alagút, sem fiók, sem útvonal nem szerepel. A megadott engedély adminisztratív elérés, és tárgya a kliensszolgáltatás, nem a kapcsolat.

Három identitás, amely osztozik a jelszó szón

A régi útmutatók egyetlen szót használnak három, egymástól független hitelesítő adatra, és így végződnek a telepítések egy rossz mezőbe illesztett titokkal.

A kliensszolgáltatás kezelési jelszava a helyi SoftEther-ügyfél adminisztrációját védi. A VPN-fiók jelszava az adott kiszolgáló szabályzata szerint hitelesít a kiszolgáló felé. A kiszolgálótanúsítvány egyáltalán nem jelszó, de megválaszolja, hogy melyik végpontot fogadja el az ügyfél. Egyikük megváltoztatása nem változtatja meg a többit, és egy érték köztük való átmásolása más konfigurációt eredményez, nem egyszerűbbet.

A kezelési jelszó csak-távoli beállítása második pillantást érdemel, mert eldönti, hogy a jelszókövetelmény a helyi gépről történő kezelésre is vonatkozik-e. Ennek a hatókörnek a szűkítése tudatos döntés egy egyfelhasználós laptopon, nem kerülőút egy senki által fel nem jegyzett jelszóhoz.

Mit változtat meg valójában a távoli kezelés engedélyezése

Két üzemeltetési következmény adódik, és mindkettő könnyen elsiklik egy másol-beilleszt útmutatóban. A kezelési jelszó kötelezővé válik, amint a távoli adminisztráció be van kapcsolva, és az új elérhetőség csak a kliensszolgáltatás újraindítása után lép életbe.

Ez az újraindítás valódi megszakítás mindenre nézve, ami az ügyfelet használja, ezért a gép tulajdonosával tervezze meg. A funkció engedélyezése önmagában sem nyit tűzfal-útvonalat: a szolgáltatásnak továbbra is elérhetőnek kell lennie a kezelőállomásról, és egy gazdagép-tűzfal vagy egy feljebb lévő ACL elérhetetlenül tarthatja. Az elérhetetlen szolgáltatás nem bizonyíték arra, hogy az engedély jól van behatárolva, csak arra, hogy valami más blokkolja.

Írja le a szándékolt kezelési útvonalat a telepítési jegyzetekbe, beleértve a portot és azt a címterületet, amely használhatja. Ez a jegyzet az a hely is, ahol rögzítheti, ki kérte a képességet, és mikor kell visszavonni.

Döntse el, ki kezelheti ezt az ügyfelet

A saját laptopján tartsa az adminisztrációt a helyi konzolon, hacsak nem tudja megnevezni a távoli hozzáférést igénylő gépet, és megmondani, miért. A központilag kezelt eszköznél nevezze meg az adminisztrátort, a kezelési útvonalat és a helyreállítás felelősét, mielőtt bármit engedélyez. A kérdés nem az, hogy kényelmes-e a funkció, hanem az, hogy ki felel a konfigurációért, amelyet feltár.

A parancsokat a helyi szolgáltatáson futtassa, hogy a változás a saját shell-előzményeibe kerüljön, ne egy képernyőképre: a vpncmd localhost /client /cmd RemoteDisable kikapcsolja a képességet, és ugyanez a parancs RemoteEnable-lel bekapcsolja. Utána indítsa újra a szolgáltatást, különben a beállítás nem lép életbe.

Ha egy útmutató minden magyarázat nélkül előkészítő lépésként engedélyezi, kezelje megoldatlan kérdésként, ne követendő utasításként. Kérdezze meg, melyik kezelőállomásnak kellene használnia, és ha nincs válasz, hagyja a képességet kikapcsolva.

A kezelési hozzáférést és a kapcsolódást külön ellenőrizze

Két teszt két különböző kérdésre válaszol, és csak az egyiket futtatni az az út, amelyen egy telepítés olyan távoli adminisztrációval végződik, amelyet senki nem szándékozott.

vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList

Az első két sor visszahelyezi az ügyfelet a helyi adminisztráció alá, és alkalmazza a változást. Az utolsó kettő megerősíti, hogy a VPN-fiókok és a virtuális adapterek továbbra is be vannak állítva, ahogy kell is, mert a kezelési hatókör és a kapcsolat állapota független beállítások. Ha az újraindítás után a fiókok listája üresen tér vissza, valami más romlott el, és a távoli kezelés beállítása nem magyarázat.

Ezután tesztelje magát a kapcsolatot az ügyfélről, és erősítse meg, hogy az adapter a várt címet és útvonalakat tartja. Egy sikeres vpncmd-munkamenet vezérlési viszonyt bizonyít, és semmit nem mond arról, hogy a forgalom elhagyja-e az alagutat.