Um cliente VPN pode aceder ao painel do NAS, mas não às sub-redes do Docker, porque a acessibilidade do anfitrião não cria automaticamente rotas de encaminhamento para as redes dos contentores.
Num servidor doméstico ZimaSpace, a página de gestão do NAS pode estar a escutar no endereço do anfitrião, enquanto as aplicações auto-hospedadas estão atrás de bridges do Docker, como 172.18.0.0/16. A VPN pode terminar com sucesso no anfitrião, mas continuar sem uma rota anunciada, uma regra de encaminhamento, uma rota de retorno ou um plano de endereçamento sem sobreposições para essas redes bridge.
Confirme que a VPN só conhece a rota do anfitrião
Compare a tabela de rotas do cliente VPN relativamente ao endereço do anfitrião NAS e à sub-rede Docker efetiva.
Um artigo focado sobre encaminhamento de sub-redes por VPN em os routers de sub-rede expandem o acesso para além de um único anfitrião ajuda a isolar esta hipótese, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Se apenas o anfitrião ou a sub-rede LAN for anunciada, não espere que uma bridge privada do Docker se torne acessível automaticamente.
Verifique se existe sobreposição entre as sub-redes do Docker e da VPN
Compare o conjunto de endereços do cliente VPN, as LAN domésticas e todos os intervalos das bridges Docker.
Um estudo de caso prático e focado sobre encaminhamento em uma sub-rede Docker pode sobrepor-se à VPN ajuda a isolar esta hipótese, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Altere os conjuntos de endereços do Docker para longe dos intervalos domésticos e da VPN e recrie apenas a rede afetada.
Procure uma rota Docker inesperada no anfitrião
Verifique que interface o Linux escolhe para o cliente VPN e para os destinos da sub-rede dos contentores.
Um artigo focado sobre redes em homelabs em o Docker pode instalar uma rota que se sobrepõe a outra sub-rede ajuda a isolar esta hipótese, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Uma rota que encaminhe as respostas da VPN para a bridge errada cria tráfego assimétrico, mesmo que o painel continue a funcionar.
Trate o planeamento de endereços do Docker e da VPN como um único sistema
Não atribua intervalos Docker independentemente dos intervalos da VPN, VLAN e LAN.
Um guia explicativo focado sobre redes Docker em os conflitos de endereços entre Docker e VPN são um problema de encaminhamento ajuda a isolar esta hipótese, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Reserve um intervalo privado documentado para as bridges dos contentores e mantenha-o fora de qualquer conjunto de endereços da VPN para utilizadores remotos.
Verifique o encaminhamento IP e o NAT no anfitrião da VPN
Um anfitrião pode aceitar pacotes destinados a si próprio e, simultaneamente, recusar encaminhá-los para outra interface ou bridge.
Um guia focado de resolução de problemas de encaminhamento VPN em os clientes VPN precisam de encaminhamento e NAT quando encaminham tráfego para outros destinos ajuda a isolar esta hipótese, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Capture pacotes nas interfaces da VPN e da bridge Docker. Se o tráfego chegar a uma e nunca sair pela outra, corrija a política de encaminhamento ou da firewall.
Verifique o encaminhamento WireGuard específico dos contentores
Algumas pilhas de servidores domésticos encaminham contentores selecionados através de um namespace WireGuard, alterando a respetiva rota de retorno para clientes remotos.
Um artigo focado sobre encaminhamento de contentores em homelabs em o encaminhamento de contentores pode utilizar uma rota WireGuard separada ajuda a isolar esta hipótese, porque aborda o mesmo problema específico em vez de apenas definir o protocolo subjacente.
Teste separadamente um contentor numa bridge normal e um contentor encaminhado pela VPN, para que o encaminhamento baseado em políticas não seja confundido com uma falha geral do Docker.
Volte a testar o percurso exato para o servidor doméstico
Depois de alterar uma variável, repita o mesmo fluxo de trabalho do NAS ou do serviço auto-hospedado a partir do mesmo cliente, em vez de mudar para um teste diferente que possa utilizar outro percurso.
O guia relacionado da ZimaSpace em o percurso de rede adjacente do servidor doméstico ajuda a manter a verificação final associada ao mesmo ambiente auto-hospedado.
A correção só está concluída quando o sintoma original continua resolvido após voltar a ligar, reiniciar o serviço e realizar uma segunda transferência ou pedido controlado.
Perguntas frequentes
Porque consigo aceder ao painel do NAS, mas não a uma sub-rede de contentores?
O painel termina no anfitrião. As bridges Docker requerem encaminhamento, reencaminhamento e tratamento da rota de retorno separados.
Devo anunciar as sub-redes das bridges Docker através da minha VPN?
Apenas quando os clientes remotos precisarem realmente de acesso direto às bridges. As portas publicadas através de um proxy são frequentemente mais simples e seguras.
A sobreposição dos intervalos do Docker e da VPN pode afetar apenas algumas aplicações?
Sim. A seleção de rotas do Linux pode enviar as respostas de um intervalo para a bridge errada, enquanto outros serviços do anfitrião continuam acessíveis.
Suporte e Dicas
Mais para Ler

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

