RemoteEnable is geen VPN-login: de reikwijdte van SoftEther-beheer

De tutorial zegt RemoteEnable uit te voeren en daarna te verbinden, en dat leest alsof die twee stappen hetzelfde soort ding zijn. Dat zijn ze niet. RemoteEnable geeft een andere machine toestemming om de SoftEther VPN-clientservice te beheren die op deze computer draait. Verbinden is een VPN-account dat zich bij een server authenticeert, en daarbij is helemaal geen beheertoestemming betrokken.

De mythe: RemoteEnable zet de VPN aan

De verwarring komt door nabijheid. Een handleiding schakelt beheer op afstand in, herstart de clientservice, verbindt daarna, en de verbinding werkt daarna, zodat de twee stappen oorzakelijk verbonden lijken. Wat werkelijk veranderde, is wie met de service mag praten, niet of de service een server kan bereiken. Schakel beheer op afstand uit op een correct geconfigureerde client en de VPN-verbinding komt toch tot stand.

De commandohelp in het oorspronkelijke project is duidelijk over de reikwijdte: beheer op afstand via VPN Client Manager of vpncmd van buiten localhost. Niets in die beschrijving noemt een tunnel, een account of een route. De toestemming die wordt verleend is administratief bereik, en het onderwerp ervan is de clientservice, niet de verbinding.

Drie identiteiten die het woord wachtwoord delen

Oude handleidingen gebruiken één woord voor drie losstaande inloggegevens, en zo eindigen implementaties met een geheim dat in het verkeerde veld is geplakt.

Het beheerwachtwoord van de clientservice beschermt het beheer van de lokale SoftEther-client. Het wachtwoord van het VPN-account authenticeert zich bij een server volgens het beleid van die server. Het servercertificaat is helemaal geen wachtwoord, maar het beantwoordt welk eindpunt de client moet accepteren. Het ene wijzigen verandert de andere niet, en een waarde ertussen kopiëren levert een andere configuratie op in plaats van een eenvoudigere.

De optie alleen-op-afstand bij het beheerwachtwoord verdient een tweede blik, omdat die bepaalt of de wachtwoordeis ook geldt voor beheer vanaf de lokale machine. Die reikwijdte verkleinen is een bewuste keuze voor een laptop met één gebruiker, geen omweg voor een wachtwoord dat niemand heeft genoteerd.

Wat het inschakelen van beheer op afstand werkelijk verandert

Er volgen twee operationele gevolgen, en beide zijn gemakkelijk te missen in een kopieer-en-plakhandleiding. Een beheerwachtwoord wordt verplicht zodra beheer op afstand is ingeschakeld, en de nieuwe beschikbaarheid wordt pas van kracht nadat de clientservice opnieuw is gestart.

Die herstart is een echte onderbreking voor alles wat de client gebruikt, dus plan die met de eigenaar van de machine. Het inschakelen van de functie opent ook niet vanzelf een pad door de firewall: de service moet nog steeds bereikbaar zijn vanaf het beheerstation, en een hostfirewall of een ACL verderop kan hem onbereikbaar houden. Een onbereikbare service is geen bewijs dat de toestemming goed is afgebakend, alleen dat iets anders hem blokkeert.

Schrijf het bedoelde beheerpad in de implementatienotities, inclusief de poort en het adresbereik dat het mag gebruiken. Die notitie is ook de plek om vast te leggen wie de mogelijkheid heeft aangevraagd en wanneer die moet worden ingetrokken.

Bepaal wie deze client mag beheren

Op een laptop die u bezit, houdt u het beheer op de lokale console, tenzij u de machine kunt noemen die toegang op afstand nodig heeft en kunt zeggen waarom. Voor een apparaat dat centraal wordt beheerd, noemt u de beheerder, het beheerpad en de eigenaar van herstel voordat u iets inschakelt. De vraag is niet of de functie handig is, maar wie verantwoordelijk is voor de configuratie die zij blootlegt.

Voer de commando’s uit tegen de lokale service zodat de wijziging in uw eigen shellgeschiedenis terechtkomt en niet in een schermafbeelding: vpncmd localhost /client /cmd RemoteDisable schakelt de mogelijkheid uit, en hetzelfde commando met RemoteEnable schakelt hem in. Herstart de service daarna, anders is de instelling niet van kracht.

Als een handleiding hem zonder uitleg als voorbereidende stap inschakelt, behandel dat dan als een onopgeloste vraag en niet als een instructie om te volgen. Vraag welk beheerstation hem moet gebruiken, en als er geen antwoord is, laat de mogelijkheid dan uitgeschakeld.

Controleer beheerstoegang en connectiviteit afzonderlijk

Twee tests beantwoorden twee verschillende vragen, en slechts één ervan uitvoeren is hoe een implementatie eindigt met beheer op afstand dat niemand bedoelde.

vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList

De eerste twee regels zetten de client terug onder lokaal beheer en passen de wijziging toe. De laatste twee bevestigen dat de VPN-accounts en de virtuele adapters nog steeds zijn geconfigureerd, wat zo hoort, omdat beheerbereik en verbindingsstatus onafhankelijke instellingen zijn. Als de lijst met accounts na de herstart leeg terugkomt, is iets anders kapotgegaan en is de instelling voor beheer op afstand niet de verklaring.

Test daarna de verbinding zelf vanaf de client en bevestig dat de adapter het verwachte adres en de verwachte routes houdt. Een geslaagde vpncmd-sessie bewijst een beheerrelatie en zegt niets over de vraag of verkeer de tunnel verlaat.