OpenVPN se vooraf geskepte tun: vergelyk die twee eienaarskapmodelle

Iemand het tun1 vooraf geskep, die profiel sê dev tun1, en die verbinding sal steeds nie aanknoop nie. Die naam wat op die gasheer bestaan sê byna niks, want die aankoppeling hang af van die naamruimte, die toesteltipe, wie die skakel besit en wat die daemon mag doen. Om 'n toestel te hergebruik dwing ook 'n besluit wat die verstekkonfigurasie verberg: watter komponent die adresse en roetes skryf. Die foutmodusse van die twee reëlings verskil veel meer as die konfigurasielyne, so besluit voordat jy 'n profiel wysig.

'n Naam is nie 'n aankoppeling nie

dev tun1 vra OpenVPN vir daardie genoemde koppelvlak, en tradisionele gebruikersruimte-boude sal probeer om dit oop te maak. As die naam nie die gewone tun- of tap-patroon volg nie, het die profiel ook 'n ooreenstemmende dev-type, want die tipe word nooit uit 'n string afgelei nie. 'n TAP-toestel is nie 'n TUN-toestel met 'n ander etiket nie: om die verkeerde een aan te koppel misluk heeltemal of lewer 'n skakel wat rame dra wat niks verwag nie. Kontroleer die tipe voor enigiets anders, want elke latere kontrole aanvaar dat die twee kante daaroor saamstem. Bevestig daarna dat die proses die toestel werklik kan oopmaak, nie net sien nie.

dev tun1
dev-type tun

Die netwerkkoppelvlak en /dev/net/tun is verskillende objekte: een is 'n skakel binne 'n naamruimte, die ander is die karaktertoestel wat 'n gebruikersruimte-program gebruik om aan te koppel. Die Linux TUN/TAP-dokumentasie beskryf daardie aankoppelingspad en die eienaarskapreëls vir persistente toestelle. 'n Root-dop wat ip link kan uitvoer, bewys net dat die dop voorregte het, nie dat die daemon dit het nie. Eienaarskap van die toestelknoop, die vermoënsversameling van die diens en die gebruiker waaronder dit loop moet almal in lyn wees voordat die oopmaak slaag.

'n Toestel wat bestaan en nie oopgemaak kan word nie, is 'n eienaarskapprobleem, nie 'n roeteprobleem nie. Behandel dit so tydens ontfouting, anders gaan die middag in die lees van roetetabelle wat nooit die probleem was nie.

Wie konfigureer die skakel: twee eienaarskapmodelle

In die eerste model konfigureer OpenVPN adresse en roetes as deel van die opbring van die verbinding. Dit is die verstekgedrag en die maklikste om oor te redeneer, want 'n enkele komponent skep die toestand en verwyder dit weer. In die tweede model besit 'n eksterne bestuurder die koppelvlak, en ifconfig-noexec verhoed OpenVPN om sy adreskonfigurasie-opdragte uit te voer en gee die parameters eerder aan scripte oor. Die bestuurder moet dan self die korrekte plaaslike en eweknie-konfigurasie toepas, wat meer werk is as wat die opsienaam voorstel. Om tussen die twee te kies is 'n vraag oor wie die skakel mag verander terwyl dit op is.

ifconfig-noexec dek net adresse: die roetetabel bly onaangeraak, en roetekonfigurasie behoort aan route-noexec. Behandel die twee riglyne as afsonderlike kontroles met afsonderlike eienaars, want om een te stel en die ander te veronderstel is 'n algemene bron van halfgekonfigureerde skakels. Kies presies een eienaar per laag, adresse op een plek en roetes op een plek. 'n Netwerkbestuurder en 'n VPN-hulp wat albei adresse skryf, is hoe 'n ontkoppeling toestand verwyder waarvan die ander kant nog afhanklik is.

Ondersoek die toestel vanuit die naamruimte wat saak maak

