Førehandsopretta tun i OpenVPN: samanlikning av dei to eigarskapsmodellane

Nokon oppretta tun1 på førehand, profilen seier dev tun1, og tilkoplinga festar seg framleis ikkje. At namnet finst på verten seier nesten ingenting, fordi festinga avheng av namnerommet, einingstypen, kven som eig lenka og kva dæmonen har lov til. Å bruke ei eining om att tvingar òg fram eit val som standardoppsettet skjuler: kva komponent som skriv adressene og rutene. Feilmodusane til dei to ordningane er langt meir ulike enn konfigurasjonslinjene, så avgjer før du redigerer ein profil.

Eit namn er ikkje ei festing

dev tun1 ber OpenVPN om det namngjevne grensesnittet, og tradisjonelle bygg i brukarrommet vil prøve å opne det. Viss namnet ikkje følgjer det vanlege tun- eller tap-mønsteret, treng profilen òg ein samsvarande dev-type, fordi typen aldri vert utleidd frå ein streng. Ei TAP-eining er ikkje ei TUN-eining med ei anna etikett: å feste den gale feilar anten med ein gong eller lagar ei lenke som ber rammer ingen ventar. Sjekk typen før alt anna, sidan kvar seinare sjekk føreset at begge sider er samde om han. Derifrå må du stadfeste at prosessen faktisk kan opne eininga, ikkje berre sjå henne.

dev tun1
dev-type tun

Nettverksgrensesnittet og /dev/net/tun er ulike objekt: det eine er ei lenke inne i eit namnerom, det andre er teikneininga eit program i brukarrommet brukar for å feste seg. Linux TUN/TAP-dokumentasjonen skildrar den festebana og eigarskapsreglane for vedvarande einingar. Eit root-skal som kan køyre ip link beviser berre at skalet har privilegium, ikkje at dæmonen har dei. Eigarskapet til einingsknuten, evnesettet til tenesta og brukaren ho køyrer som må alle stemme før opninga lykkast.

Ei eining som finst og ikkje kan opnast, er eit eigarskapsproblem, ikkje eit ruteproblem. Handsame det som det når du feilsøkjer, elles går ettermiddagen med til å lese rutetabellar som aldri var problemet.

Kven konfigurerer lenka: to eigarskapsmodellar

I den første modellen konfigurerer OpenVPN adresser og ruter som ein del av å heise tilkoplinga. Det er standardåtferda og den enklaste å resonnere om, fordi éin komponent lagar tilstanden og fjernar han att. I den andre modellen eig ein ekstern behandlar grensesnittet, og ifconfig-noexec hindrar OpenVPN i å køyre adressekonfigurasjonskommandoane sine og overlèt parametrane til skript. Behandlaren må då bruke den rette lokale og peer-konfigurasjonen sjølv, noko som er meir arbeid enn namnet på valet antydar. Å velje mellom dei to er eit spørsmål om kven som kan endre lenka medan ho er oppe.

ifconfig-noexec dekkjer berre adresser: rutetabellen er urørt, og rutekonfigurasjonen høyrer til route-noexec. Handsame dei to direktiva som separate kontrollar med separate eigarar, fordi det å setje den eine og anta den andre er ei vanleg kjelde til halvkonfigurerte lenker. Vel nøyaktig éin eigar per lag, adresser på éin stad og ruter på éin stad. Ein nettverksbehandlar og ein VPN-hjelpar som båe skriv adresser, er måten ein fråkobling slettar tilstand den andre sida framleis er avhengig av.

Undersøk eininga frå namnerommet som betyr noko

Undersøk eininga frå namnerommet der VPN-prosessen køyrer, ikkje frå det skalet ditt tilfeldigvis er i. Dei to kommandoane nedanfor svarar på ulike spørsmål, og skillnaden viser seg når ein vert ser eit grensesnitt ein container ikkje ser. Køyr dei i gjeven rekkjefølgje, fordi den andre berre gjev meining når du veit om lenka i det heile finst.

ip -details link show dev tun1
ip tuntap show

Den første kommandoen skriv ut lenka slik kjernen ser henne, inkludert flagg og grensesnitttype, og slik stadfester du at dette er eininga du meinte. Den andre listar vedvarande tun/tap-oppføringar, som finst utan at nokon prosess held dei. Eit grensesnitt som ventar på sin tiltenkte eigar er ein annan situasjon enn ein levande tunnel fest til ein annan VPN, og berre den andre forklarar kvifor di eiga festing mislykkast. Finn prosessen som held eininga før du endrar noko, fordi ei vedvarande oppføring og eit oppteke grensesnitt har ulike løysingar.

Støtte for fleire køar er ei bestemd drivarordning med eigne krav, ikkje løyve for urelaterte prosessar til å dele eitt grensesnitt. Ein levande sesjon frå ein annan eigar er eit koordineringsproblem, og inga profilendring løyser det.

To ulike former for vedvarenheit

Kjernens vedvarenheit og persist-tun skildrar levetider som er lette å blande saman og dyre å forveksle. Ei vedvarande eining finst uavhengig av kvar prosess, så ho overlever ein stans og kan brukast på nytt av neste start. persist-tun held ressursane gjennom støtta mjuke tilbakestillingar innanfor éin OpenVPN-prosess, ein mykje kortare horisont. Ingen av dei lovar at stansing av tenesta lèt ruter og adresser bli ståande, og eit grensesnitt som blir synleg er ikkje prov på ein fungerande kryptert sesjon.

Stadfest òg backend, fordi eit førehandsopretta grensesnitt ikkje seier noko om kva implementasjon som opnar det. Fellesskapsbygg som har den direkte databana vil prøve å bruke henne, med mindre designet seier noko anna. Der versjonen støttar brytaren, vel disable-dco i staden brukarromsbana; eldre motorar og andre klientar har ingen slik direktiv, så hald versjonsvilkåret ved sida av valet i staden for å anta at det gjeld.

Kva som bryt når berre oppstart blir testa

Ein eigarskapsavtale kan bestå den første testen og feile den siste, noko som gjer oppstart til ein dårleg sjekk åleine. Sjå på to overgangar i staden: ein mjuk tilbakestilling, og ein full stans følgd av ein start.

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

Oppstart er det enkle tilfellet: eininga kjem opp, lenka viser seg, og utdata frå statusen namngjev profilen som vart lasta. Festinga er augneblinken dæmonen opnar eininga, så køyr lenkesjekken etter at eininga rapporterer at ho er aktiv, ikkje før. Viss lenka finst medan statusen framleis aktiverer, ser du på ei vedvarande eining ingen enno har fest seg til, ikkje ein fungerande tunnel. Slipp ekte trafikk gjennom lenka før du går vidare, fordi eit fest grensesnitt utan brukbar rute framleis er ein feil.

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

Ein mjuk tilbakestilling bør la sesjonen vere brukbar og ressursane intakte, og det er jobben persist-tun gjer. Ein full stans er staden der ein ekstern behandlar avslører seg: viss lenka eller adressene overlever stansen, eig nokon andre dei, og det er anten tilstanden du dokumenterte eller feilen du nettopp fann. Noter båe observasjonane ved sida av profilen, slik at neste endring startar frå prov og ikkje frå eit diagram.