tun precreada en OpenVPN: comparar os dous modelos de propiedade

Alguén precreou tun1, o perfil di dev tun1, e a conexión segue sen adherirse. A existencia do nome no host non di case nada, porque a adhesión depende do espazo de nomes, do tipo de dispositivo, de quen posúe a ligazón e do que se lle permite facer ao daemon. Reutilizar un dispositivo tamén obriga a unha decisión que a configuración predeterminada agocha: que compoñente escribe os enderezos e as rutas. Os modos de fallo dos dous arranxos difiren moito máis que as liñas de configuración, así que decida antes de editar un perfil.

Un nome non é unha adhesión

dev tun1 pide a OpenVPN esa interface nomeada, e as compilacións tradicionais en espazo de usuario tentarán abrila. Se o nome non segue o patrón habitual tun ou tap, o perfil tamén necesita un dev-type correspondente, porque o tipo nunca se deduce dunha cadea. Un dispositivo TAP non é un dispositivo TUN cunha etiqueta distinta: adherir o incorrecto ou falla de inmediato ou produce unha ligazón que transporta tramas que ninguén espera. Comprobe o tipo antes que calquera outra cousa, xa que cada comprobación posterior supón que os dous lados están de acordo niso. A partir de aí, confirme que o proceso pode realmente abrir o dispositivo, e non só velo.

dev tun1
dev-type tun

A interface de rede e /dev/net/tun son obxectos distintos: unha é unha ligazón dentro dun espazo de nomes, o outro é o dispositivo de caracteres que un programa en espazo de usuario usa para adherirse. A documentación de Linux TUN/TAP describe esa ruta de adhesión e as regras de propiedade dos dispositivos persistentes. Unha consola root que pode executar ip link só demostra que a consola ten privilexios, non que os teña o daemon. A propiedade do nodo do dispositivo, o conxunto de capacidades do servizo e o usuario baixo o que se executa deben aliñarse todos antes de que a apertura teña éxito.

Un dispositivo que existe e non se pode abrir é un problema de propiedade, non de encamiñamento. Tráteo como tal durante a depuración, ou a tarde pasa a ler táboas de rutas que nunca foron o problema.

Quen configura a ligazón: dous modelos de propiedade

No primeiro modelo OpenVPN configura enderezos e rutas como parte de levantar a conexión. Ese é o comportamento predeterminado e o máis doado de razoar, porque un único compoñente crea o estado e volve eliminalo. No segundo modelo un xestor externo posúe a interface, e ifconfig-noexec impide que OpenVPN execute as súas ordes de configuración de enderezos e entrega os parámetros a scripts. O xestor debe entón aplicar el mesmo a configuración local e a do par correctas, o que é máis traballo do que suxire o nome da opción. Escoller entre os dous é unha cuestión de quen pode cambiar a ligazón mentres está levantada.

ifconfig-noexec cobre só os enderezos: a táboa de rutas queda intacta, e a configuración de rutas pertence a route-noexec. Trate as dúas directivas como controis separados con propietarios separados, porque definir unha e supor a outra é unha fonte habitual de ligazóns a medio configurar. Escolla exactamente un propietario por capa, os enderezos nun sitio e as rutas noutro. Un xestor de rede e un axudante VPN que escriben ambos enderezos é como unha desconexión borra estado do que o outro lado aínda depende.

Inspeccione o dispositivo desde o espazo de nomes que importa

Inspeccione o dispositivo desde o espazo de nomes no que se executa o proceso VPN, non desde o que a súa consola ocupa por casualidade. Os dous comandos de abaixo responden a preguntas distintas, e a diferenza aparece cando un host ve unha interface que un contedor non ve. Execúteos na orde indicada, porque o segundo só ten sentido unha vez que saiba se a ligazón existe.

ip -details link show dev tun1
ip tuntap show

O primeiro comando imprime a ligazón tal como a ve o núcleo, incluídos os sinalizadores e o tipo de interface, e así confirma que é o dispositivo que quería. O segundo lista as entradas tun/tap persistentes, que existen sen que ningún proceso as manteña. Unha interface que agarda polo seu propietario previsto é unha situación distinta dun túnel activo adherido a outra VPN, e só o segundo explica por que falla a súa propia adhesión. Atope o proceso que mantén o dispositivo antes de cambiar nada, porque unha entrada persistente e unha interface ocupada teñen correccións distintas.

A compatibilidade con varias colas é unha disposición concreta do controlador cos seus propios requisitos, non un permiso para que procesos sen relación compartan unha interface. A sesión activa doutro propietario é un problema de coordinación, e ningunha edición de perfil o resolve.

Dous tipos de persistencia

A persistencia do núcleo e persist-tun describen tempos de vida fáciles de confundir e caros de mesturar. Un dispositivo persistente existe independentemente de calquera proceso, polo que sobrevive a unha parada e pode reutilizalo o seguinte arranque. persist-tun conserva os recursos a través dos reinicios suaves admitidos dentro dun único proceso OpenVPN, un horizonte moito máis curto. Nin un nin outro prometen que parar o servizo deixe as rutas e os enderezos no seu sitio, e unha interface que segue visible non é proba dunha sesión cifrada que funcione.

Confirme tamén o backend, porque unha interface precreada non di nada sobre que implementación a abrirá. As compilacións da comunidade que levan a ruta de datos directa tentarán usala, salvo que o deseño diga o contrario. Onde a versión admite o conmutador, disable-dco selecciona no seu lugar a ruta en espazo de usuario; os motores máis antigos e outros clientes non teñen esa directiva, así que manteña a condición de versión xunto á opción en vez de supor que se aplica.

Que rompe cando só se proba o arranque

Un acordo de propiedade pode pasar a primeira proba e fallar na última, o que fai do arranque unha comprobación pobre por si só. Observe no seu lugar dúas transicións: un reinicio suave, e unha parada completa seguida dun arranque.

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

O arranque é o caso fácil: a unidade levanta, a ligazón aparece e a saída de estado nomea o perfil que se cargou. A adhesión é o momento en que o daemon abre o dispositivo, así que execute a comprobación da ligazón despois de que a unidade informe que está activa, non antes. Se a ligazón existe mentres o estado aínda se está activando, está a ver un dispositivo persistente ao que aínda ninguén se adheriu, non un túnel que funcione. Faga pasar tráfico real pola ligazón antes de continuar, porque unha interface adherida sen ruta utilizable segue sendo un fallo.

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

Un reinicio suave debería deixar a sesión utilizable e os recursos intactos, e ese é o traballo que fai persist-tun. A parada completa é onde un xestor externo se revela: se a ligazón ou os seus enderezos sobreviven á parada, alguén máis os posúe, e iso é ou o estado que documentou ou o erro que acaba de atopar. Anote as dúas observacións xunto ao perfil, para que o seguinte cambio parta de evidencias e non dun diagrama.