Antaŭkreita tun de OpenVPN: komparu la du posedmodelojn

Iu tun1 antaŭe kreis, la profilo diras dev tun1, kaj la konekto tamen ne alkroĉiĝas. La nomo ekzistanta sur la gastiganto diras preskaŭ nenion, ĉar la alkroĉiĝo dependas de la nomspaco, la aparata tipo, kiu posedas la ligilon kaj kion la demono rajtas fari. Reuzi aparaton ankaŭ devigas decidon, kiun la defaŭlta agordo kaŝas: kiu komponanto skribas la adresojn kaj itinerojn. La malsukcesaj reĝimoj de la du aranĝoj malsamas multe pli ol la agordaj linioj, do decidu antaŭ ol redakti profilon.

Nomo ne estas alkroĉiĝo

dev tun1 petas de OpenVPN tiun nomitan interfacon, kaj tradiciaj uzer-spacaj konstruoj provos malfermi ĝin. Se la nomo ne sekvas la kutiman ŝablonon tun aŭ tap, la profilo ankaŭ bezonas kongruan dev-type, ĉar la tipo neniam estas deduktata el ĉeno. TAP-aparato ne estas TUN-aparato kun alia etikedo: alkroĉi la malĝustan aŭ tute malsukcesas aŭ produktas ligilon, kiu portas kadrojn, kiujn neniu atendas. Kontrolu la tipon antaŭ ĉio alia, ĉar ĉiu posta kontrolo supozas, ke la du flankoj konsentas pri ĝi. De tie, konfirmu, ke la procezo povas efektive malfermi la aparaton, ne nur vidi ĝin.

dev tun1
dev-type tun

La retinterfaco kaj /dev/net/tun estas malsamaj objektoj: unu estas ligilo ene de nomspaco, la alia estas la signa aparato, kiun uzer-spaca programo uzas por alkroĉiĝi. Linux TUN/TAP-dokumentaro priskribas tiun alkroĉiĝan vojon kaj la posedregulojn por persistentaj aparatoj. Radika ŝelo, kiu povas ruli ip link pruvas nur, ke la ŝelo havas privilegiojn, ne ke la demono havas ilin. Posedo de la aparata nodo, la kapabla aro de la servo kaj la uzanto, sub kiu ĝi ruliĝas ĉiuj devas kongrui antaŭ ol la malfermo sukcesos.

Aparato, kiu ekzistas kaj ne povas esti malfermita, estas posedproblemo, ne itinerproblemo. Traktu ĝin tiel dum sencimigado, alie la posttagmezo foriĝos legante itinerajn tabelojn, kiuj neniam estis la problemo.

Kiu agordas la ligilon: du posedmodeloj

En la unua modelo OpenVPN agordas adresojn kaj itinerojn kiel parton de starigo de la konekto. Tio estas la defaŭlta konduto kaj la plej facile pripensebla, ĉar unu komponanto kreas la staton kaj forigas ĝin denove. En la dua modelo ekstera administranto posedas la interfacon, kaj ifconfig-noexec malhelpas OpenVPN ruli siajn adresagordajn komandojn kaj transdonas la parametrojn al skriptoj anstataŭe. La administranto tiam devas mem apliki la ĝustan lokan kaj peer-agordon, kio estas pli da laboro ol la nomo de la opcio sugestas. Elekti inter la du estas demando pri tio, kiu rajtas ŝanĝi la ligilon dum ĝi estas aktiva.

ifconfig-noexec kovras nur adresojn: la itinera tabelo restas netuŝita, kaj itinera agordo apartenas al route-noexec. Traktu la du direktivojn kiel apartajn regilojn kun apartaj posedantoj, ĉar agordi unu kaj supozi la alian estas ofta fonto de duonagorditaj ligiloj. Elektu precize unu posedanton por tavolo, adresojn en unu loko kaj itinerojn en unu loko. Reta administranto kaj VPN-helpa programo, kiuj ambaŭ skribas adresojn, estas la maniero kiel malkonekto forigas staton, de kiu la alia flanko ankoraŭ dependas.

Ekzamenu la aparaton el la nomspaco, kiu gravas

