Meshnet, Docker e a permissão no meio
Um par da malha que alcança um contêiner publicado atravessa uma permissão do host e uma tradução do Docker. Revise as duas separadamente ou aprovará o escopo errado.
Dois URLs podem parecer idênticos no navegador de um par e significar coisas muito diferentes para o firewall. Um aponta para um serviço que escuta no próprio host. O outro aponta para um endereço de host cuja porta é publicada numa rede de contêineres, onde uma etapa de tradução entrega a conexão a outro IP. Numa malha ponto a ponto que controla o acesso à rede local com uma permissão por par, essa diferença é toda a revisão.
A permissão diz respeito ao endpoint do host, a tradução diz respeito ao Docker e o login diz respeito à aplicação. Três decisões, três lugares para olhar.
Siga o destino depois da publicação
Pegue um host Linux com Docker que publica a porta 80 de um contêiner na porta 8080 do host. Um par conecta-se ao endereço de malha do host na 8080, o host aceita a conexão e uma tradução de destino reescreve-a para o endereço de ponte do contêiner, normalmente algo como 172.17.0.2 na porta 80.
Quando uma regra inspeciona esse fluxo, o destino interessante é o contêiner, não o host. Uma política que raciocina apenas sobre «um serviço nesta máquina» raciocina sobre o objeto errado. O pedido aterrou no host, mas está a ser entregue noutro lugar.
É por isso que a documentação da malha inclui os contêineres Docker entre os recursos que a permissão de rede local governa no Linux. A permissão não é sinónimo de uma entrada comum numa lista de permitidos de VPN, e os dois controlos não se substituem. Um decide se um par pode chegar aos recursos locais; o outro decide que destinos transporta uma rota tunelizada.
Decida quanto acesso local concede uma permissão
Conceder acesso à rede local a um par não é uma decisão sobre um único contêiner. Pode expor outros serviços publicados no mesmo host e pode ir mais longe conforme a forma como o host encaminha. Reveja o âmbito efetivo antes de clicar no interruptor para um painel.
Depois veja onde o Docker publica a porta. Uma publicação em 0.0.0.0 cria um ouvinte em cada endereço do host, o que pode acrescentar uma entrada comum de LAN ao lado da entrada da malha. Se o requisito for apenas a malha, ligue a publicação ao endereço ou à interface concreta que pretende, e trate a ligação mais ampla como uma constatação separada e não como uma comodidade.
Mantenha a política de encaminhamento do host e a autenticação da própria aplicação suficientemente estreitas para o serviço. Um URL com aparência privada não é um controlo de acesso, e um contêiner que confia em todas as origens na sua rede de ponte não fica protegido pelo facto de o par da malha ter sido aprovado. A autenticação da aplicação é a terceira decisão, e é a única que sabe quem é o utilizador. Uma permissão ao nível do host não pode fornecer esse conhecimento.
Teste a permissão, não apenas o URL
A partir do par aprovado, abra o serviço exato e confirme que funciona. Depois experimente um destino que deve continuar negado e confirme que não funciona. Testar apenas o caminho feliz diz-lhe que a permissão foi concedida; não lhe diz que a fronteira está onde pensa.
Compare separadamente um serviço nativo do host. Se uma base de dados escuta no host e um painel corre num contêiner, seguem caminhos diferentes pela mesma permissão e podem não ser governados da mesma forma pela política de encaminhamento do host. Registe o que é o quê antes de escrever a nota de revisão.
Não esvazie as tabelas do Docker nem as regras do cliente da malha para «reiniciar» o acesso. Ambos os produtos instalam a sua própria integração de políticas, e apagá-la produz um host que parece funcionar enquanto contorna os controlos que lhe pediram para avaliar. Se uma regra parecer errada, leia-a e altere apenas essa regra. Se não conseguir explicar o que uma regra faz, essa é a constatação, não um motivo para a apagar.
Escreva a constatação nos termos do próprio sistema
O que importa é a distinção que o produto aplica de facto, não a do modelo de revisão: permissão para alcançar um endpoint do host, permissão para alcançar recursos privados encaminhados e permissão para usar a aplicação. Publicar uma porta deixa essas três decisões exatamente onde estavam, e um revisor que as trata como uma só aprovará o escopo errado.
Indique o endereço do host, a porta publicada, o destino do contêiner e a permissão do par na mesma frase. Essa frase é verificável por outra pessoa, e é isso que a torna uma constatação e não uma opinião.