SoftEther-client bij het opstarten: AccountStartupSet en de volgorde van de daemon

Het opnieuw opstarten van de machine laat hem weer op het netwerk achter met de tunnel omlaag. De client van SoftEther houdt twee stukken toestand bij die de meeste mensen als één zien: of de dienst draait, en of een opgeslagen account daarmee omhoog mag komen. Beide moeten waar zijn, en het tweede is een vlag per account in plaats van een opstartinstelling. Voer de vier controles hieronder in volgorde uit en stop bij de eerste fout.

Bevestig dat het account is gemarkeerd voor automatisch starten

De vlag zit in het accountrecord in de eigen configuratie van de client, dus herinstallatie van de client of het herstellen van een lege map wist hem. Open de beheerconsole en bekijk de accountlijst voordat je iets anders wijzigt.

cd /opt/softether/vpnclient
./vpncmd

Kies 2 voor VPN-clientbeheer en accepteer de lokale server door op Enter te drukken.

AccountStartupSet
office-hub
exit

AccountStartupSet registreert het account als een account dat omhoog moet komen wanneer de clientdienst start. Het start de dienst niet en maakt ook geen nieuw account aan, en het drukt niets nuttigs af als de naam verkeerd is. Lees de accountlijst daarna opnieuw, want een typefout is stil en ziet er precies uit als een vlag die niet van kracht werd.

Bevestig dat de dienst start, en vroeg genoeg

Op Linux draait de client als daemon vanuit zijn eigen map, en hij moet omhoog zijn voordat een opstartstap het account probeert te gebruiken. Een korte hook die van map wisselt en hem start is genoeg op systemen die nog rc.local draaien.

cd /opt/softether/vpnclient
./vpnclient start

Waar rc.local weg is, schrijf je een systemd-unit met een expliciete WorkingDirectory en een herstartbeleid. Het binaire bestand lost zijn configuratie op ten opzichte van de plaats waar het start, dus een unit zonder die instelling kan met succes starten en niets lezen. De volgorde is de tweede helft van het probleem: een verbindingspoging die draait voordat de daemon luistert, mislukt met tussenpozen, wat veel moeilijker te diagnosticeren is dan een consistente fout. Een herstartbeleid dekt het derde geval, waarin de daemon uren later stil sterft.

Controleer de processenlijst in plaats van een pid-bestand te vertrouwen dat de vorige opstart heeft achtergelaten.

Bevestig dat de adapter een adres heeft gekregen

Zodra het account verbindt, toont de client een virtuele adapter en de adapter heeft nog steeds een adres nodig. Een hub met SecureNAT antwoordt meestal op DHCP; een hub die aan een fysiek LAN is gebrugd verwacht dat in plaats daarvan de server van dat LAN antwoordt.

ip -brief address
dhclient vpn_vpn1

Neem de interfacenaam uit de lijst, want het nummer in een voorbeeld is geen constante. Als het adres statisch moet zijn, zet het dan in de netwerkconfiguratie van de distributie voor die interface, zodat het na een linkgebeurtenis opnieuw wordt toegepast en niet alleen bij het opstarten. Een eenmalig script laat de adapter adresloos achter de eerste keer dat de tunnel overdag opnieuw verbindt. Die fout ziet eruit als een dode tunnel, ook al is het account in orde.

Een adapter zonder adres is de stilste fout in de lijst, omdat het account nog steeds meldt dat het verbonden is.

Bevestig dat de route wijst waar je denkt

Verkeer kan nog steeds mislukken met een gezonde link en een geldig adres. Vraag de kernel welke interface hij zou gebruiken voor een bestemming binnen het subnet van de hub, en vergelijk dat antwoord dan met de tunnel.

ip route get 10.10.20.15

Een lokaal subnet dat overlapt met het bereik van de hub wint, omdat de route specifieker is en al is geïnstalleerd.

Dat is een nummeringsbeslissing en geen clientfout, en het herstarten van de dienst verandert daar niets aan. De resolverconfiguratie is de andere helft: een adres zonder werkende DNS-server levert een tunnel op die elke linkcontrole doorstaat en toch geen naam kan openen.

Schrijf de vier controles in de herbouwnotities

Noteer de accountnaam, het startcommando van de dienst en de interfacenaam samen, want een herbouwde host herstelt de accountgegevens maar niet de hook van het besturingssysteem die de daemon start. Die leven op verschillende plaatsen en worden meestal door verschillende mensen geback-upt.

De vlag is één regel om opnieuw toe te passen en makkelijk te vergeten.

Houd de volgorde aan: vlag, dienst, adres, route. Een checklist die in het midden begint, levert veel zelfverzekerde verkeerde antwoorden op.