tun na ginawa nang maaga sa OpenVPN: paghahambing ng dalawang modelo ng pagmamay-ari

May gumawa ng tun1 nang maaga, sinasabi ng profile na dev tun1, at hindi pa rin kumakabit ang koneksyon. Halos walang sinasabi ang pagkakaroon ng pangalan sa host, dahil ang pagkabit ay nakadepende sa namespace, uri ng device, kung sino ang may-ari ng link at kung ano ang pinapayagan sa daemon. Ang muling paggamit ng device ay nagpipilit din ng desisyong itinatago ng default na configuration: aling bahagi ang nagsusulat ng mga address at ruta. Malaki ang pagkakaiba ng mga failure mode ng dalawang kaayusan kaysa sa mga linya ng configuration, kaya magpasya bago mag-edit ng profile.

Ang pangalan ay hindi pagkabit

Hinihiling ng dev tun1 sa OpenVPN ang pinangalanang interface na iyon, at susubukan itong buksan ng mga tradisyunal na build sa user space. Kung hindi sinusunod ng pangalan ang karaniwang tun o tap pattern, kailangan din ng profile ng tugmang dev-type, dahil hindi kailanman hinuhulaan ang uri mula sa isang string. Ang TAP device ay hindi TUN device na may ibang label: ang pagkabit ng mali ay mabibigo agad o gagawa ng link na nagdadala ng mga frame na walang inaasahan. Suriin ang uri bago ang lahat, dahil ipinapalagay ng bawat susunod na pagsusuri na magkasundo ang dalawang panig tungkol dito. Mula roon, tiyakin na talagang kayang buksan ng proseso ang device, hindi lang ito makita.

dev tun1
dev-type tun

Ang network interface at /dev/net/tun ay magkaibang bagay: ang isa ay link sa loob ng namespace, ang isa ay character device na ginagamit ng program sa user space para kumabit. Inilalarawan ng dokumentasyon ng Linux TUN/TAP ang landas ng pagkabit na iyon at ang mga tuntunin ng pagmamay-ari para sa mga persistent device. Ang root shell na kayang magpatakbo ng ip link ay nagpapatunay lamang na may mga pribilehiyo ang shell, hindi na mayroon ang daemon. Ang pagmamay-ari ng node ng device, ang set ng kakayahan ng serbisyo at ang user na pinagpapatakbuhan nito ay dapat magtugma lahat bago magtagumpay ang pagbubukas.

Ang device na umiiral at hindi mabuksan ay problema ng pagmamay-ari, hindi ng routing. Tratuhin ito nang ganoon habang nagde-debug, kung hindi mauubos ang hapon sa pagbasa ng mga routing table na hindi kailanman naging problema.

Sino ang nagko-configure ng link: dalawang modelo ng pagmamay-ari

Sa unang modelo, kinokonfigura ng OpenVPN ang mga address at ruta bilang bahagi ng pag-angat ng koneksyon. Iyon ang default na pag-uugali at pinakamadaling isipin, dahil isang bahagi lang ang gumagawa ng estado at pagkatapos ay tinatanggal ito. Sa ikalawang modelo, isang panlabas na manager ang may-ari ng interface, at pinipigilan ng ifconfig-noexec ang OpenVPN na patakbuhin ang mga utos nito sa configuration ng address at ipinapasa ang mga parameter sa mga script. Kailangan noon ng manager na siya mismo ang maglapat ng tamang lokal at peer na configuration, na mas maraming trabaho kaysa ipinahihiwatig ng pangalan ng opsyon. Ang pagpili sa dalawa ay tanong kung sino ang maaaring magbago ng link habang nakataas ito.

Saklaw ng ifconfig-noexec ang mga address lamang: hindi ginagalaw ang routing table, at pag-aari ng route-noexec ang configuration ng ruta. Tratuhin ang dalawang direktiba bilang magkahiwalay na kontrol na may magkahiwalay na may-ari, dahil ang pagtatakda ng isa at pagpapalagay ng isa pa ay karaniwang pinagmumulan ng kalahating naka-configure na link. Pumili ng eksaktong isang may-ari bawat layer, address sa isang lugar at ruta sa isang lugar. Ang network manager at VPN helper na parehong nagsusulat ng address ay ang paraan ng pagbura ng disconnect sa estadong umaasa pa ang kabilang panig.

Suriin ang device mula sa namespace na mahalaga

