RemoteEnable er ikke et VPN-login: afgrænsning af SoftEther-administration

Vejledningen siger, at du skal køre RemoteEnable og derefter oprette forbindelse, og det læses, som om de to trin er samme slags ting. Det er de ikke. RemoteEnable giver en anden maskine tilladelse til at administrere SoftEther VPN-klienttjenesten, der kører på denne computer. Forbindelse er en VPN-konto, der autentificerer til en server, og ingen administrationstilladelse indgår i det overhovedet.

Myten: RemoteEnable tænder for VPN’en

Forvirringen kommer fra naboskab. En guide aktiverer fjernadministration, genstarter klienttjenesten, opretter derefter forbindelse, og forbindelsen virker bagefter, så de to trin ser kausalt forbundne ud. Det, der faktisk ændrede sig, er, hvem der må tale med tjenesten, ikke om tjenesten kan nå en server. Slå fjernadministration fra på en korrekt konfigureret klient, og VPN-forbindelsen kommer stadig op.

Kommandohjælpen i det oprindelige projekt er tydelig om omfanget: fjernadministration via VPN Client Manager eller vpncmd udefra localhost. Intet i den beskrivelse nævner en tunnel, en konto eller en rute. Den tilladelse, der gives, er administrativ rækkevidde, og dens genstand er klienttjenesten snarere end forbindelsen.

Tre identiteter, der deler ordet adgangskode

Gamle guider bruger ét ord til tre uafhængige legitimationsoplysninger, og det er sådan implementeringer ender med en hemmelighed indsat i det forkerte felt.

Adgangskoden til klienttjenesteadministration beskytter administrationen af den lokale SoftEther-klient. Adgangskoden til VPN-kontoen autentificerer til en server under den servers politik. Servercertifikatet er slet ikke en adgangskode, men det besvarer, hvilket endepunkt klienten skal acceptere. At ændre en af dem ændrer ikke de andre, og at kopiere en værdi mellem dem giver en anden konfiguration i stedet for en enklere.

Indstillingen kun-fjern på administrationsadgangskoden fortjener et andet blik, fordi den afgør, om adgangskodekravet også gælder for administration fra den lokale maskine. At indsnævre det omfang er et bevidst valg til en enkeltbruger-bærbar computer, ikke en omvej for en adgangskode, som ingen har nedskrevet.

Hvad aktivering af fjernadministration faktisk ændrer

Der følger to driftsmæssige konsekvenser, og begge er nemme at overse i en kopier-og-sæt-ind-guide. En administrationsadgangskode bliver obligatorisk, når fjernadministration slås til, og den nye tilgængelighed træder først i kraft, efter at klienttjenesten er genstartet.

Den genstart er en reel afbrydelse for alt, der bruger klienten, så planlæg den med den, der ejer maskinen. At aktivere funktionen åbner heller ikke selv en vej gennem firewallen: tjenesten skal stadig kunne nås fra administrationsstationen, og en vært-firewall eller en ACL længere oppe kan holde den utilgængelig. En utilgængelig tjeneste er ikke bevis på, at tilladelsen er afgrænset korrekt, kun på at noget andet blokerer den.

Skriv den tilsigtede administrationsvej i implementeringsnoterne, herunder porten og det adresseområde, der må bruge den. Den note er også stedet til at registrere, hvem der bad om muligheden, og hvornår den bør trækkes tilbage.

Beslut, hvem der må administrere denne klient

På en bærbar computer, du ejer, skal administrationen blive på den lokale konsol, medmindre du kan navngive den maskine, der har brug for fjernadgang, og sige hvorfor. For en enhed, der administreres centralt, skal du navngive administratoren, administrationsvejen og gendannelsesejeren, før du aktiverer noget. Spørgsmålet er ikke, om funktionen er bekvem, men hvem der er ansvarlig for den konfiguration, den blotlægger.

Kør kommandoerne mod den lokale tjeneste, så ændringen havner i din egen shell-historik i stedet for på et skærmbillede: vpncmd localhost /client /cmd RemoteDisable slår muligheden fra, og samme kommando med RemoteEnable slår den til. Genstart tjenesten bagefter, ellers gælder indstillingen ikke.

Hvis en vejledning aktiverer den som et foreløbigt trin uden forklaring, skal du behandle det som et uafklaret spørgsmål i stedet for en instruktion, der skal følges. Spørg, hvilken administrationsstation der skal bruge den, og hvis der ikke er noget svar, så lad muligheden være deaktiveret.

Kontrollér administrationsadgang og forbindelse separat

To test besvarer to forskellige spørgsmål, og at køre kun én af dem er, hvordan en implementering ender med fjernadministration, som ingen havde til hensigt.

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

De to første linjer sætter klienten tilbage under lokal administration og anvender ændringen. De to sidste bekræfter, at VPN-kontoene og de virtuelle netværkskort stadig er konfigureret, hvilket de bør være, fordi administrationsomfang og forbindelsestilstand er uafhængige indstillinger. Hvis kontolisten kommer tom tilbage efter genstarten, er noget andet gået i stykker, og indstillingen for fjernadministration er ikke forklaringen.

Test derefter selve forbindelsen fra klienten, og bekræft, at netværkskortet har den forventede adresse og de forventede ruter. En vellykket vpncmd-session beviser et kontrolforhold og siger intet om, hvorvidt trafikken forlader gennem tunnelen.