Forudoprettet tun i OpenVPN: sammenlign de to ejerskabsmodeller

Nogen har tun1 oprettet på forhånd, profilen siger dev tun1, og forbindelsen knytter sig stadig ikke til. Navnet, der findes på værten, siger næsten intet, fordi tilknytningen afhænger af navnerummet, enhedstypen, hvem der ejer linket, og hvad dæmonen må gøre. Genbrug af en enhed tvinger også en beslutning, som standardkonfigurationen skjuler: hvilken komponent der skriver adresserne og ruterne. De to arrangementers fejltilstande adskiller sig langt mere end konfigurationslinjerne, så beslut dig, før du redigerer en profil.

Et navn er ikke en tilknytning

dev tun1 beder OpenVPN om det navngivne interface, og traditionelle brugerspace-builds vil forsøge at åbne det. Hvis navnet ikke følger det sædvanlige tun- eller tap-mønster, har profilen også brug for en tilsvarende dev-type, fordi typen aldrig udledes af en streng. En TAP-enhed er ikke en TUN-enhed med en anden etiket: at knytte den forkerte til fejler enten helt eller giver et link, der bærer rammer, som ingen forventer. Kontroller typen før noget andet, da hver senere kontrol forudsætter, at de to sider er enige om den. Bekræft derefter, at processen faktisk kan åbne enheden og ikke blot se den.

dev tun1
dev-type tun

Netværksinterfacet og /dev/net/tun er forskellige objekter: det ene er et link inde i et navnerum, det andet er den tegneenhed, som et brugerspace-program bruger til at knytte til. Linux TUN/TAP-dokumentation beskriver den tilknytningsvej og ejerskabsreglerne for persistente enheder. Et root-shell, der kan køre ip link beviser kun, at shellen har privilegier, ikke at dæmonen har dem. Ejerskab af enhedsknudepunktet, tjenestens kapabilitetssæt og den bruger, den kører som skal alle stemme, før åbningen lykkes.

En enhed, der findes og ikke kan åbnes, er et ejerskabsproblem, ikke et routingproblem. Behandl det som sådant under fejlfinding, ellers går eftermiddagen med at læse routingtabeller, der aldrig var problemet.

Hvem konfigurerer linket: to ejerskabsmodeller

I den første model konfigurerer OpenVPN adresser og ruter som en del af at bringe forbindelsen op. Det er standardadfærden og den nemmeste at ræsonnere om, fordi én komponent opretter tilstanden og fjerner den igen. I den anden model ejer en ekstern manager interfacet, og ifconfig-noexec forhindrer OpenVPN i at køre sine adressekonfigurationskommandoer og giver i stedet parametrene til scripts. Manageren skal så selv anvende den korrekte lokale og peer-konfiguration, hvilket er mere arbejde, end optionens navn antyder. Valget mellem de to er et spørgsmål om, hvem der må ændre linket, mens det er oppe.

ifconfig-noexec dækker kun adresser: routingtabellen er urørt, og rutekonfiguration hører til route-noexec. Behandl de to direktiver som separate kontroller med separate ejere, fordi det at sætte den ene og antage den anden er en almindelig kilde til halvkonfigurerede links. Vælg præcis én ejer pr. lag, adresser ét sted og ruter ét sted. En netværksmanager og en VPN-hjælper, der begge skriver adresser, er hvordan en afbrydelse sletter tilstand, som den anden side stadig afhænger af.

Inspicér enheden fra det navnerum, der betyder noget

Inspicér enheden fra det navnerum, VPN-processen kører i, ikke fra det, din shell tilfældigvis er i. De to kommandoer nedenfor besvarer forskellige spørgsmål, og forskellen viser sig, når en vært ser et interface, som en container ikke kan se. Kør dem i den angivne rækkefølge, fordi den anden kun giver mening, når du ved, om linket overhovedet findes.

ip -details link show dev tun1
ip tuntap show

Den første kommando udskriver linket, som kernen ser det, inklusive flag og interfacetype, og det er sådan, du bekræfter, at dette er den enhed, du mente. Den anden viser persistente tun/tap-poster, som findes uden nogen proces, der holder dem. Et interface, der venter på sin tiltænkte ejer, er en anden situation end en levende tunnel, der er knyttet til en anden VPN, og kun den anden forklarer, hvorfor din egen tilknytning fejler. Find processen, der holder enheden, før du ændrer noget, da en persistent post og et travlt interface har forskellige løsninger.

Multiqueue-understøttelse er et bestemt driverarrangement med egne krav, ikke tilladelse til at urelaterede processer deler ét interface. En anden ejers levende session er et koordineringsproblem, og ingen profilredigering løser det.

To forskellige slags persistens

Kernens persistens og persist-tun beskriver levetider, der er lette at sammenblande og dyre at forveksle. En persistent enhed eksisterer uafhængigt af enhver proces, så den overlever et stop og kan genbruges ved næste start. persist-tun bevarer ressourcer gennem understøttede bløde resets inde i én OpenVPN-proces, en meget kortere horisont. Ingen af dem lover, at stop af tjenesten efterlader ruter og adresser på plads, og et interface, der forbliver synligt, er ikke bevis på en fungerende krypteret session.

Bekræft også backend, fordi et forudoprettet interface intet siger om, hvilken implementering der åbner det. Fællesskabsbuilds, der bærer den direkte datasti, vil forsøge at bruge det, medmindre designet siger andet. Hvor en version understøtter kontakten, disable-dco vælger den brugerspace-stien i stedet; ældre motorer og andre klienter har ikke et sådant direktiv, så hold versionsbetingelsen ved optionen i stedet for at antage, at den gælder.

Hvad der brækker, når kun opstart testes

En ejerskabsaftale kan bestå den første test og fejle den sidste, hvilket gør opstart til en dårlig kontrol alene. Hold i stedet øje med to overgange: et blødt reset og et fuldt stop efterfulgt af en start.

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

Opstart er det nemme tilfælde: enheden kommer op, linket vises, og statusoutputtet navngiver den profil, der blev indlæst. Tilknytning er det øjeblik, dæmonen åbner enheden, så kør linkkontrollen, efter at enheden rapporterer aktiv, ikke før. Hvis linket findes, mens status stadig aktiverer, ser du på en persistent enhed, som ingen har knyttet til endnu, ikke en fungerende tunnel. Send rigtig trafik gennem linket, før du går videre, fordi et tilknyttet interface uden en brugbar rute stadig er en fejl.

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

Et blødt reset bør efterlade sessionen brugbar og ressourcerne intakte, hvilket er det arbejde, persist-tun udfører. Et fuldt stop er, hvor en ekstern manager afslører sig selv: hvis linket eller dets adresser overlever stoppet, ejer nogen andre dem, og det er enten den tilstand, du dokumenterede, eller den fejl, du netop fandt. Notér begge observationer ved siden af profilen, så den næste ændring starter fra bevis i stedet for fra et diagram.