Klient SoftEther při spouštění: AccountStartupSet a pořadí démona

Restart počítače ho znovu nechá v síti se spadlým tunelem. Klient SoftEther drží dva stavy, které většina lidí považuje za jeden: zda služba běží a zda smí uložený účet vstát spolu s ní. Oba musí platit a druhý je příznakem u konkrétního účtu, nikoli nastavením při spouštění. Proveďte čtyři kontroly níže v pořadí a zastavte se u prvního selhání.

Ověřte, že je účet označen pro automatické spuštění

Příznak žije v záznamu účtu uvnitř vlastní konfigurace klienta, takže přeinstalace klienta nebo obnovení prázdného adresáře ho vymaže. Otevřete konzolu správy a podívejte se na seznam účtů, než změníte cokoli jiného.

cd /opt/softether/vpnclient
./vpncmd

Zvolte 2 pro správu klienta VPN a potvrďte místní server stisknutím Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet zaznamená účet jako ten, který má být vychován při spuštění služby klienta. Službu sám nespustí ani nevytvoří nový účet a při chybném názvu nevypíše nic užitečného. Přečtěte si seznam účtů po příkazu znovu, protože překlep je tichý a vypadá přesně jako příznak, který se neprosadil.

Ověřte, že se služba spustí, a to dostatečně brzy

V Linuxu klient běží jako démon ze svého vlastního adresáře a musí být nahoru dřív, než se jakýkoli krok spouštění pokusí účet použít. Krátký hák, který změní adresář a spustí ho, stačí na systémech, které ještě používají rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Tam, kde rc.local už není, napište jednotku systemd s explicitním WorkingDirectory a politikou restartu. Binárka řeší konfiguraci relativně k místu, odkud je spuštěna, takže jednotka bez tohoto nastavení může úspěšně nastartovat a nic nepřečíst. Pořadí je druhá polovina problému: pokus o připojení, který běží dřív, než démon začne naslouchat, občas selže, což je mnohem těžší diagnostikovat než stálé selhání. Politika restartu pokrývá třetí případ, kdy démon po hodinách tiše zemře.

Zkontrolujte seznam procesů, místo abyste věřili souboru pid, který zůstal po předchozím spuštění.

Ověřte, že adaptér dostal adresu

Jakmile se účet připojí, klient předloží virtuální adaptér a adaptér stále potřebuje adresu. Hub se SecureNAT obvykle odpovídá na DHCP; hub přemostěný do fyzické LAN očekává, že místo toho odpoví server této LAN.

ip -brief address
dhclient vpn_vpn1

Vezměte název rozhraní ze seznamu, protože číslo v příkladu není konstanta. Pokud musí být adresa statická, vložte ji do síťové konfigurace distribuce pro toto rozhraní, aby se znovu použila po události spojení a nejen při spouštění. Jednorázový skript nechá adaptér bez adresy při prvním opětovném připojení tunelu během dne. To selhání vypadá jako mrtvý tunel, i když je účet v pořádku.

Adaptér bez adresy je nejtišší selhání v seznamu, protože účet stále hlásí připojení.

Ověřte, že trasa vede tam, kam si myslíte

Provoz může selhat i se zdravým spojením a platnou adresou. Zeptejte se jádra, které rozhraní by použilo pro cíl uvnitř podsítě hubu, a pak tuto odpověď porovnejte s tunelem.

ip route get 10.10.20.15

Místní podsíť, která se překrývá s rozsahem hubu, vyhraje, protože její trasa je konkrétnější a už je nainstalovaná.

To je rozhodnutí o číslování, ne chyba klienta, a restart služby to nezmění. Konfigurace překladače je druhá polovina: adresa bez funkčního DNS serveru vytvoří tunel, který projde každou kontrolou spojení a přesto nedokáže otevřít jméno.

Zapište čtyři kontroly do poznámek k přestavbě

Zaznamenejte společně název účtu, příkaz pro spuštění služby a název rozhraní, protože přestavěný hostitel obnoví data účtu, ale ne hák operačního systému, který spouští démona. Ty žijí na různých místech a obvykle je zálohují různí lidé.

Příznak je jeden řádek k opětovnému použití a snadno se zapomene.

Zachovejte pořadí: příznak, služba, adresa, trasa. Kontrolní seznam, který začne uprostřed, dává mnoho sebevědomých špatných odpovědí.