Pi als VPN-client: één beheerder of een eigen script?

Een Raspberry Pi die alleen zijn eigen uitgaande verkeer hoeft te beschermen, heeft twee realistische ontwerpen: laat de netwerkbeheerder de tunnel bezitten, of houd een script dat hem bezit. Beide kunnen verkeer dragen. Ze falen op verschillende plekken, en de fout die je om twee uur ’s nachts op afstand kunt diagnosticeren, is degene die het waard is om te kiezen. Vergelijk ze op eigendom, op wat volledige tunnel betekent zodra IPv6 en DNS in het spel zijn, en op wat er gebeurt op het moment dat de tunnel wegvalt.

Twee eigenaren voor één tunnel

Ontwerp A is een profiel binnen de netwerkbeheerder van het systeem: een geïmporteerd OpenVPN-profiel of een native WireGuard-verbinding, bij het opstarten geactiveerd door dezelfde dienst die Ethernet en Wi-Fi opzet. Ontwerp B is een eigen eenheid die de client rechtstreeks draait, de resolverconfiguratie bewerkt en zijn eigen routes en firewallregels installeert. Beide zijn legitieme ontwerpen; ze verschillen in wie de routingtabel mag wijzigen.

De fouten verschillen omdat de eigenaren verschillen. Bij A laat een profiel dat niet activeert de interface omhoog en de tunnel omlaag, en de logs van de beheerder zeggen waarom. Bij B laat een script dat half slaagt routes achter die het proces dat ze maakte overleven. Beide draaien is de slechtste uitkomst: twee processen schrijven de standaardroute, twee resolverbewerkingen wedijveren bij het opstarten, en twee sets geheimen moeten worden geroteerd.

Kies één eigenaar per tunnel en schakel de andere uit voordat je iets test. Twee eigenaren betekent ook twee plekken om te kijken wanneer de tunnel omhoog is en niets wordt opgelost. Die ene regel voorkomt de meeste verwarrende toestanden die in Pi VPN-threads worden beschreven.

Wat een import maakt, en wat niet

Op Raspberry Pi OS Bookworm en later is het standaardhulpmiddel voor netwerkconfiguratie NetworkManager, dus een profiel is de natuurlijke thuisbasis voor een clienttunnel. De import vereist de juiste plug-in geïnstalleerd; zonder die faalt de import met een melding over een niet-ondersteund verbindingstype, wat het eerlijke signaal is om te stoppen en de plug-in te installeren.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

Importeren slaat een profiel op. Het bewijst niet dat de andere kant bereikbaar is, en het garandeert niet dat elke richtlijn in het bestand de conversie heeft overleefd. Lees de resulterende verbinding terug en controleer de delen die identiteit en vertrouwen dragen: het certificaat, de externe host en poort, en of er om een wachtwoord wordt gevraagd of dat het wordt opgeslagen.

Activeren met --ask houdt een wachtwoordzin buiten de shellgeschiedenis op een gedeelde machine. Voor een Pi zonder toezicht wil je uiteindelijk dat het profiel bij het opstarten omhoogkomt, wat een aparte beslissing is van het eenmalig met de hand omhoogbrengen.

Volledige tunnel, vergeleken over beide ontwerpen

Een volledige tunnel is een bewering over routes, niet over bedoeling, en de twee ontwerpen drukken dat verschillend uit. De profielaanpak vraagt de beheerder een standaardroute en zijn resolverinstellingen te installeren; de scriptaanpak doet wat het script zegt, inclusief niets. Geen van beide ontwerpen dekt IPv6 tenzij dat wordt gezegd, en een onaangeroerde IPv6-standaardroute vervoert graag verkeer buiten de tunnel terwijl IPv4 perfect lijkt.

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

Gebruik een documentatieadres voor de routeopvraag en vervang het door een host die je mag onderzoeken. De eerste opdracht laat zien welke interface de Pi voor een gewone bestemming zou gebruiken; de tweede laat zien of er nog een IPv6-standaardroute bestaat; de derde bewijst welke resolver antwoordde. Lees alle drie voordat je een bewering over een volledige tunnel gelooft.

Als de instructies van de provider een volledige tunnel beloven maar de IPv6-standaardroute overleeft, lekt de Pi. Schakel IPv6 op de uplink uit of vraag het profiel het op te eisen, en beslis bewust in plaats van het later te ontdekken.

Fail-open tegenover fail-closed

Wanneer de tunnel wegvalt, valt een routingtabel die zijn standaardroute verliest gewoon terug naar de fysieke uplink, en verkeer gaat open verder. Dat is fail-open, en het is het standaardgedrag van beide ontwerpen tenzij iets het verhindert. De meeste mensen ontdekken het weken later door een firewalllog te lezen.

Fail-closed kost je externe toegang wanneer de tunnel omlaag is, dus het vereist een bewuste uitzondering voor het beheerpad. Eén manier is een regel die buiten de tunnel alleen het adres van de VPN-peer toestaat:

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

Vergelijk de operationele kosten eerlijk. Een profiel kan deze regel meestal niet uitdrukken, dus fail-closed duwt je naar het scriptontwerp of naar een kleine eenheid die de regel onafhankelijk van de tunnel installeert. Hoe dan ook, log de weigeringen een week: een stille weigering ziet er identiek uit als een kapotte dienst, en je wilt de teller hebben wanneer een gebruiker meldt dat één site niet meer laadt.

Kiezen voor een Pi zonder scherm

Als de image al NetworkManager draait, de tunnel niets exotisch nodig heeft en je wilt dat hij de uplink automatisch volgt, neem het profiel. Als je beleidsrouting nodig hebt, meerdere per bestemming gekozen tunnels, of een fail-closed-regel die moet bestaan voordat de tunnel omhoogkomt, neem het script en bezit elk deel ervan, inclusief opstartvolgorde en opruiming. De twee ontwerpen mengen kost meer dan elk afzonderlijk.

Migreren tussen beide is vooral een kwestie van volgorde: schakel de oude eigenaar uit, bevestig dat er geen verouderde route of resolververmelding overleeft, activeer dan de nieuwe en herstart twee keer. Een enkele herstart kan een race verbergen die een tweede blootlegt. Eindig met het testen van de Pi in plaats van de tunnel: los een naam op, haal iets op via IPv4, haal op via IPv6 als je dat hebt gehouden, laat dan de tunnel vallen en bevestig dat het gedrag dat je koos echt gebeurt. Een interface in ip link is het begin van de test, niet het einde.