Klient SoftEther pri štarte: AccountStartupSet a poradie démona

Reštart počítača ho opäť nechá v sieti so spadnutým tunelom. Klient SoftEther drží dva stavy, ktoré väčšina ľudí považuje za jeden: či služba beží a či smie uložený účet vstať spolu s ňou. Oba musia platiť a druhý je príznak na úrovni účtu, nie nastavenie štartu. Vykonajte štyri kontroly nižšie v poradí a zastavte sa pri prvej chybe.

Overte, že účet je označený na automatický štart

Príznak žije v zázname účtu vnútri vlastnej konfigurácie klienta, takže preinštalovanie klienta alebo obnovenie prázdneho adresára ho vymaže. Otvorte konzolu správy a pozrite sa na zoznam účtov, skôr než zmeníte čokoľvek iné.

cd /opt/softether/vpnclient
./vpncmd

Zvoľte 2 pre správu klienta VPN a potvrďte lokálny server stlačením Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet zaznamená účet ako ten, ktorý treba vychovať pri štarte služby klienta. Službu sám nespustí ani nevytvorí nový účet a pri nesprávnom názve nevypíše nič užitočné. Prečítajte si zoznam účtov po príkaze znova, pretože preklep je tichý a vyzerá presne ako príznak, ktorý sa nepresadil.

Overte, že služba sa spustí, a to dosť skoro

V Linuxe klient beží ako démon z vlastného adresára a musí byť hore skôr, než sa akýkoľvek krok štartu pokúsi použiť účet. Krátky hák, ktorý zmení adresár a spustí ho, stačí na systémoch, ktoré ešte vykonávajú rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Tam, kde rc.local už nie je, napíšte jednotku systemd s explicitným WorkingDirectory a politikou reštartu. Binárka rieši svoju konfiguráciu relatívne k miestu, odkiaľ je spustená, takže jednotka bez tohto nastavenia môže úspešne naštartovať a nič neprečítať. Poradie je druhá polovica problému: pokus o pripojenie, ktorý beží skôr, než démon začne počúvať, občas zlyhá, čo je oveľa ťažšie diagnostikovať ako trvalé zlyhanie. Politika reštartu pokrýva tretí prípad, keď démon po hodinách ticho zomrie.

Skontrolujte zoznam procesov namiesto toho, aby ste dôverovali súboru pid, ktorý zanechal predchádzajúci štart.

Overte, že adaptér dostal adresu

Hneď ako sa účet pripojí, klient predloží virtuálny adaptér a adaptér stále potrebuje adresu. Hub so SecureNAT zvyčajne odpovedá na DHCP; hub premostený do fyzickej LAN očakáva, že namiesto toho odpovie server tejto LAN.

ip -brief address
dhclient vpn_vpn1

Vezmite názov rozhrania zo zoznamu, pretože číslo v príklade nie je konštanta. Ak má byť adresa statická, vložte ju do sieťovej konfigurácie distribúcie pre toto rozhranie, aby sa znovu použila po udalosti spojenia a nielen pri štarte. Jednorazový skript nechá adaptér bez adresy pri prvom opätovnom pripojení tunela počas dňa. To zlyhanie vyzerá ako mŕtvy tunel, aj keď je účet v poriadku.

Adaptér bez adresy je najtichšie zlyhanie v zozname, pretože účet stále hlási pripojenie.

Overte, že trasa vedie tam, kam si myslíte

Prevádzka môže zlyhať aj so zdravým spojením a platnou adresou. Spýtajte sa jadra, ktoré rozhranie by použilo pre cieľ v podsieti hubu, a potom to porovnajte s tunelom.

ip route get 10.10.20.15

Miestna podsiet, ktorá sa prekrýva s rozsahom hubu, vyhráva, pretože jej trasa je konkrétnejšia a už je nainštalovaná.

To je rozhodnutie o číslovaní, nie chyba klienta, a reštart služby to nezmení. Konfigurácia prekladača je druhá polovica: adresa bez funkčného DNS servera vytvorí tunel, ktorý prejde každou kontrolou spojenia a napriek tomu nedokáže otvoriť meno.

Zapíšte štyri kontroly do poznámok k prestavbe

Zaznamenajte spolu názov účtu, príkaz na spustenie služby a názov rozhrania, pretože prestavaný hostiteľ obnoví údaje účtu, ale nie hák operačného systému, ktorý spúšťa démona. Tie žijú na rôznych miestach a zvyčajne ich zálohujú rôzni ľudia.

Príznak je jeden riadok na opätovné použitie a ľahko sa zabudne.

Zachovajte poradie: príznak, služba, adresa, trasa. Kontrolný zoznam, ktorý začína v strede, dáva veľa sebavedomých nesprávnych odpovedí.