Draagbare VPN-client zonder beheerdersrechten: wat er alsnog stukgaat

Draagbaar beschrijft de installer, niet de kernel. Een client kan binnenkomen als één uitvoerbaar bestand op een USB-stick en toch een tunnelapparaat, een vermelding in de routetabel en een schrijfactie naar de resolver nodig hebben voordat het eerste pakket beweegt. Welke van die drie de doelmachine u laat aanraken, bepaalt of die build daar überhaupt werkt. De controles hieronder beantwoorden de vraag in de volgorde waarin de client ze tegenkomt.

Draagbaar dekt drie verschillende beloften, en slechts één is gratis

Geen installer betekent dat de leverancier geen service heeft geregistreerd, geen uninstaller heeft meegeleverd en geen menu-item heeft toegevoegd. Geen beheerder betekent dat een gewoon account de client kan starten en een verbinding kan afronden. Geen wijziging aan de host betekent dat de machine er na het afsluiten identiek uitziet. Downloadpagina's die draagbaar zeggen, beloven meestal alleen het eerste daarvan, en de andere twee zijn waar uitrollingen mislukken. Een build kan ook in engere zin draagbaar zijn: hij draait vanaf alleen-lezen media zonder enige dotfile-schrijfactie, wat nog niets zegt over de netwerkstack.

De dure beloften zijn de tweede en de derde. Eén uitvoerbaar bestand dat een adapter, een route of een schrijfactie naar de resolver nodig heeft, vraagt het besturingssysteem om bevoegdheid die het label draagbaar nooit dekte.

Vind de geprivilegieerde helper die de client aanroept

Bijna geen enkele VPN-client verplaatst zelf pakketten. Op Windows loopt het datapad via WFP-filters en de Base Filtering Engine, op macOS via een NetworkExtension-provider die de gebruiker in Systeeminstellingen goedkeurt, en op Linux via een tun-apparaat plus de routingstack. Het binaire bestand dat u hebt gekopieerd is een bedieningsoppervlak voor die componenten, geen vervanging ervan. Vraag welke component de client verwacht en bevestig dan dat die is geïnstalleerd, draait en door uw account kan worden gebruikt.

Linux is de gemakkelijkste plek om dat te bewijzen, omdat de controle één systeemaanroep is. /dev/net/tun openen en de kernel om een apparaat vragen vereist CAP_NET_ADMIN, en de kernel-documentatie over TUN/TAP noemt zowel de eigendomsregel als de mogelijkheid. Voer de controle uit met het account dat de client start, niet als root.

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

Een toestemmingsfout op de middelste regel is het antwoord dat u zocht: dit account kan geen tunnelinterface aanmaken, dus elke userspace-client die er een nodig heeft, faalt bij het verbinden in plaats van bij het downloaden. De laatste regel verwijdert het testapparaat en drukt niets af als het werkt. Als beide regels slagen, heeft de host niets permanents gewijzigd.

Test route- en resolverwijzigingen vóór de eerste verbinding

Split-tunneling maakt van een verbinding een routingbeslissing, terwijl een volledige tunnel er een vervanging van de standaardroute van maakt. Beide zijn schrijfacties naar de netwerkstack van de host, en beide falen voor een account zonder privileges, zelfs wanneer de client zelf schoon start. De resolver is de derde schrijfactie, en op systemd-hosts is dat meestal degene die als laatste breekt. Die volgorde is belangrijk wanneer u besluit waar u een verhoogde installatie aan uitgeeft.

Een routecontrole heeft een bestemming nodig die u echt iets kan schelen, dus vervang de plaatsaanduiding hieronder door een subnet uit uw eigen profiel. De apparaatnaam moet bestaan wil de route ergens aan kunnen hangen.

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

Als de eerste regel RTNETLINK answers: Operation not permitted teruggeeft, kan het account de privéroute die het profiel vereist niet installeren. De tweede regel bewijst hetzelfde recht omgekeerd, wat ertoe doet omdat een client die routes kan toevoegen maar niet verwijderen een kapotte tabel achterlaat. De resolver-query laat daarna zien of privénamen via de tunnel worden opgelost of weglekken naar de resolver die de host al vertrouwt.

Voer alle drie uit terwijl het testapparaat nog bestaat en verwijder het daarna. Een route die naar een verdwenen apparaat wijst, is de meest voorkomende reden dat een laptop na een mislukte verbinding de connectiviteit verliest.

Bepaal wat de sessie moet overleven

De map verwijderen is geen opruimplan. Adapters, routes, resolverinstellingen, vertrouwde certificaten en opgeslagen inloggegevens kunnen elk het proces overleven, en een service bij het opstarten kan sommige daarvan herstellen zonder te vragen. Schrijf op wat de client mag achterlaten voordat u hem start, niet na de eerste mislukte verbreking.

De praktische regel is een momentopname te maken van de drie oppervlakken die u gaat wijzigen en ze daarna te vergelijken. Registreer interfaces, de hoofd-routetabel en de resolverstatus vóór de eerste verbinding en herhaal dan dezelfde drie uitlezingen wanneer de client is afgesloten.

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

Alles wat in de tweede opname aanwezig is en in de eerste ontbreekt, heeft een eigenaar nodig. Ofwel de client verwijdert het bij het afsluiten, ofwel u verwijdert het met dezelfde opdrachten die het hebben gemaakt, en die verwijdering hoort in de uitrolnotities en niet in iemands herinnering aan wat er is gebeurd. Op Windows zijn de overeenkomstige uitlezingen Get-NetAdapter, Get-NetRoute en Get-DnsClientServerAddress, die geen verhoging nodig hebben maar dezelfde resten tonen.