Meshnet, Docker y el permiso de por medio

Dos URL pueden parecer idénticas desde el navegador de un par y significar cosas muy distintas para el cortafuegos. Una apunta a un servicio que escucha en el propio host. La otra apunta a una dirección de host cuyo puerto se publica en una red de contenedores, donde un paso de traducción entrega la conexión a otra IP. En una malla entre pares que controla el acceso a la red local con un permiso por par, esa diferencia es toda la revisión.

El permiso trata del extremo del host, la traducción trata de Docker y el inicio de sesión trata de la aplicación. Tres decisiones, tres lugares donde mirar.

Siga el destino después de la publicación

Tome un host Linux con Docker que publica el puerto 80 de un contenedor en el puerto 8080 del host. Un par se conecta a la dirección de malla del host en el 8080, el host acepta la conexión y una traducción de destino la reescribe hacia la dirección de puente del contenedor, normalmente algo como 172.17.0.2 en el puerto 80.

Cuando una regla inspecciona ese flujo, el destino interesante es el contenedor, no el host. Una política que razona solo sobre «un servicio en esta máquina» razona sobre el objeto equivocado. La petición aterrizó en el host, pero se entrega en otro lugar.

Por eso la documentación de la malla incluye los contenedores de Docker entre los recursos que el permiso de red local gobierna en Linux. El permiso no es sinónimo de una entrada corriente de la lista de permitidos de una VPN, y los dos controles no se sustituyen. Uno decide si un par puede llegar a los recursos locales; el otro decide qué destinos transporta una ruta tunelizada.

Decida cuánto acceso local concede un permiso

Conceder acceso a la red local a un par no es una decisión sobre un solo contenedor. Puede exponer otros servicios publicados en el mismo host y puede llegar más lejos según cómo reenvíe el host. Revise el alcance efectivo antes de pulsar el interruptor para un panel.

Luego mire dónde publica Docker el puerto. Una publicación en 0.0.0.0 crea un escucha en cada dirección del host, lo que puede añadir una entrada corriente de LAN junto a la de la malla. Si el requisito es solo la malla, vincule la publicación a la dirección o la interfaz concreta que pretende, y trate la vinculación más amplia como un hallazgo aparte y no como una comodidad.

Mantenga la política de reenvío del host y la autenticación propia de la aplicación lo bastante estrechas para el servicio. Una URL que parece privada no es un control de acceso, y un contenedor que confía en cada origen de su red de puente no queda protegido por el hecho de que el par de la malla haya sido aprobado. La autenticación de la aplicación es la tercera decisión, y es la única que sabe quién es el usuario. Un permiso a nivel de host no puede aportar ese conocimiento.

Pruebe el permiso, no solo la URL

Desde el par aprobado, abra el servicio exacto y confirme que funciona. Luego pruebe un destino que debería seguir denegado y confirme que no funciona. Probar solo el camino feliz le dice que el permiso se concedió; no le dice que la frontera esté donde usted cree.

Compare aparte un servicio nativo del host. Si una base de datos escucha en el host y un panel se ejecuta en un contenedor, siguen caminos distintos por el mismo permiso y puede que la política de reenvío del host no los gobierne igual. Anote qué es cada cosa antes de escribir la nota de revisión.

No vacíe las tablas de Docker ni las reglas del cliente de la malla para «reiniciar» el acceso. Ambos productos instalan su propia integración de políticas, y borrarla produce un host que parece funcionar mientras omite los controles que le pidieron evaluar. Si una regla parece incorrecta, léala y cambie solo esa regla. Si no puede explicar qué hace una regla, ese es el hallazgo, no un motivo para borrarla.

Escriba el hallazgo en los términos del propio sistema

Lo que importa es la distinción que el producto aplica de verdad, no la de la plantilla de revisión: permiso para llegar a un extremo del host, permiso para llegar a recursos privados enrutados y permiso para usar la aplicación. Publicar un puerto deja esas tres decisiones exactamente donde estaban, y un revisor que las trata como una sola aprobará el alcance equivocado.

Indique la dirección del host, el puerto publicado, el destino del contenedor y el permiso del par en la misma frase. Esa frase es verificable por otra persona, y eso es lo que la convierte en un hallazgo y no en una opinión.