Unha aplicación Linux corrente usa a VPN sen tocar TUN

Un navegador que usa unha VPN Linux xa establecida non abre /dev/net/tun. Abre un socket, e o núcleo decide por que interface saen os paquetes dese socket. O proceso que creou o túnel fai un traballo distinto do proceso cuxo tráfico transporta. Manter eses dous roles separados responde a maioría das preguntas sobre permisos antes de que se formulen.

Segue un paquete desde o socket ata o túnel

Unha aplicación corrente chama a connect ou send, e o núcleo busca unha ruta para o destino. Se a ruta escollida apunta á interface do túnel, o paquete ponse na cola do dispositivo que le o daemon da VPN. O daemon cifrao e envíao pola interface física. Cada frecha desa descrición é un lugar onde se pode responder a unha pregunta sobre permisos.

Nada nesa ruta esixe que a aplicación coñeza o dispositivo. O daemon mantén o descritor de ficheiro e realiza as operacións de interface, mentres a aplicación só ve unha API de rede normal.

Debuxa as dúas metades unha vez, e as preguntas sobre permisos serán máis fáciles de situar. A metade superior é o mundo das aplicacións, e a inferior pertence ao daemon.

Decide quen necesita o dispositivo e quen non

Crear ou conectar a unha interface TUN require acceso ao dispositivo e ademais a capacidade de configurala, por iso un servizo VPN compatible comeza con autoridade de administración de rede ou usa un axudante privilexiado. Ese requisito pertence ao daemon. Non di nada sobre o navegador, o cliente de base de datos ou a ferramenta de transferencia de ficheiros. Un servizo que necesita a capacidade necesitaa para o seu propio paso de configuración, non para os seus clientes.

Unha vez que a ruta e a política están no seu sitio, un proceso corrente usa a ruta resultante mediante as súas chamadas de socket habituais. Non necesita o nodo do dispositivo, e non necesita root.

Cambiar os permisos do dispositivo non é unha forma de conceder a unha aplicación acceso ao destino. Só move a fronteira do dispositivo a outro lugar.

Comproba o espazo de nomes no que se executa realmente a aplicación

Un contedor, ou un segundo espazo de nomes de rede, dá aos seus procesos un conxunto de interfaces e unha táboa de rutas separados. Un túnel no host non aparece alí automaticamente, e ningunha cantidade de cambios de permisos do dispositivo cambia iso. A aplicación simplemente encamiñará a través do que proporcione ese espazo de nomes. Por iso unha imaxe de contedor non pode herdar un túnel do host por accidente.

Compróbao con ip netns list e ip -n NAME route, ou inspeccionando a ligazón do espazo de nomes do proceso. A resposta adoita verse cun só comando.

Tamén se lles pode dar a dous usuarios do mesmo host rutas distintas mediante políticas. Iso é unha decisión de rede e non unha proba sobre a propiedade do dispositivo.

Separa as capacidades da política de rede

Algunhas ferramentas necesitan máis que un socket. Capturar paquetes necesita un socket en bruto, e cambiar rutas necesita autoridade de administración. Son operacións distintas con concesións distintas, e conceder unha non debe lerse como un requisito xeral para usar a VPN.

Un programa que implementa o seu propio túnel é un terceiro caso. Abre TUN de verdade porque asume o papel do daemon, por iso necesita os privilexios do daemon.

Nomea a operación antes de nomear o privilexio. Normalmente é máis fácil separar os dous do que parece.

Verifica a separación con dúas contas

Conecta o túnel como o servizo, despois executa a aplicación como un usuario corrente e confirma que chega ao recurso privado. Comproba ip route get para o destino desde a shell dese usuario para ver que interface se escolleu. Se a ruta é correcta e a conexión segue fallando, o problema é a política e non o privilexio.

O deseño resultante é o mínimo privilexio cunha fronteira explícita: un compoñente posúe a configuración e os recursos do túnel, as cargas de traballo manteñen as súas contas normais, e a política de rede decide que pode pasar. Executar todo como root colapsa eses roles sen explicar nada.