Forhåndsopprettet tun i OpenVPN: sammenligning av de to eierskapsmodellene

Noen opprettet tun1 på forhånd, profilen sier dev tun1, og tilkoblingen fester seg fortsatt ikke. At navnet finnes på verten sier nesten ingenting, fordi festingen avhenger av navnerommet, enhetstypen, hvem som eier lenken og hva dæmonen har lov til. Gjenbruk av en enhet tvinger også fram et valg som standardkonfigurasjonen skjuler: hvilken komponent som skriver adressene og rutene. Feilmodusene til de to ordningene er langt mer forskjellige enn konfigurasjonslinjene, så bestem deg før du redigerer en profil.

Et navn er ikke en festing

dev tun1 ber OpenVPN om det navngitte grensesnittet, og tradisjonelle brukerromsbygg vil prøve å åpne det. Hvis navnet ikke følger det vanlige tun- eller tap-mønsteret, trenger profilen også en samsvarende dev-type, fordi typen aldri utledes fra en streng. En TAP-enhet er ikke en TUN-enhet med en annen etikett: å feste den gale feiler enten med en gang eller lager en lenke som bærer rammer ingen forventer. Sjekk typen før alt annet, siden hver senere sjekk forutsetter at begge sider er enige om den. Derfra må du bekrefte at prosessen faktisk kan åpne enheten, ikke bare se den.

dev tun1
dev-type tun

Nettverksgrensesnittet og /dev/net/tun er forskjellige objekter: det ene er en lenke inne i et navnerom, det andre er tegnenheten et program i brukerrommet bruker for å feste seg. Linux TUN/TAP-dokumentasjonen beskriver den festebanene og eierskapsreglene for vedvarende enheter. Et root-skal som kan kjøre ip link beviser bare at skallet har privilegier, ikke at dæmonen har dem. Eierskapet til enhetsnoden, tjenestens evnesett og brukeren den kjører som må alle stemme før åpningen lykkes.

En enhet som finnes og ikke kan åpnes, er et eierskapsproblem, ikke et rutingproblem. Behandle det som det når du feilsøker, ellers går ettermiddagen med til å lese rutingtabeller som aldri var problemet.

Hvem konfigurerer lenken: to eierskapsmodeller

I den første modellen konfigurerer OpenVPN adresser og ruter som en del av å heise tilkoblingen. Det er standardatferden og den enkleste å resonnere om, fordi én komponent lager tilstanden og fjerner den igjen. I den andre modellen eier en ekstern behandler grensesnittet, og ifconfig-noexec hindrer OpenVPN i å kjøre adressekonfigurasjonskommandoene sine og overlater parameterne til skript. Behandleren må da bruke den riktige lokale og peer-konfigurasjonen selv, noe som er mer arbeid enn navnet på alternativet antyder. Å velge mellom de to er et spørsmål om hvem som kan endre lenken mens den er oppe.

ifconfig-noexec dekker bare adresser: rutingtabellen er urørt, og rutekonfigurasjonen tilhører route-noexec. Behandle de to direktivene som separate kontroller med separate eiere, fordi det å sette den ene og anta den andre er en vanlig kilde til halvkonfigurerte lenker. Velg nøyaktig én eier per lag, adresser på ett sted og ruter på ett sted. En nettverksbehandler og en VPN-hjelper som begge skriver adresser, er måten en frakobling sletter tilstand den andre siden fortsatt er avhengig av.

Undersøk enheten fra navnerommet som betyr noe

Undersøk enheten fra navnerommet der VPN-prosessen kjører, ikke fra det skallet ditt tilfeldigvis er i. De to kommandoene nedenfor svarer på forskjellige spørsmål, og forskjellen vises når en vert ser et grensesnitt en container ikke ser. Kjør dem i gitt rekkefølge, fordi den andre bare gir mening når du vet om lenken i det hele tatt finnes.

ip -details link show dev tun1
ip tuntap show

Den første kommandoen skriver ut lenken slik kjernen ser den, inkludert flagg og grensesnitttype, og slik bekrefter du at dette er enheten du mente. Den andre lister vedvarende tun/tap-oppføringer, som finnes uten at noen prosess holder dem. Et grensesnitt som venter på sin tiltenkte eier er en annen situasjon enn en levende tunnel festet til en annen VPN, og bare den andre forklarer hvorfor din egen festing mislykkes. Finn prosessen som holder enheten før du endrer noe, fordi en vedvarende oppføring og et opptatt grensesnitt har forskjellige løsninger.

Støtte for flere køer er en bestemt driverordning med egne krav, ikke tillatelse for urelaterte prosesser til å dele ett grensesnitt. En levende sesjon fra en annen eier er et koordineringsproblem, og ingen profilendring løser det.

To ulike former for vedvarenhet

Kjernens vedvarenhet og persist-tun beskriver levetider som er lette å blande sammen og dyre å forveksle. En vedvarende enhet finnes uavhengig av enhver prosess, så den overlever en stans og kan gjenbrukes av neste start. persist-tun beholder ressursene gjennom støttede myke tilbakestillinger innenfor én OpenVPN-prosess, en mye kortere horisont. Ingen av dem lover at stansing av tjenesten lar ruter og adresser bli stående, og et grensesnitt som forblir synlig er ikke bevis på en fungerende kryptert sesjon.

Bekreft også backend, fordi et forhåndsopprettet grensesnitt ikke sier noe om hvilken implementasjon som åpner det. Fellesskapsbygg som har den direkte databanen vil prøve å bruke den, med mindre designet sier noe annet. Der versjonen støtter bryteren, velger disable-dco i stedet brukerromsbanen; eldre motorer og andre klienter har ingen slik direktiv, så hold versjonsbetingelsen ved siden av alternativet i stedet for å anta at den gjelder.

Hva som bryter når bare oppstart testes

En eierskapsavtale kan bestå den første testen og feile den siste, noe som gjør oppstart til en dårlig sjekk alene. Se på to overganger i stedet: en myk tilbakestilling, og en full stans etterfulgt av en start.

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

Oppstart er det enkle tilfellet: enheten kommer opp, lenken vises, og utdata fra statusen navngir profilen som ble lastet. Festingen er øyeblikket dæmonen åpner enheten, så kjør lenkesjekken etter at enheten rapporterer at den er aktiv, ikke før. Hvis lenken finnes mens statusen fortsatt aktiveres, ser du på en vedvarende enhet ingen ennå har festet seg til, ikke en fungerende tunnel. Slipp ekte trafikk gjennom lenken før du går videre, fordi et festet grensesnitt uten brukbar rute fortsatt er en feil.

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

En myk tilbakestilling bør la sesjonen være brukbar og ressursene intakte, og det er jobben persist-tun gjør. En full stans er stedet der en ekstern behandler avslører seg: hvis lenken eller adressene overlever stansen, eier noen andre dem, og det er enten tilstanden du dokumenterte eller feilen du nettopp fant. Noter begge observasjonene ved siden av profilen, slik at neste endring starter fra bevis og ikke fra et diagram.