Perché un client VPN può aprire il pannello di controllo del NAS, ma non raggiungere le sue sottoreti bridge Docker?
Un client VPN può raggiungere il dashboard del NAS ma non le subnet Docker, perché la raggiungibilità dell'host non crea automaticamente percorsi di inoltro verso le reti dei container.
In un home server ZimaSpace, la pagina di gestione del NAS può essere in ascolto sull'indirizzo dell'host, mentre le app self-hosted si trovano dietro bridge Docker come 172.18.0.0/16. La VPN può terminare correttamente sull'host, ma non disporre di un percorso annunciato, di una regola di inoltro, di un percorso di ritorno o di un piano di indirizzamento non sovrapposto per tali reti bridge.
Conferma che la VPN conosca solo il percorso dell'host
Confronta la tabella dei percorsi del client VPN per l'indirizzo dell'host NAS e per la subnet Docker effettiva.
Un articolo mirato sul routing delle subnet VPN, i router di subnet estendono l'accesso oltre un singolo host, aiuta a isolare questo caso perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Se viene annunciata solo la subnet dell'host o della LAN, non aspettarti che un bridge Docker privato diventi raggiungibile automaticamente.
Verifica la sovrapposizione tra subnet Docker e VPN
Confronta il pool di indirizzi del client VPN, le LAN domestiche e ogni intervallo dei bridge Docker.
Un caso di studio mirato e reale sul routing, una subnet Docker può sovrapporsi alla VPN, aiuta a isolare questo caso perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Sposta i pool di indirizzi Docker fuori dagli intervalli della rete domestica e della VPN, quindi ricrea solo la rete interessata.
Cerca un percorso Docker imprevisto sull'host
Controlla quale interfaccia Linux sceglie per il client VPN e per le destinazioni della subnet dei container.
Un articolo mirato sul networking degli homelab, Docker può installare un percorso che nasconde un'altra subnet, aiuta a isolare questo caso perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Un percorso che indirizza le risposte VPN verso il bridge sbagliato crea traffico asimmetrico anche se il dashboard continua a funzionare.
Considera il piano di indirizzamento Docker-VPN come un unico sistema
Non allocare gli intervalli Docker separatamente da quelli di VPN, VLAN e LAN.
Un approfondimento mirato sul networking Docker, i conflitti di indirizzi Docker e VPN sono un problema di routing, aiuta a isolare questo caso perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Riserva un intervallo privato documentato per i bridge dei container e mantienilo fuori da qualsiasi pool VPN per utenti remoti.
Verifica l'inoltro IP e il NAT sull'host VPN
Un host può accettare pacchetti destinati a se stesso rifiutandosi però di inoltrarli verso un'altra interfaccia o un altro bridge.
Una guida mirata alla risoluzione dei problemi di routing VPN, i client VPN hanno bisogno di inoltro e NAT quando instradano il traffico oltre l'host, aiuta a isolare questo caso perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Cattura i pacchetti sulle interfacce VPN e del bridge Docker. Se il traffico arriva su una ma non esce mai dall'altra, correggi l'inoltro o la policy del firewall.
Controlla il routing WireGuard specifico dei container
Alcuni stack per home server instradano container selezionati attraverso uno spazio dei nomi WireGuard, modificando il loro percorso di ritorno verso i client remoti.
Un articolo mirato sul routing dei container negli homelab, il routing dei container può usare un percorso WireGuard separato, aiuta a isolare questo caso perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Testa separatamente un container su un bridge ordinario e uno instradato tramite VPN, così da non confondere il policy routing con un problema generale di Docker.
Ripeti il test sul percorso esatto dell'home server
Dopo aver modificato una variabile, ripeti lo stesso flusso NAS o self-hosted dallo stesso client invece di passare a un test diverso che potrebbe utilizzare un altro percorso.
La guida ZimaSpace correlata su il percorso di rete adiacente dell'home server aiuta a mantenere la verifica finale legata allo stesso ambiente self-hosted.
La correzione è completa solo quando il sintomo originale rimane risolto dopo la riconnessione, il riavvio del servizio e un secondo trasferimento o una seconda richiesta controllata.
Domande frequenti
Perché posso raggiungere il dashboard del NAS ma non la subnet di un container?
Il dashboard termina sull'host. I bridge Docker richiedono una gestione separata del routing, dell'inoltro e del percorso di ritorno.
Devo annunciare le subnet dei bridge Docker sulla VPN?
Solo quando i client remoti hanno realmente bisogno di accedere direttamente ai bridge. Le porte pubblicate tramite proxy sono spesso più semplici e sicure.
La sovrapposizione degli intervalli Docker e VPN può interrompere solo alcune app?
Sì. La selezione dei percorsi di Linux può inviare le risposte relative a un intervallo verso il bridge sbagliato, mentre gli altri servizi dell'host restano raggiungibili.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
