tun precreat d'OpenVPN: compareu els dos models de propietat

Algú va crear tun1 prèviament, el perfil diu dev tun1, i la connexió encara no s’adjunta. El nom que existeix a l’amfitrió gairebé no diu res, perquè l’adjunció depèn de l’espai de noms, del tipus de dispositiu, de qui posseeix l’enllaç i de què pot fer el dimoni. Reutilitzar un dispositiu també força una decisió que la configuració per defecte amaga: quin component escriu les adreces i les rutes. Els modes de fallada dels dos arranjaments difereixen molt més que les línies de configuració, així que decidiu abans d’editar un perfil.

Un nom no és una adjunció

dev tun1 demana OpenVPN per a aquesta interfície amb aquest nom, i les compilacions tradicionals d’espai d’usuari intentaran obrir-la. Si el nom no segueix el patró habitual de tun o tap, el perfil també necessita un dev-type coincident, perquè el tipus mai no s’infereix d’una cadena. Un dispositiu TAP no és un dispositiu TUN amb una etiqueta diferent: adjuntar el equivocat falla directament o produeix un enllaç que transporta trames que ningú espera. Comproveu el tipus abans que res, ja que tota comprovació posterior assumeix que les dues bandes hi estan d’acord. A partir d’aquí, confirmeu que el procés pot obrir realment el dispositiu, no només veure’l.

dev tun1
dev-type tun

La interfície de xarxa i /dev/net/tun són objectes diferents: un és un enllaç dins d’un espai de noms, l’altre és el dispositiu de caràcters que un programa d’espai d’usuari fa servir per adjuntar-s’hi. La documentació de TUN/TAP de Linux descriu aquest camí d’adjunció i les regles de propietat per als dispositius persistents. Un intèrpret d’ordres root que pugui executar ip link només demostra que l’intèrpret té privilegis, no que el dimoni els tingui. La propietat del node de dispositiu, el conjunt de capacitats del servei i l’usuari amb què s’executa han d’estar tots alineats abans que l’obertura tingui èxit.

Un dispositiu que existeix i que no es pot obrir és un problema de propietat, no un problema d’encaminament. Tracteu-lo com a tal mentre depureu, o la tarda se n’anirà llegint taules d’encaminament que mai no eren el problema.

Qui configura l’enllaç: dos models de propietat

En el primer model, OpenVPN configura adreces i rutes com a part de posar la connexió en marxa. Aquest és el comportament per defecte i el més fàcil de raonar, perquè un sol component crea l’estat i el torna a eliminar. En el segon model, un gestor extern posseeix la interfície, i ifconfig-noexec atura OpenVPN perquè no executi les seves ordres de configuració d’adreces i passa els paràmetres als scripts. Llavors el gestor ha d’aplicar ell mateix la configuració local i d’igual correcta, cosa que és més feina del que suggereix el nom de l’opció. Triar entre els dos és una qüestió de qui pot canviar l’enllaç mentre està actiu.

ifconfig-noexec cobreix només les adreces: la taula d’encaminament no es toca, i la configuració de rutes pertany a route-noexec. Tracteu les dues directives com a controls separats amb propietaris separats, perquè establir-ne una i suposar l’altra és una font habitual d’enllaços mig configurats. Trieu exactament un propietari per capa, les adreces en un lloc i les rutes en un altre. Un gestor de xarxa i un auxiliar de VPN que escriuen tots dos adreces és com una desconnexió esborra un estat del qual l’altra banda encara depèn.

Inspeccioneu el dispositiu des de l’espai de noms que importa

Inspeccioneu el dispositiu des de l’espai de noms en què s’executa el procés VPN, no des del que el vostre intèrpret d’ordres té per casualitat. Les dues ordres següents responen preguntes diferents, i la diferència apareix quan un amfitrió veu una interfície que un contenidor no pot veure. Executeu-les en l’ordre indicat, perquè la segona només té sentit un cop sabeu si l’enllaç existeix.

ip -details link show dev tun1
ip tuntap show

La primera ordre imprimeix l’enllaç tal com el veu el nucli, incloent-hi els indicadors i el tipus d’interfície, que és com confirmeu que aquest és el dispositiu que volíeu. La segona llista les entrades persistents de tun/tap, que existeixen sense que cap procés les mantingui. Una interfície que espera el seu propietari previst és una situació diferent d’un túnel actiu adjuntat a una altra VPN, i només la segona explica per què falla la vostra adjunció. Trobeu el procés que manté el dispositiu abans de canviar res, ja que una entrada persistent i una interfície ocupada tenen solucions diferents.

El suport de multiqueue és un arranjament específic de controlador amb els seus propis requisits, no un permís perquè processos no relacionats comparteixin una interfície. La sessió activa d’un altre propietari és un problema de coordinació, i cap edició de perfil el resol.

Dos tipus diferents de persistència

La persistència del nucli i persist-tun descriuen temps de vida que és fàcil confondre i car de confondre. Un dispositiu persistent existeix independentment de qualsevol procés, així que sobreviu a una aturada i es pot reutilitzar en la propera arrencada. persist-tun conserva recursos durant els reinicis suaus admesos dins d’un sol procés OpenVPN, un horitzó molt més curt. Cap de les dues promet que aturar el servei deixi les rutes i les adreces al seu lloc, i una interfície que continua visible no és prova d’una sessió xifrada que funcioni.

Confirmeu també el backend, perquè una interfície precreada no diu res sobre quina implementació l’obrirà. Les compilacions comunitàries que porten el camí de dades directe intentaran fer-la servir tret que el disseny digui el contrari. Quan una versió admet l’interruptor, disable-dco selecciona el camí d’espai d’usuari; els motors més antics i altres clients no tenen aquesta directiva, així que manteniu la condició de versió al costat de l’opció en lloc de suposar que s’aplica.

Què es trenca quan només es prova l’arrencada

Un acord de propietat pot superar la primera prova i fallar l’última, cosa que fa de l’arrencada una comprovació pobra per si sola. Observeu dues transicions: un reinici suau i una aturada completa seguida d’una arrencada.

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

L’arrencada és el cas fàcil: la unitat arrenca, l’enllaç apareix i la sortida d’estat nomena el perfil que s’ha carregat. L’adjunció és el moment en què el dimoni obre el dispositiu, així que executeu la comprovació de l’enllaç després que la unitat informi que està activa, no abans. Si l’enllaç existeix mentre l’estat encara s’activa, esteu veient un dispositiu persistent al qual ningú no s’ha adjuntat encara, no un túnel en funcionament. Feu passar trànsit real per l’enllaç abans de continuar, perquè una interfície adjuntada sense cap ruta utilitzable encara és un fracàs.

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

Un reinici suau hauria de deixar la sessió utilitzable i els recursos intactes, que és la feina que persist-tun fa. Una aturada completa és on un gestor extern es revela: si l’enllaç o les seves adreces sobreviuen a l’aturada, algú altre en és propietari, i això és o bé l’estat que vau documentar o bé l’error que acabeu de trobar. Anoteu les dues observacions al costat del perfil, perquè el proper canvi comenci a partir d’evidències i no d’un diagrama.