Meshnet, Docker e o permiso polo medio

Dous URL poden parecer idénticos desde o navegador dun par e significar cousas moi distintas para a devasa. Un apunta a un servizo que escoita no propio host. O outro apunta a un enderezo de host cuxo porto se publica nunha rede de contedores, onde un paso de tradución entrega a conexión a outra IP. Nunha malla entre pares que controla o acceso á rede local cun permiso por par, esa diferenza é toda a revisión.

O permiso trata do extremo do host, a tradución trata de Docker e o inicio de sesión trata da aplicación. Tres decisións, tres lugares onde mirar.

Siga o destino despois da publicación

Colla un host Linux con Docker que publica o porto 80 dun contedor no porto 8080 do host. Un par conéctase ao enderezo de malla do host no 8080, o host acepta a conexión e unha tradución de destino reescríbea cara ao enderezo de ponte do contedor, normalmente algo como 172.17.0.2 no porto 80.

Cando unha regra inspecciona ese fluxo, o destino interesante é o contedor, non o host. Unha política que razoa só sobre «un servizo nesta máquina» razoa sobre o obxecto equivocado. A petición aterrou no host, pero entrégase noutro lugar.

Por iso a documentación da malla inclúe os contedores de Docker entre os recursos que o permiso de rede local goberna en Linux. O permiso non é sinónimo dunha entrada corrente da lista de permitidos dunha VPN, e os dous controis non se substitúen. Un decide se un par pode chegar aos recursos locais; o outro decide que destinos transporta unha ruta tunelizada.

Decida canto acceso local concede un permiso

Conceder acceso á rede local a un par non é unha decisión sobre un só contedor. Pode expor outros servizos publicados no mesmo host e pode chegar máis lonxe segundo como reenvíe o host. Revise o alcance efectivo antes de premer o interruptor para un panel.

Despois mire onde publica Docker o porto. Unha publicación en 0.0.0.0 crea un oínte en cada enderezo do host, o que pode engadir unha entrada corrente de LAN xunto á da malla. Se o requisito é só a malla, vincule a publicación ao enderezo ou á interface concreta que pretende, e trate a vinculación máis ampla como un achado aparte e non como unha comodidade.

Manteña a política de reenvío do host e a autenticación propia da aplicación o suficientemente estreitas para o servizo. Un URL que parece privado non é un control de acceso, e un contedor que confía en cada orixe da súa rede de ponte non queda protexido polo feito de que o par da malla fose aprobado. A autenticación da aplicación é a terceira decisión, e é a única que sabe quen é o usuario. Un permiso a nivel de host non pode achegar ese coñecemento.

Probe o permiso, non só o URL

Desde o par aprobado, abra o servizo exacto e confirme que funciona. Despois probe un destino que debería seguir denegado e confirme que non funciona. Probar só o camiño feliz dialle que o permiso se concedeu; non lle di que a fronteira estea onde vostede cre.

Compare á parte un servizo nativo do host. Se unha base de datos escoita no host e un panel se executa nun contedor, seguen camiños distintos polo mesmo permiso e pode que a política de reenvío do host non os goberne igual. Anote que é cada cousa antes de escribir a nota de revisión.

Non baleire as táboas de Docker nin as regras do cliente da malla para «reiniciar» o acceso. Ambos os produtos instalan a súa propia integración de políticas, e borrala produce un host que parece funcionar mentres omite os controis que lle pediron avaliar. Se unha regra parece incorrecta, léaa e cambie só esa regra. Se non pode explicar que fai unha regra, ese é o achado, non un motivo para borrala.

Escriba o achado nos termos do propio sistema

O que importa é a distinción que o produto aplica de verdade, non a do modelo de revisión: permiso para chegar a un extremo do host, permiso para chegar a recursos privados encamiñados e permiso para usar a aplicación. Publicar un porto deixa esas tres decisións exactamente onde estaban, e un revisor que as trata como unha soa aprobará o alcance equivocado.

Indique o enderezo do host, o porto publicado, o destino do contedor e o permiso do par na mesma frase. Esa frase é verificable por outra persoa, e iso é o que a converte nun achado e non nunha opinión.