RemoteEnable er ikke en VPN-innlogging: å avgrense SoftEther-administrasjonen

Veiledningen sier at du skal kjøre RemoteEnable og deretter koble til, og det leses som om de to trinnene er samme slags ting. Det er de ikke. RemoteEnable gir en annen maskin tillatelse til å administrere SoftEther VPN-klienttjenesten som kjører på denne datamaskinen. Tilkobling er en VPN-konto som autentiserer seg mot en server, og ingen administrasjonstillatelse er involvert i det i det hele tatt.

Myten: RemoteEnable slår på VPN-en

Forvirringen kommer fra naboskap. En veiledning slår på fjernadministrasjon, starter klienttjenesten på nytt, kobler deretter til, og tilkoblingen fungerer etterpå, så de to trinnene ser kausalt sammenkoblet ut. Det som faktisk endret seg, er hvem som får snakke med tjenesten, ikke om tjenesten kan nå en server. Slå av fjernadministrasjon på en riktig konfigurert klient, og VPN-tilkoblingen kommer likevel opp.

Kommandohjelpen i oppstrømsprosjektet er tydelig om omfanget: fjernadministrasjon via VPN Client Manager eller vpncmd fra utenfor localhost. Ingenting i den beskrivelsen nevner en tunnel, en konto eller en rute. Tillatelsen som gis, er administrativ rekkevidde, og gjenstanden er klienttjenesten snarere enn tilkoblingen.

Tre identiteter som deler ordet passord

Gamle veiledninger bruker ett ord for tre urelaterte påloggingsdata, og det er slik utrullinger ender opp med en hemmelighet limt inn i feil felt.

Administrasjonspassordet for klienttjenesten beskytter administrasjonen av den lokale SoftEther-klienten. Passordet for VPN-kontoen autentiserer seg mot en server under den serverens policy. Serverens sertifikat er ikke et passord i det hele tatt, men det svarer på hvilket endepunkt klienten skal godta. Å endre ett av dem endrer ikke de andre, og å kopiere en verdi mellom dem gir en annen konfigurasjon i stedet for en enklere.

Alternativet bare-fjerntilgang på administrasjonspassordet fortjener et nytt blikk, fordi det avgjør om passordkravet også gjelder administrasjon fra den lokale maskinen. Å innsnevre det omfanget er et bevisst valg for en enbruker-bærbar datamaskin, ikke en omvei for et passord ingen har notert.

Hva det faktisk endrer å slå på fjernadministrasjon

To driftsmessige konsekvenser følger, og begge er lette å overse i en kopier-og-lim-veiledning. Et administrasjonspassord blir obligatorisk så snart fjernadministrasjon er slått på, og den nye tilgjengeligheten trer bare i kraft etter at klienttjenesten er startet på nytt.

Den omstarten er en reell avbrytelse for alt som bruker klienten, så planlegg den med den som eier maskinen. Å slå på funksjonen åpner heller ikke selv en vei gjennom brannmuren: tjenesten må fortsatt være nåbar fra administrasjonsstasjonen, og en vertsbrannmur eller en ACL lenger opp kan holde den unåelig. En unåelig tjeneste er ikke bevis på at tillatelsen er avgrenset riktig, bare på at noe annet blokkerer den.

Skriv den tiltenkte administrasjonsveien i utrullingsnotatene, inkludert porten og adresseområdet som kan bruke den. Det notatet er også stedet for å registrere hvem som ba om funksjonen og når den bør trekkes tilbake.

Bestem hvem som kan administrere denne klienten

På en bærbar datamaskin du eier, hold administrasjonen på den lokale konsollen med mindre du kan navngi maskinen som trenger fjernaksess og si hvorfor. For en enhet som administreres sentralt, navngi administratoren, administrasjonsveien og gjenopprettingseieren før du slår på noe. Spørsmålet er ikke om funksjonen er praktisk, men hvem som er ansvarlig for konfigurasjonen den blottlegger.

Kjør kommandoene mot den lokale tjenesten slik at endringen havner i din egen skallhistorikk i stedet for i et skjermbilde: vpncmd localhost /client /cmd RemoteDisable slår av funksjonen, og samme kommando med RemoteEnable slår den på. Start tjenesten på nytt etterpå, ellers gjelder ikke innstillingen.

Hvis en veiledning slår den på som et forberedende trinn uten forklaring, behandle det som et uavklart spørsmål i stedet for en instruksjon som skal følges. Spør hvilken administrasjonsstasjon som skal bruke den, og hvis det ikke finnes noe svar, la funksjonen være avslått.

Verifiser administrasjonstilgang og tilkobling separat

To tester svarer på to forskjellige spørsmål, og å kjøre bare én av dem er hvordan en utrulling ender med fjernadministrasjon ingen hadde til hensikt.

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

De to første linjene setter klienten tilbake under lokal administrasjon og anvender endringen. De to siste bekrefter at VPN-kontoene og de virtuelle adapterne fortsatt er konfigurert, slik de bør være, fordi administrasjonsomfang og tilkoblingstilstand er uavhengige innstillinger. Hvis kontolisten kommer tom tilbake etter omstarten, er noe annet ødelagt, og innstillingen for fjernadministrasjon er ikke forklaringen.

Test deretter selve tilkoblingen fra klienten og bekreft at adapteren holder den forventede adressen og rutene. En vellykket vpncmd-økt beviser et kontrollforhold og sier ingenting om hvorvidt trafikken forlater gjennom tunnelen.