Ondersoek die toestel vanuit die naamruimte waarin die VPN-proses loop, nie vanuit dié waarin jou dop toevallig is nie. Die twee opdragte hieronder beantwoord verskillende vrae, en die verskil wys wanneer 'n gasheer 'n koppelvlak sien wat 'n houer nie kan sien nie. Voer hulle in die gegewe volgorde uit, want die tweede maak net sin sodra jy weet of die skakel hoegenaamd bestaan.

ip -details link show dev tun1
ip tuntap show

Die eerste opdrag druk die skakel soos die kernel dit sien, insluitend vlae en koppelvlaktipes, en so bevestig jy dat dit die toestel is wat jy bedoel het. Die tweede lys persistente tun/tap-inskrywings, wat bestaan sonder dat enige proses hulle vashou. 'n Koppelvlak wat op sy bedoelde eienaar wag, is 'n ander situasie as 'n lewende tonnel wat aan 'n ander VPN gekoppel is, en net die tweede verduidelik waarom jou eie aankoppeling misluk. Vind die proses wat die toestel vashou voordat jy enigiets verander, want 'n persistente inskrywing en 'n besige koppelvlak het verskillende oplossings.

Multiqueue-ondersteuning is 'n spesifieke drywer-reëling met sy eie vereistes, nie toestemming vir onverwante prosesse om een koppelvlak te deel nie. 'n Ander eienaar se lewende sessie is 'n koördinasieprobleem, en geen profielwysiging los dit op nie.

Twee verskillende soorte persistentheid

Kernel-persistentheid en persist-tun beskryf leeftye wat maklik verwar word en duur is om te verwar. 'n Persistente toestel bestaan onafhanklik van enige proses, so dit oorleef 'n stop en kan deur die volgende begin hergebruik word. persist-tun behou hulpbronne oor ondersteunde sagte herstellings binne een OpenVPN-proses, 'n veel korter horison. Nie een belowe dat die stop van die diens roetes en adresse in plek laat nie, en 'n koppelvlak wat sigbaar bly is nie bewys van 'n werkende versleutelde sessie nie.

Bevestig ook die agterkant, want 'n vooraf geskepte koppelvlak sê niks oor watter implementering dit sal oopmaak nie. Gemeenskapsboude wat die direkte datapad dra, sal dit probeer gebruik tensy die ontwerp anders sê. Waar 'n weergawe die skakelaar ondersteun, disable-dco kies eerder die gebruikersruimte-pad; ouer enjins en ander kliënte het nie so 'n direktief nie, so hou die weergawevoorwaarde by die opsie eerder as om te aanvaar dit geld.

Wat breek wanneer net die opstart getoets word

'n Eienaarskapsooreenkoms kan die eerste toets slaag en die laaste een faal, wat die opstart op sigself 'n swak kontrole maak. Let eerder op twee oorgange: 'n sagte herstelling, en 'n volle stop gevolg deur 'n begin.

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

Opstart is die maklike geval: die eenheid kom op, die skakel verskyn, en die statusuitvoer noem die profiel wat gelaai het. Aankoppeling is die oomblik wanneer die daemon die toestel oopmaak, so voer die skakelkontrole uit nadat die eenheid aktief rapporteer, nie voor dit nie. As die skakel bestaan terwyl die status nog aktiveer, kyk jy na 'n persistente toestel waaraan niemand nog gekoppel het nie, nie na 'n werkende tonnel nie. Stuur werklike verkeer deur die skakel voordat jy aanbeweeg, want 'n gekoppelde koppelvlak sonder 'n bruikbare roete is steeds 'n mislukking.

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

'n Sagte herstelling moet die sessie bruikbaar en die hulpbronne ongeskonde laat, wat die werk is wat persist-tun doen. 'n Volle stop is waar 'n eksterne bestuurder homself openbaar: as die skakel of sy adresse die stop oorleef, besit iemand anders hulle, en dit is óf die toestand wat jy gedokumenteer het óf die fout wat jy pas gevind het. Teken albei waarnemings langs die profiel aan, sodat die volgende verandering van bewyse eerder as van 'n diagram begin.