Vooraf aangemaakte tun in OpenVPN: de twee eigendomsmodellen vergeleken

Iemand heeft tun1 vooraf aangemaakt, het profiel zegt dev tun1, en de verbinding maakt nog steeds geen verbinding. Het bestaan van de naam op de host zegt bijna niets, omdat het koppelen afhangt van de naamruimte, het apparaattype, wie de link bezit en wat de daemon mag doen. Hergebruik van een apparaat dwingt ook een beslissing af die de standaardconfiguratie verbergt: welke component de adressen en routes schrijft. De faalwijzen van de twee opstellingen verschillen veel meer dan de configuratieregels, dus beslis voordat u een profiel bewerkt.

Een naam is geen koppeling

dev tun1 vraagt OpenVPN om die genoemde interface, en traditionele builds in de gebruikersruimte zullen proberen die te openen. Als de naam niet het gebruikelijke tun- of tappatroon volgt, heeft het profiel ook een bijpassende dev-type nodig, omdat het type nooit uit een tekenreeks wordt afgeleid. Een TAP-apparaat is geen TUN-apparaat met een ander label: het verkeerde koppelen mislukt ofwel meteen, ofwel levert een link op die frames draagt die niemand verwacht. Controleer het type vóór al het andere, want elke latere controle veronderstelt dat beide kanten het erover eens zijn. Bevestig daarna dat het proces het apparaat echt kan openen, en niet alleen kan zien.

dev tun1
dev-type tun

De netwerkinterface en /dev/net/tun zijn verschillende objecten: de ene is een link binnen een naamruimte, de andere is het tekenapparaat dat een programma in de gebruikersruimte gebruikt om te koppelen. De Linux TUN/TAP-documentatie beschrijft dat koppelpad en de eigendomsregels voor persistente apparaten. Een rootshell die ip link kan uitvoeren bewijst alleen dat de shell privileges heeft, niet dat de daemon ze heeft. Eigendom van het apparaatknooppunt, de capaciteitenset van de dienst en de gebruiker waaronder die draait moeten allemaal kloppen voordat het openen slaagt.

Een apparaat dat bestaat en niet kan worden geopend, is een eigendomsprobleem, geen routeringsprobleem. Behandel het zo tijdens het debuggen, anders gaat de middag op aan het lezen van routeringstabellen die nooit het probleem waren.

Wie configureert de link: twee eigendomsmodellen

In het eerste model configureert OpenVPN adressen en routes als onderdeel van het opzetten van de verbinding. Dat is het standaardgedrag en het eenvoudigst te beredeneren, omdat één component de toestand maakt en weer verwijdert. In het tweede model bezit een externe beheerder de interface, en ifconfig-noexec verhindert dat OpenVPN zijn adresconfiguratieopdrachten uitvoert en geeft de parameters in plaats daarvan aan scripts. De beheerder moet dan zelf de juiste lokale en peer-configuratie toepassen, wat meer werk is dan de naam van de optie suggereert. Kiezen tussen de twee is een kwestie van wie de link mag wijzigen terwijl die actief is.

ifconfig-noexec dekt alleen adressen: de routeringstabel blijft onaangeroerd, en routeconfiguratie hoort bij route-noexec. Behandel de twee richtlijnen als afzonderlijke besturingselementen met afzonderlijke eigenaren, want het ene instellen en het andere aannemen is een veelvoorkomende bron van half geconfigureerde links. Kies precies één eigenaar per laag, adressen op één plek en routes op één plek. Een netwerkbeheerder en een VPN-hulp die beide adressen schrijven, is hoe een verbreking toestand wist waarvan de andere kant nog afhankelijk is.

Inspecteer het apparaat vanuit de naamruimte die ertoe doet

Inspecteer het apparaat vanuit de naamruimte waarin het VPN-proces draait, niet vanuit die waarin uw shell toevallig zit. De twee opdrachten hieronder beantwoorden verschillende vragen, en het verschil blijkt wanneer een host een interface ziet die een container niet ziet. Voer ze in de gegeven volgorde uit, want de tweede heeft alleen zin als u weet of de link überhaupt bestaat.

ip -details link show dev tun1
ip tuntap show

De eerste opdracht drukt de link af zoals de kernel die ziet, inclusief vlaggen en interfacetype, en zo bevestigt u dat dit het bedoelde apparaat is. De tweede somt persistente tun/tap-vermeldingen op, die bestaan zonder dat een proces ze vasthoudt. Een interface die op zijn bedoelde eigenaar wacht is een andere situatie dan een levende tunnel die aan een andere VPN is gekoppeld, en alleen de tweede verklaart waarom uw eigen koppeling mislukt. Zoek het proces dat het apparaat vasthoudt voordat u iets wijzigt, want een persistente vermelding en een bezette interface hebben verschillende oplossingen.

Ondersteuning voor meerdere wachtrijen is een specifieke driveropstelling met eigen eisen, geen toestemming voor ongerelateerde processen om één interface te delen. Een levende sessie van een andere eigenaar is een coördinatieprobleem, en geen enkele profielwijziging lost dat op.

Twee soorten persistentie

Kernelpersistentie en persist-tun beschrijven levensduren die gemakkelijk te verwarren en duur zijn om te verwisselen. Een persistent apparaat bestaat onafhankelijk van enig proces, dus het overleeft een stop en kan door de volgende start opnieuw worden gebruikt. persist-tun houdt bronnen vast over ondersteunde zachte resets binnen één OpenVPN-proces, een veel kortere horizon. Geen van beide belooft dat het stoppen van de dienst routes en adressen op hun plaats laat, en een interface die zichtbaar blijft is geen bewijs van een werkende versleutelde sessie.

Controleer ook de backend, want een vooraf aangemaakte interface zegt niets over welke implementatie die opent. Communitybuilds met het directe datapad zullen proberen die te gebruiken, tenzij het ontwerp anders zegt. Waar de versie de schakelaar ondersteunt, kiest disable-dco in plaats daarvan het pad in de gebruikersruimte; oudere engines en andere clients hebben zo'n richtlijn niet, dus houd de versie-voorwaarde naast de optie in plaats van aan te nemen dat die geldt.

Wat breekt als alleen het opstarten wordt getest

Een eigendomsovereenkomst kan de eerste test doorstaan en de laatste niet, waardoor opstarten op zichzelf een slechte controle is. Let in plaats daarvan op twee overgangen: een zachte reset, en een volledige stop gevolgd door een start.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Opstarten is het gemakkelijke geval: de eenheid komt omhoog, de link verschijnt en de statusuitvoer noemt het geladen profiel. Koppelen is het moment waarop de daemon het apparaat opent, dus voer de linkcontrole uit nadat de eenheid meldt dat die actief is, niet daarvoor. Als de link bestaat terwijl de status nog activeert, kijkt u naar een persistent apparaat waar nog niemand aan gekoppeld is, niet naar een werkende tunnel. Stuur echte verkeer door de link voordat u verdergaat, want een gekoppelde interface zonder bruikbare route is nog steeds een fout.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Een zachte reset hoort de sessie bruikbaar en de bronnen intact te laten, en dat is het werk dat persist-tun doet. Een volledige stop is de plek waar een externe beheerder zichzelf verraadt: als de link of zijn adressen de stop overleven, bezit iemand anders ze, en dat is ofwel de toestand die u documenteerde ofwel de bug die u net vond. Noteer beide waarnemingen naast het profiel, zodat de volgende wijziging begint bij bewijs en niet bij een diagram.