Bärbar VPN-klient utan administratörsrättigheter: vad som fortfarande går sönder

Bärbar beskriver installationsprogrammet, inte kärnan. En klient kan komma som en enda körbar fil på ett USB-minne och ändå behöva en tunnelenhet, en post i rutttabellen och en skrivning till resolvern innan det första paketet rör sig. Vilken av de tre målmaskinen låter dig röra avgör om den bygget alls fungerar där. Testerna nedan besvarar frågan i den ordning klienten möter dem.

Bärbar täcker tre olika löften, och bara ett är gratis

Inget installationsprogram innebär att leverantören inte registrerade en tjänst, inte skickade med ett avinstallationsprogram och inte lade till en menypost. Ingen administratör innebär att ett vanligt konto kan starta klienten och slutföra en anslutning. Ingen ändring av värden innebär att maskinen ser identisk ut efter att du avslutar. Nedladdningssidor som säger bärbar lovar oftast bara det första av dessa, och de andra två är där utrullningar misslyckas. En bygge kan också vara bärbar i snäv mening: den körs från skrivskyddat medium utan några punktfilsskrivningar alls, vilket fortfarande inte säger något om nätverksstacken.

De dyra löftena är det andra och det tredje. En enda körbar fil som behöver en adapter, en rutt eller en skrivning till resolvern ber operativsystemet om befogenhet som etiketten bärbar aldrig täckte.

Hitta den privilegierade hjälparen som klienten kommer att anropa

Nästan ingen VPN-klient flyttar paket själv. På Windows går datavägen genom WFP-filter och Base Filtering Engine, på macOS genom en NetworkExtension-leverantör som användaren godkänner i Systeminställningar, och på Linux genom en tun-enhet plus routingstacken. Binärfilen du kopierade är en kontrollsyta för dessa komponenter, inte en ersättning för dem. Fråga vilken komponent klienten förväntar sig och bekräfta sedan att den är installerad, körs och kan användas av ditt konto.

Linux är den enklaste platsen att bevisa det på, eftersom kontrollen är ett enda systemanrop. Att öppna /dev/net/tun och be kärnan om en enhet kräver CAP_NET_ADMIN, och kärnans TUN/TAP-dokumentation anger både ägarregeln och förmågan. Kör testet som kontot som ska starta klienten, inte som root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

Ett behörighetsfel på mittraden är svaret du letade efter: det här kontot kan inte skapa ett tunnelgränssnitt, så varje användarrymdsklient som behöver ett misslyckas vid anslutning i stället för vid nedladdning. Den sista raden tar bort testenheten och skriver ingenting när den fungerar. Om båda raderna lyckas har värden inte ändrat något permanent.

Testa rutt- och resolverändringar före den första anslutningen

Delad tunnling gör en anslutning till ett routingbeslut, medan en full tunnel gör den till en ersättning av standardrutten. Båda är skrivningar till värdens nätverksstack, och båda misslyckas för ett konto utan privilegier även när klienten själv startar rent. Resolvern är den tredje skrivningen, och på systemd-värdar är det vanligtvis den som går sönder sist. Den ordningen spelar roll när du bestämmer var du vill lägga en förhöjd installation.

Ett rutt-test behöver en destination du faktiskt bryr dig om, så byt ut platshållaren nedan mot ett subnät från din egen profil. Enhetsnamnet måste finnas för att rutten ska kunna fästa vid något.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Om den första raden returnerar RTNETLINK answers: Operation not permitted kan kontot inte installera den privata rutt som profilen kräver. Den andra raden bevisar samma rätt omvänt, vilket spelar roll eftersom en klient som kan lägga till rutter men inte ta bort dem lämnar en trasig tabell efter sig. Därefter visar resolverfrågan om privata namn löses genom tunneln eller läcker till den resolver som värden redan litar på.

Kör alla tre medan testenheten fortfarande finns och ta sedan bort den. En rutt som pekar på en enhet som är borta är den vanligaste anledningen till att en laptop tappar anslutningen efter en misslyckad anslutning.

Bestäm vad som måste överleva sessionen

Att radera mappen är inte en städplan. Adaptrar, rutter, resolverinställningar, betrodda certifikat och lagrade inloggningsuppgifter kan var och en överleva processen, och en tjänst vid uppstart kan återställa några av dem utan att fråga. Skriv ned vad klienten får lämna efter sig innan du kör den, inte efter den första misslyckade frånkopplingen.

Den praktiska regeln är att ta en ögonblicksbild av de tre ytor du ska ändra och jämföra dem efteråt. Registrera gränssnitt, huvudrutttabellen och resolverns tillstånd före den första anslutningen och upprepa sedan samma tre läsningar när klienten har avslutats.

ip -brief addr show
ip route show table main
resolvectl status

Allt som finns i den andra fångsten och saknas i den första behöver en ägare. Antingen tar klienten bort det vid avslut, eller så tar du bort det med samma kommandon som skapade det, och den borttagningen hör hemma i driftsättningsanteckningarna, inte i någons minne av vad som hände. På Windows är motsvarande läsningar Get-NetAdapter, Get-NetRoute och Get-DnsClientServerAddress, som inte kräver förhöjning men visar samma rester.