Clientul SoftEther la pornire: AccountStartupSet și ordinea demonului

Repornirea mașinii o lasă în rețea cu tunelul din nou căzut. Clientul SoftEther ține două stări pe care majoritatea oamenilor le tratează ca una singură: dacă serviciul rulează și dacă unui cont salvat i se permite să urce împreună cu el. Ambele trebuie să fie adevărate, iar al doilea este un steag pe cont, nu o setare de pornire. Executați cele patru verificări de mai jos în ordine și opriți-vă la prima eroare.

Confirmați că contul este marcat pentru pornire automată

Steagul trăiește în înregistrarea contului din configurația proprie a clientului, așa că reinstalarea clientului sau restaurarea unui director gol îl șterge. Deschideți consola de administrare și uitați-vă la lista de conturi înainte de a schimba orice altceva.

cd /opt/softether/vpnclient
./vpncmd

Alegeți 2 pentru administrarea clientului VPN și acceptați serverul local apăsând Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet înregistrează contul ca unul care trebuie ridicat la pornirea serviciului client. Nu pornește serviciul și nu creează un cont nou, iar când numele este greșit nu tipărește nimic util. Recitiți lista de conturi după comandă, pentru că o greșeală de tastare este tăcută și arată exact ca un steag care nu a intrat în vigoare.

Confirmați că serviciul pornește, și suficient de devreme

Pe Linux clientul rulează ca demon din propriul director și trebuie să fie pornit înainte ca orice pas de pornire să încerce să folosească contul. Un cârlig scurt care schimbă directorul și îl pornește este suficient pe sistemele care încă rulează rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Acolo unde rc.local nu mai există, scrieți o unitate systemd cu un WorkingDirectory explicit și o politică de repornire. Binarul își rezolvă configurația relativ la locul din care este pornit, așa că o unitate fără această setare poate porni cu succes și nu poate citi nimic. Ordinea este a doua jumătate a problemei: o încercare de conectare care rulează înainte ca demonul să asculte eșuează intermitent, ceea ce este mult mai greu de diagnosticat decât o eroare constantă. O politică de repornire acoperă al treilea caz, în care demonul moare în liniște ore mai târziu.

Verificați lista de procese în loc să aveți încredere într-un fișier pid lăsat de pornirea anterioară.

Confirmați că adaptorul a primit o adresă

De îndată ce contul se conectează, clientul prezintă un adaptor virtual, iar adaptorul are încă nevoie de o adresă. Un hub care rulează SecureNAT răspunde de obicei la DHCP; un hub punte către o LAN fizică așteaptă ca, în schimb, să răspundă serverul acelei LAN.

ip -brief address
dhclient vpn_vpn1

Luați numele interfeței din listă, pentru că numărul dintr-un exemplu nu este o constantă. Dacă adresa trebuie să fie statică, puneți-o în configurația de rețea a distribuției pentru acea interfață, astfel încât să fie reaplicată după un eveniment de legătură și nu doar la pornire. Un script de o singură rulare lasă adaptorul fără adresă prima dată când tunelul se reconectează în timpul zilei. Acea eroare arată ca un tunel mort chiar dacă contul este în regulă.

Un adaptor fără adresă este cea mai tăcută eroare din listă, deoarece contul raportează în continuare conectat.

Confirmați că ruta indică unde credeți

Traficul poate eșua în continuare cu o legătură sănătoasă și o adresă validă. Întrebați nucleul ce interfață ar folosi pentru o destinație din subrețeaua hubului, apoi comparați acel răspuns cu tunelul.

ip route get 10.10.20.15

O subrețea locală care se suprapune cu intervalul hubului câștigă, pentru că ruta ei este mai specifică și deja instalată.

Aceasta este o decizie de numerotare, nu o eroare a clientului, iar repornirea serviciului nu o va schimba. Configurația resolverului este cealaltă jumătate: o adresă fără un server DNS funcțional produce un tunel care trece fiecare verificare a legăturii și tot nu poate deschide un nume.

Scrieți cele patru verificări în notele de reconstrucție

Notați împreună numele contului, comanda de pornire a serviciului și numele interfeței, pentru că un host reconstruit restaurează datele contului, dar nu cârligul sistemului de operare care lansează demonul. Acestea trăiesc în locuri diferite și de obicei sunt salvate de persoane diferite.

Steagul este o linie de reaplicat și ușor de uitat.

Păstrați ordinea: steag, serviciu, adresă, rută. O listă de verificare care începe la mijloc produce multe răspunsuri greșite și încrezătoare.