Poradnik mówi, aby uruchomić RemoteEnable, a następnie się połączyć, i czyta się to tak, jakby te dwa kroki były tym samym rodzajem rzeczy. Nie są. RemoteEnable daje innej maszynie prawo administrowania usługą klienta SoftEther VPN działającą na tym komputerze. Połączenie to konto VPN uwierzytelniające się na serwerze i nie bierze w nim udziału żadne uprawnienie administracyjne.

Mit: RemoteEnable włącza VPN

Zamieszanie bierze się z sąsiedztwa. Poradnik włącza zdalne zarządzanie, restartuje usługę klienta, potem się łączy, a połączenie działa później, więc dwa kroki wyglądają na powiązane przyczynowo. Naprawdę zmieniło się to, kto może rozmawiać z usługą, a nie to, czy usługa może dotrzeć do serwera. Wyłącz zdalne zarządzanie na poprawnie skonfigurowanym kliencie, a połączenie VPN i tak powstanie.

Pomoc polecenia w źródle oryginalnym jasno określa zakres: zdalne zarządzanie przez VPN Client Manager lub vpncmd spoza localhost. Nic w tym opisie nie wspomina o tunelu, koncie ani trasie. Przyznawane uprawnienie to zasięg administracyjny, a jego przedmiotem jest usługa klienta, nie połączenie.

Trzy tożsamości dzielące słowo hasło

Stare poradniki używają jednego słowa dla trzech niepowiązanych poświadczeń, i tak wdrożenia kończą z sekretem wklejonym w złe pole.

Hasło administracji usługą klienta chroni zarządzanie lokalnym klientem SoftEther. Hasło konta VPN uwierzytelnia się na serwerze zgodnie z polityką tego serwera. Certyfikat serwera wcale nie jest hasłem, ale odpowiada na pytanie, który punkt końcowy klient powinien zaakceptować. Zmiana jednego nie zmienia pozostałych, a kopiowanie wartości między nimi daje inną konfigurację, a nie prostszą.

Opcja tylko-zdalnie przy haśle administracji zasługuje na drugie spojrzenie, bo decyduje, czy wymóg hasła dotyczy także zarządzania z lokalnej maszyny. Zawężenie tego zakresu to świadomy wybór dla laptopa jednego użytkownika, a nie obejście hasła, którego nikt nie zapisał.

Co naprawdę zmienia włączenie zdalnego zarządzania

Wynikają z tego dwie konsekwencje operacyjne i obie łatwo przeoczyć w poradniku typu kopiuj-wklej. Hasło administracji staje się obowiązkowe, gdy tylko włączone zostanie zdalne administrowanie, a nowa dostępność obowiązuje dopiero po restarcie usługi klienta.

Ten restart to rzeczywiste przerwanie dla wszystkiego, co korzysta z klienta, więc zaplanuj go z właścicielem maszyny. Włączenie funkcji samo w sobie nie otwiera też drogi przez zaporę: usługa nadal musi być osiągalna ze stacji administracyjnej, a zapora hosta lub ACL wyżej mogą utrzymywać ją nieosiągalną. Nieosiągalna usługa nie jest dowodem na to, że uprawnienie jest dobrze ograniczone, tylko na to, że coś innego ją blokuje.

Zapisz zamierzoną ścieżkę zarządzania w notatkach wdrożeniowych, wraz z portem i zakresem adresów, które mogą jej używać. Ta notatka to także miejsce na zapisanie, kto poprosił o tę możliwość i kiedy należy ją wycofać.

Zdecyduj, kto może zarządzać tym klientem

Na laptopie, który należy do ciebie, trzymaj administrację na konsoli lokalnej, chyba że potrafisz wskazać maszynę potrzebującą zdalnego dostępu i powiedzieć dlaczego. Dla urządzenia zarządzanego centralnie wskaż administratora, ścieżkę zarządzania i właściciela odtwarzania, zanim cokolwiek włączysz. Pytanie nie brzmi, czy funkcja jest wygodna, ale kto odpowiada za konfigurację, którą ona odsłania.

Uruchamiaj polecenia wobec lokalnej usługi, aby zmiana trafiła do twojej własnej historii powłoki, a nie na zrzut ekranu: vpncmd localhost /client /cmd RemoteDisable wyłącza możliwość, a to samo polecenie z RemoteEnable włącza ją. Zrestartuj potem usługę, inaczej ustawienie nie będzie obowiązywać.

Jeśli poradnik włącza ją jako krok wstępny bez wyjaśnienia, traktuj to jako nierozstrzygnięte pytanie, a nie jako instrukcję do wykonania. Zapytaj, która stacja administracyjna ma jej używać, a jeśli nie ma odpowiedzi, pozostaw możliwość wyłączoną.

Weryfikuj dostęp administracyjny i łączność osobno

Dwa testy odpowiadają na dwa różne pytania, a uruchomienie tylko jednego z nich to sposób, w jaki wdrożenie kończy się zdalną administracją, której nikt nie chciał.

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

Pierwsze dwie linie przywracają klienta pod administrację lokalną i stosują zmianę. Ostatnie dwie potwierdzają, że konta VPN i adaptery wirtualne nadal są skonfigurowane, jak powinny być, ponieważ zakres zarządzania i stan połączenia to niezależne ustawienia. Jeśli po restarcie lista kont wróci pusta, zepsuło się coś innego, a ustawienie zdalnego zarządzania nie jest wyjaśnieniem.

Następnie przetestuj samo połączenie z klienta i potwierdź, że adapter trzyma oczekiwany adres i trasy. Udana sesja vpncmd dowodzi relacji sterowania i nic nie mówi o tym, czy ruch wychodzi przez tunel.

Powiązane artykuły