Ponowne uruchomienie maszyny zostawia ją w sieci z ponownie opuszczonym tunelem. Klient SoftEther trzyma dwa stany, które większość ludzi traktuje jako jeden: czy usługa działa i czy zapisanemu kontu wolno wstać razem z nią. Oba muszą być prawdziwe, a drugi to flaga na konto, a nie ustawienie startowe. Wykonaj cztery poniższe kontrole po kolei i zatrzymaj się przy pierwszym błędzie.

Potwierdź, że konto jest oznaczone do automatycznego startu

Flaga mieszka we wpisie konta w konfiguracji samego klienta, więc reinstalacja klienta lub przywrócenie pustego katalogu ją usuwa. Otwórz konsolę zarządzania i spójrz na listę kont, zanim zmienisz cokolwiek innego.

cd /opt/softether/vpnclient
./vpncmd

Wybierz 2 do zarządzania klientem VPN i zaakceptuj serwer lokalny, naciskając Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet zapisuje konto jako takie, które ma zostać podniesione przy starcie usługi klienta. Nie uruchamia usługi ani nie tworzy nowego konta, a przy błędnej nazwie nie wypisuje nic użytecznego. Przeczytaj listę kont ponownie po poleceniu, bo literówka jest cicha i wygląda dokładnie jak flaga, która nie zadziałała.

Potwierdź, że usługa startuje, i to wystarczająco wcześnie

W Linuxie klient działa jako demon z własnego katalogu i musi być uruchomiony, zanim jakikolwiek krok startowy spróbuje użyć konta. Krótki hook, który zmienia katalog i uruchamia go, wystarczy w systemach, które nadal wykonują rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Tam, gdzie rc.local już nie ma, napisz jednostkę systemd z jawnym WorkingDirectory i polityką restartu. Binarka rozwiązuje swoją konfigurację względem miejsca, z którego została uruchomiona, więc jednostka bez tego ustawienia może z powodzeniem wystartować i nic nie odczytać. Kolejność to druga połowa problemu: próba połączenia uruchamiana, zanim demon zacznie nasłuchiwać, zawodzi sporadycznie, co jest znacznie trudniejsze do zdiagnozowania niż stały błąd. Polityka restartu obejmuje trzeci przypadek, gdy demon po godzinach cicho umiera.

Sprawdź listę procesów, zamiast ufać plikowi pid pozostawionemu przez poprzedni start.

Potwierdź, że adapter otrzymał adres

Gdy konto się połączy, klient przedstawia wirtualny adapter, a adapter nadal potrzebuje adresu. Hub z SecureNAT zwykle odpowiada na DHCP; hub mostkowany do fizycznej LAN oczekuje, że zamiast tego odpowie serwer tej LAN.

ip -brief address
dhclient vpn_vpn1

Weź nazwę interfejsu z listy, bo liczba w przykładzie nie jest stałą. Jeśli adres musi być statyczny, umieść go w konfiguracji sieci dystrybucji dla tego interfejsu, aby był stosowany ponownie po zdarzeniu łącza, a nie tylko przy starcie. Skrypt jednorazowy zostawia adapter bez adresu przy pierwszym ponownym połączeniu tunelu w ciągu dnia. Ta awaria wygląda jak martwy tunel, choć konto jest w porządku.

Adapter bez adresu to najcichsza awaria na liście, bo konto nadal zgłasza połączenie.

Potwierdź, że trasa prowadzi tam, gdzie myślisz

Ruch może nadal zawodzić przy zdrowym łączu i prawidłowym adresie. Zapytaj jądro, którego interfejsu użyłoby do celu w podsieci huba, a potem porównaj tę odpowiedź z tunelem.

ip route get 10.10.20.15

Lokalna podsieć, która pokrywa się z zakresem huba, wygrywa, bo jej trasa jest bardziej szczegółowa i już zainstalowana.

To decyzja o numeracji, a nie błąd klienta, i restart usługi tego nie zmieni. Konfiguracja resolwera to druga połowa: adres bez działającego serwera DNS daje tunel, który przechodzi każdą kontrolę łącza i nadal nie potrafi otworzyć nazwy.

Zapisz cztery kontrole w notatkach do odbudowy

Zapisz razem nazwę konta, polecenie startu usługi i nazwę interfejsu, bo odbudowany host przywraca dane konta, ale nie hook systemu operacyjnego, który uruchamia demona. Te rzeczy żyją w różnych miejscach i zwykle są archiwizowane przez różne osoby.

Flaga to jedna linia do ponownego zastosowania i łatwo o niej zapomnieć.

Zachowaj kolejność: flaga, usługa, adres, trasa. Lista kontrolna zaczynająca się w środku daje wiele pewnych siebie błędnych odpowiedzi.

Powiązane artykuły