RemoteEnable er ikkje ei VPN-innlogging: å avgrense SoftEther-administrasjonen

Rettleiinga seier at du skal køyre RemoteEnable og deretter kopie til, og det blir lese som om dei to trinna er same slags ting. Det er dei ikkje. RemoteEnable gir ein annan maskin løyve til å administrere SoftEther VPN-klienttenesta som køyrer på denne datamaskina. Tilkopling er ein VPN-konto som autentiserer seg mot ein tenar, og ingen administrasjonsløyve er med i det i det heile.

Myten: RemoteEnable slår på VPN-en

Forvirringa kjem frå naboskap. Ei rettleiing slår på fjernadministrasjon, startar klienttenesta på nytt, koplar deretter til, og tilkoplinga fungerer etterpå, så dei to trinna ser kausalt samankopla ut. Det som faktisk endra seg, er kven som får snakke med tenesta, ikkje om tenesta kan nå ein tenar. Slå av fjernadministrasjon på ein rett konfigurert klient, og VPN-tilkoplinga kjem likevel opp.

Kommandohjelpa i oppstrømsprosjektet er tydeleg om omfanget: fjernadministrasjon via VPN Client Manager eller vpncmd utanfor localhost. Ingenting i den skildringa nemner ein tunnel, ein konto eller ei rute. Løyvet som blir gitt, er administrativ rekkevidd, og gjenstanden er klienttenesta snarare enn tilkoplinga.

Tre identitetar som deler ordet passord

Gamle rettleiingar brukar eitt ord for tre urelaterte påloggingsdata, og det er slik utrullingar endar opp med ein løyndom limt inn i feil felt.

Administrasjonspassordet for klienttenesta vernar administrasjonen av den lokale SoftEther-klienten. Passordet for VPN-kontoen autentiserer seg mot ein tenar under policyen til den tenaren. Tenarsertifikatet er ikkje eit passord i det heile, men det svarar på kva endepunkt klienten skal godta. Å endre eitt av dei endrar ikkje dei andre, og å kopiere ein verdi mellom dei gir ein annan konfigurasjon i staden for ein enklare.

Alternativet berre-fjernadministrasjon på administrasjonspassordet fortener eit nytt blikk, fordi det avgjer om passordkravet også gjeld administrasjon frå den lokale maskina. Å snevre inn det omfanget er eit medvite val for ein einbrukar-bærbar datamaskin, ikkje ein omveg for eit passord ingen har notert.

Kva det faktisk endrar å slå på fjernadministrasjon

To driftsmessige konsekvensar følgjer, og begge er lette å oversjå i ei kopier-og-lim-rettleiing. Eit administrasjonspassord blir obligatorisk så snart fjernadministrasjon er slått på, og den nye tilgjengelegheita trer berre i kraft etter at klienttenesta er starta på nytt.

Den omstarten er ei reell avbryting for alt som brukar klienten, så planlegg han med den som eig maskina. Å slå på funksjonen opnar heller ikkje sjølv ein veg gjennom brannmuren: tenesta må framleis vere nåbar frå administrasjonsstasjonen, og ein vertsbrannmur eller ein ACL lenger opp kan halde henne unåbar. Ei unåbar teneste er ikkje prov på at løyvet er avgrensa rett, berre på at noko anna blokkerer henne.

Skriv den tiltenkte administrasjonsvegen i utrullingsnotata, inkludert porten og adresseområdet som kan bruke han. Det notatet er også staden for å registrere kven som bad om funksjonen og når han bør trekkjast tilbake.

Avgjer kven som kan administrere denne klienten

På ein bærbar datamaskin du eig, hald administrasjonen på den lokale konsollen med mindre du kan namngje maskina som treng fjernåtkomst og seie kvifor. For eininga som blir administrert sentralt, namngje administratoren, administrasjonsvegen og gjenopprettingseigaren før du slår på noko. Spørsmålet er ikkje om funksjonen er praktisk, men kven som er ansvarleg for konfigurasjonen han legg open.

Køyr kommandoane mot den lokale tenesta slik at endringa hamnar i din eigen skallhistorikk i staden for i eit skjermbilete: vpncmd localhost /client /cmd RemoteDisable slår av funksjonen, og same kommando med RemoteEnable slår han på. Start tenesta på nytt etterpå, elles gjeld ikkje innstillinga.

Viss ei rettleiing slår han på som eit førebuande trinn utan forklaring, handsam det som eit uavklart spørsmål i staden for ein instruksjon som skal følgjast. Spør kva administrasjonsstasjon som skal bruke han, og viss det ikkje finst noko svar, lat funksjonen vere avslegen.

Stadfest administrasjonstilgang og tilkopling kvar for seg

To testar svarar på to ulike spørsmål, og å køyre berre éin av dei er korleis ein utrulling endar med fjernadministrasjon ingen hadde til hensikt.

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

Dei to første linjene set klienten tilbake under lokal administrasjon og brukar endringa. Dei to siste stadfester at VPN-kontoane og dei virtuelle adapterane framleis er konfigurerte, slik dei bør vere, fordi administrasjonsomfang og tilkoplingstilstand er uavhengige innstillingar. Viss kontolista kjem tom tilbake etter omstarten, er noko anna øydelagt, og innstillinga for fjernadministrasjon er ikkje forklaringa.

Test deretter sjølve tilkoplinga frå klienten og stadfest at adapteren held den forventa adressa og rutene. Ei vellukka vpncmd-økt provar eit kontrollforhold og seier ingenting om korvidt trafikken forlèt gjennom tunnelen.