Rete di Immich: come rilevamento, DNS e routing garantiscono la raggiungibilità

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Immich Networking: How Discovery, DNS, and Routing Produce Reachability

I risultati di raggiungibilità di Immich derivano da una catena ordinata: selezione dell’endpoint, risoluzione DNS, instradamento dei pacchetti, inoltro tramite proxy o NAT e risposta dell’applicazione.

Un telefono può raggiungere Immich tramite IP locale mentre lo stesso hostname non funziona sulla rete Wi‑Fi, oppure funzionare da remoto seguendo un percorso più lungo quando si trova a casa. Questi risultati sono prodotti da decisioni diverse relative ai nomi e alle route, non da un unico stato universale di “rete attiva”.

La raggiungibilità inizia dall’endpoint scelto dal client

Un client non può instradare verso “Immich” come servizio astratto; utilizza uno schema, un hostname o un indirizzo, una porta e talvolta un percorso. Le applicazioni native, i browser, i segnalibri e i link condivisi possono memorizzare endpoint diversi. La loro raggiungibilità può divergere prima ancora che un pacchetto raggiunga il server.

Una discussione della community sull’esposizione di Immich localmente e da remoto descrive le difficoltà che si verificano quando un router non è in grado di fornire un comportamento split-horizon e il client non supporta il cambio automatico dell’endpoint locale. Il caso mostra che la selezione dell’endpoint e le capacità DNS locali determinano congiuntamente quale percorso un client domestico tenterà di seguire.

Annota l’URL esatto utilizzato da ciascun client e indica se è stato digitato, aperto da un link o salvato in precedenza. Confronta schema, host, porta e percorso. Non ridurre a un unico risultato un IP locale funzionante e un hostname pubblico non funzionante: sono contratti di destinazione diversi.

Il DNS seleziona un indirizzo, non un servizio funzionante

Il DNS converte l’hostname selezionato in un indirizzo. I resolver pubblici e locali possono restituire intenzionalmente risposte diverse, mentre le cache obsolete possono conservare l’indirizzo precedente del router o del server. Una risposta corretta identifica soltanto una destinazione; non dimostra che la porta, il proxy, il certificato o l’applicazione siano disponibili in quel punto.

Un caso della community di Caddy descrive Immich funzionante tramite IP locale, mentre un percorso locale basato su DuckDNS non funziona e solleva dubbi sul NAT hairpin. I dettagli dipendono dall’ambiente, ma dimostrano che la risoluzione dei nomi e i percorsi di ritorno del router possono differire anche sulla stessa rete domestica.

Interroga l’hostname dalla rete del telefono o del browser interessato, quindi confrontalo con l’indirizzo locale o pubblico previsto. Ripeti l’operazione usando la rete dati mobile. Se le risposte differiscono intenzionalmente, documenta il DNS split. Se differiscono in modo imprevisto, correggi il record autorevole o la cache prima di modificare i container di Immich.

Routing, NAT e proxy completano la catena di consegna

Dopo il DNS, il client ha bisogno di una route. Il traffico remoto può attraversare un ISP, un router, un port forwarding, un tunnel o un reverse proxy; il traffico locale può passare direttamente oppure attraversare il perimetro pubblico. Ogni livello deve inoltrare alla porta corretta e preservare il contesto della richiesta previsto dall’applicazione.

L’articolo di ZimaSpace sul percorso dei dati di Immich separa le dipendenze di client, rete, applicazione, database e contenuti multimediali. Questo modello a livelli evita un errore comune: riavviare Immich quando l’applicazione risponde già localmente e la prima dipendenza non funzionante si trova al di fuori del container.

Segui il percorso in ordine: indirizzo, route, porta in ascolto, destinazione del proxy, nome TLS e risposta dell’applicazione. Un ping riuscito non è sufficiente, perché la porta web o API potrebbe essere ancora bloccata. Allo stesso modo, la pagina iniziale di un proxy non dimostra che le richieste raggiungano il servizio Immich.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Usa una traccia di raggiungibilità a livelli

Crea due colonne per il Wi‑Fi domestico e la rete dati mobile. In ciascuna, registra l’URL selezionato, la risposta DNS, la route o il gateway, la connessione TCP, il risultato TLS, lo stato HTTP e una risposta autenticata dell’API di Immich. Usa lo stesso account e lo stesso contenuto, così l’identità o le autorizzazioni non alterano il confronto di rete.

Una guida a Immich per home server mostra il routing DNS come prerequisito prima dei passaggi relativi al certificato e all’accesso all’applicazione. La sequenza sostiene la regola diagnostica: i livelli successivi non possono compensare una mappatura nome-indirizzo errata, mentre il DNS corretto da solo non può convalidare l’inoltro o lo stato dell’applicazione.

Fermati al primo livello in cui il valore osservato differisce dal percorso previsto. Correggi solo quel livello e ripeti entrambe le colonne, perché una correzione remota può compromettere il comportamento hairpin locale. La raggiungibilità è confermata quando entrambi i percorsi previsti completano la stessa richiesta dell’applicazione, non semplicemente quando un hostname viene risolto.