Suriin ang device mula sa namespace kung saan tumatakbo ang proseso ng VPN, hindi mula sa kung saan nagkataong naroroon ang iyong shell. Magkaibang tanong ang sinasagot ng dalawang utos sa ibaba, at lumilitaw ang pagkakaiba kapag may interface na nakikita ng host na hindi nakikita ng container. Patakbuhin ang mga ito sa ibinigay na pagkakasunod-sunod, dahil may kahulugan lamang ang pangalawa kapag alam mo kung may link ba talaga.

ip -details link show dev tun1
ip tuntap show

Ipinapakita ng unang utos ang link kung paano ito nakikita ng kernel, kasama ang mga flag at uri ng interface, at doon mo nakukumpirma na ito ang device na ibig mong sabihin. Inililista ng pangalawa ang mga persistent tun/tap entry, na umiiral nang walang prosesong humahawak sa mga ito. Ang interface na naghihintay sa itinakdang may-ari nito ay ibang sitwasyon kaysa sa buhay na tunnel na nakakabit sa ibang VPN, at ang pangalawa lamang ang nagpapaliwanag kung bakit nabibigo ang sarili mong pagkabit. Hanapin ang prosesong humahawak sa device bago magbago ng anuman, dahil magkaiba ang lunas ng persistent entry at ng abalang interface.

Ang multi-queue support ay partikular na kaayusan ng driver na may sariling mga pangangailangan, hindi permiso para sa magkakaugnay na proseso na maghati sa isang interface. Ang buhay na session ng ibang may-ari ay problema sa koordinasyon, at walang pag-edit ng profile ang makalulutas nito.

Dalawang uri ng pagtitiyaga

Ang pagtitiyaga ng kernel at persist-tun ay naglalarawan ng mga haba ng buhay na madaling paghalo at mamahaling pagkamalian. Ang persistent device ay umiiral nang hiwalay sa anumang proseso, kaya nakakaligtas ito sa paghinto at magagamit muli ng susunod na pag-start. Ang persist-tun ay nagpapanatili ng mga resource sa mga sinusuportahang soft reset sa loob ng isang proseso ng OpenVPN, mas maikling abot-tanaw. Wala sa dalawa ang nangangakong maiiwan ng paghinto ng serbisyo ang mga ruta at address sa kinalalagyan nito, at ang interface na nananatiling nakikita ay hindi patunay ng gumaganang naka-encrypt na session.

Tiyakin din ang backend, dahil walang sinasabi ang interface na ginawa nang maaga tungkol sa kung aling implementasyon ang magbubukas nito. Susubukan ng mga community build na may direktang data path na gamitin ito maliban kung sinasabi ng disenyo ang kabaligtaran. Kung saan sinusuportahan ng bersyon ang switch, pinipili ng disable-dco ang landas sa user space sa halip; wala ang gayong direktiba sa mas lumang engine at ibang kliyente, kaya itago ang kundisyon ng bersyon sa tabi ng opsyon sa halip na ipagpalagay na naaangkop ito.

Ano ang nasisira kapag simula lamang ang sinusubok

Ang kasunduan sa pagmamay-ari ay maaaring pumasa sa unang pagsubok at mabigo sa huli, na ginagawang mahinang tseke ang simula nang mag-isa. Pagmasdan sa halip ang dalawang transisyon: isang malambot na reset, at isang buong paghinto na sinusundan ng pag-start.

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

Ang simula ay ang madaling kaso: bumabangon ang unit, lumilitaw ang link, at pinapangalanan ng output ng status ang na-load na profile. Ang pagkabit ay ang sandali na binubuksan ng daemon ang device, kaya patakbuhin ang pagsusuri ng link pagkatapos iulat ng unit na aktibo ito, hindi bago. Kung umiiral ang link habang nag-a-activate pa ang status, tinitingnan mo ang persistent device na wala pang nakakabit, hindi gumaganang tunnel. Ipadala ang tunay na trapiko sa link bago magpatuloy, dahil ang nakakabit na interface na walang magagamit na ruta ay kabiguan pa rin.

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

Ang malambot na reset ay dapat mag-iwan sa session na magagamit at sa mga resource na buo, at iyon ang gawaing ginagawa ng persist-tun. Ang buong paghinto ang lugar kung saan inihahayag ng panlabas na manager ang sarili nito: kung ang link o ang mga address nito ay nakakaligtas sa paghinto, ibang tao ang may-ari ng mga ito, at ito ay alinman sa estadong naidokumento mo o sa bug na kararaanan mong natagpuan. Itala ang dalawang obserbasyon sa tabi ng profile, upang ang susunod na pagbabago ay magsimula sa ebidensya at hindi sa diagram.