RemoteEnable är inte en VPN-inloggning: att avgränsa SoftEther-administrationen

Handledningen säger att du ska köra RemoteEnable och sedan ansluta, och det läses som om de två stegen vore samma sorts sak. Det är de inte. RemoteEnable ger en annan maskin tillstånd att administrera SoftEther VPN-klienttjänsten som körs på den här datorn. Att ansluta är ett VPN-konto som autentiserar sig mot en server, och inget administrationstillstånd är inblandat i det alls.

Myten: RemoteEnable slår på VPN:en

Förvirringen kommer från närheten. En guide aktiverar fjärradministration, startar om klienttjänsten, ansluter sedan, och anslutningen fungerar efteråt, så de två stegen verkar kausalt sammankopplade. Det som faktiskt ändrades är vem som får tala med tjänsten, inte om tjänsten kan nå en server. Stäng av fjärradministration på en korrekt konfigurerad klient och VPN-anslutningen kommer ändå upp.

Kommandohjälpen i ursprungsprojektet är tydlig om omfattningen: fjärradministration via VPN Client Manager eller vpncmd från utanför localhost. Inget i den beskrivningen nämner en tunnel, ett konto eller en rutt. Det tillstånd som ges är administrativ räckvidd, och dess föremål är klienttjänsten snarare än anslutningen.

Tre identiteter som delar ordet lösenord

Gamla guider använder ett ord för tre orelaterade inloggningsuppgifter, och det är så distributioner slutar med en hemlighet inklistrad i fel fält.

Administrationslösenordet för klienttjänsten skyddar administrationen av den lokala SoftEther-klienten. VPN-kontots lösenord autentiserar sig mot en server enligt den serverns policy. Serverns certifikat är inte alls ett lösenord, men det svarar på vilken slutpunkt klienten ska acceptera. Att ändra ett av dem ändrar inte de andra, och att kopiera ett värde mellan dem ger en annan konfiguration i stället för en enklare.

Alternativet endast-fjärr på administrationslösenordet förtjänar en andra titt, eftersom det avgör om lösenordskravet också gäller administration från den lokala maskinen. Att snäva in den omfattningen är ett medvetet val för en enanvändarlaptop, inte en omväg för ett lösenord som ingen har antecknat.

Vad aktiveringen av fjärradministration faktiskt ändrar

Två driftsmässiga konsekvenser följer, och båda är lätta att missa i en kopiera-och-klistra-guide. Ett administrationslösenord blir obligatoriskt så snart fjärradministrationen slås på, och den nya tillgängligheten träder i kraft först efter att klienttjänsten har startats om.

Den omstarten är ett verkligt avbrott för allt som använder klienten, så planera den med den som äger maskinen. Att aktivera funktionen öppnar inte heller själv en väg genom brandväggen: tjänsten måste fortfarande vara nåbar från administrationsstationen, och en värdbrandvägg eller en ACL högre upp kan hålla den onåbar. En onåbar tjänst är inte bevis på att tillståndet är korrekt avgränsat, bara på att något annat blockerar den.

Skriv den avsedda administrationsvägen i distributionsanteckningarna, inklusive porten och det adressområde som får använda den. Den anteckningen är också platsen för att registrera vem som bad om funktionen och när den bör dras tillbaka.

Bestäm vem som får administrera den här klienten

På en laptop du äger, håll administrationen på den lokala konsolen om du inte kan namnge maskinen som behöver fjärråtkomst och säga varför. För en enhet som administreras centralt, namnge administratören, administrationsvägen och återställningsägaren innan du aktiverar något. Frågan är inte om funktionen är bekväm, utan vem som ansvarar för den konfiguration den blottlägger.

Kör kommandona mot den lokala tjänsten så att ändringen hamnar i din egen skalhistorik i stället för i en skärmbild: vpncmd localhost /client /cmd RemoteDisable stänger av funktionen, och samma kommando med RemoteEnable slår på den. Starta om tjänsten efteråt, annars gäller inte inställningen.

Om en guide aktiverar den som ett förberedande steg utan förklaring, behandla det som en olöst fråga och inte som en instruktion att följa. Fråga vilken administrationsstation som ska använda den, och om det inte finns något svar, låt funktionen vara avstängd.

Verifiera administrationsåtkomst och anslutning separat

Två tester besvarar två olika frågor, och att bara köra ett av dem är hur en distribution slutar med fjärradministration som ingen avsåg.

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

De två första raderna för tillbaka klienten under lokal administration och tillämpar ändringen. De två sista bekräftar att VPN-kontona och de virtuella adaptrarna fortfarande är konfigurerade, vilket de bör vara, eftersom administrationsomfattning och anslutningsstatus är oberoende inställningar. Om kontolistan kommer tillbaka tom efter omstarten har något annat gått sönder, och inställningen för fjärradministration är inte förklaringen.

Testa sedan själva anslutningen från klienten och bekräfta att adaptern håller den förväntade adressen och rutterna. En lyckad vpncmd-session bevisar ett kontrollförhållande och säger ingenting om huruvida trafiken lämnar genom tunneln.