Ekzamenu la aparaton el la nomspaco, en kiu ruliĝas la VPN-procezo, ne el tiu, en kiu via ŝelo hazarde troviĝas. La du komandoj sube respondas malsamajn demandojn, kaj la diferenco montriĝas, kiam gastiganto vidas interfacon, kiun ujo ne povas vidi. Rulu ilin en la donita ordo, ĉar la dua nur sencas post kiam vi scias, ĉu la ligilo entute ekzistas.

ip -details link show dev tun1
ip tuntap show

La unua komando presas la ligilon tiel, kiel la kerno vidas ĝin, inkluzive flagojn kaj interfacan tipon, kaj tiel vi konfirmas, ke ĉi tio estas la celita aparato. La dua listigas persistentajn tun/tap-enskribojn, kiuj ekzistas sen iu ajn procezo tenanta ilin. Interfaco atendanta sian celitan posedanton estas alia situacio ol viva tunelo alkroĉita al alia VPN, kaj nur la dua klarigas, kial via propra alkroĉiĝo malsukcesas. Trovu la procezon tenantan la aparaton antaŭ ol ŝanĝi ion ajn, ĉar persistanta enskribo kaj okupata interfaco havas malsamajn solvojn.

Multiqueue-subteno estas specifa pelila aranĝo kun propraj postuloj, ne permeso por nerilataj procezoj kunhavi unu interfacon. Viva sesio de alia posedanto estas kunordiga problemo, kaj neniu profila redakto solvas ĝin.

Du malsamaj specoj de persisteco

Kerna persisteco kaj persist-tun priskribas vivdaŭrojn, kiujn oni facile kunfandas kaj multekoste konfuzas. Persistanta aparato ekzistas sendepende de iu ajn procezo, do ĝi postvivas halton kaj povas esti reuzata de la sekva starto. persist-tun konservas rimedojn tra subtenataj molaj restarigoj ene de unu OpenVPN-procezo, multe pli mallonga horizonto. Neniu promesas, ke halto de la servo lasas itinerojn kaj adresojn surloke, kaj interfaco, kiu restas videbla, ne estas pruvo de funkcianta ĉifrita sesio.

Konfirmu ankaŭ la malantalon, ĉar antaŭkreita interfaco diras nenion pri tio, kiu efektivigo malfermos ĝin. Komunumaj konstruoj, kiuj portas la rektan datenvojon, provos uzi ĝin, se la dezajno ne diras alie. Kie versio subtenas la ŝaltilon, disable-dco elektas la uzer-spacan vojon anstataŭe; pli malnovaj motoroj kaj aliaj klientoj ne havas tian direktivon, do tenu la versian kondiĉon apud la opcio anstataŭ supozi, ke ĝi validas.

Kio rompiĝas, kiam oni testas nur la starton

Posedinterkonsento povas trapasi la unuan teston kaj malsukcesi en la lasta, kio igas la starton mallonga kontrolo sole. Observu anstataŭe du transirojn: molan restarigon kaj plenan halton sekvatan de starto.

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

Starto estas la facila kazo: la unuo ekfunkcias, la ligilo aperas, kaj la stateligilo nomas la profilon, kiu ŝargiĝis. Alkroĉiĝo estas la momento, kiam la demono malfermas la aparaton, do rulu la ligilan kontrolon post kiam la unuo raportas aktivecon, ne antaŭe. Se la ligilo ekzistas dum la stato ankoraŭ aktivigas, vi rigardas persistentan aparaton, al kiu ankoraŭ neniu alkroĉiĝis, ne funkciantan tunelon. Sendu realan trafikon tra la ligilo antaŭ ol daŭrigi, ĉar alkroĉita interfaco sen uzebla itinero ankoraŭ estas malsukceso.

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

Mola restarigo devus lasi la sesion uzebla kaj la rimedojn sendifektaj, kio estas la tasko, kiun persist-tun plenumas. Plena halto estas kie ekstera administranto malkaŝiĝas: se la ligilo aŭ ĝiaj adresoj postvivas la halton, iu alia posedas ilin, kaj tio estas aŭ la stato, kiun vi dokumentis, aŭ la cimo, kiun vi ĵus trovis. Notu ambaŭ observojn apud la profilo, por ke la sekva ŝanĝo komenciĝu de pruvoj anstataŭ de diagramo.