Accesso UNC nei container Windows: prima il nome, poi l'identità

Un container Windows che necessita di una condivisione dall'altra parte del tunnel fallisce in due modi indipendenti, e Explorer dell'host non ne dimostra nessuno. Il container ha il proprio endpoint di rete e la propria identità di processo. Un nome che si risolve sul desktop e una sessione che il file server accetta lì descrivono il desktop, non il carico di lavoro.

Explorer dell'host non è una prova

Aprire la condivisione sull'host usa il client DNS dell'host, la tabella di routing dell'host e l'account con cui l'host ha effettuato l'accesso. Un processo del container non eredita nulla di tutto ciò in modo implicito, anche quando il container gira sulla stessa macchina e il client VPN gira anch'esso lì. Il primo confine è il percorso di rete: il container riesce a risolvere il nome e riesce ad aprire una sessione TCP verso la porta SMB. Il secondo è l'identità: il file server accetta ciò che il container presenta, con i permessi di cui il carico di lavoro ha bisogno.

Trattarli come un solo problema produce il noto ciclo di allargare le regole del firewall per correggere ciò che in realtà è una risposta di accesso negato dalla condivisione.

Seguite la richiesta del container stesso

La rete dei container Windows è gestita dall'Host Networking Service, che crea endpoint con il proprio spazio dei nomi di rete. La modalità scelta decide se l'endpoint è tradotto, in bridge o collegato a una rete condivisa con l'host. Questa decisione cambia due cose insieme: ciò che il container può risolvere e quale indirizzo di origine vede il file server.

Confermate ciò che osserva il container stesso prima di cambiare qualcosa. Un nome che si risolve fuori può fallire dentro, perché la configurazione DNS del container non è quella dell'host, e un endpoint tradotto può presentare un'origine che le regole del file server non si aspettano.

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

Se la risoluzione fallisce, correggete il DNS nella configurazione di rete invece di sostituire un indirizzo. Sostituire il nome con un IP può cambiare il comportamento dell'autenticazione e dell'identità del server, il che trasforma un problema in due. La policy del client VPN stessa è la cosa successiva da controllare, perché può trattare diversamente i processi dell'host e il traffico originato dal container.

L'identità è una decisione separata

Una lettera di unità mappata da un utente interattivo non è un'interfaccia applicativa. Esiste in una sola sessione di accesso, e un processo del container non ne fa parte. Usate il percorso UNC e date al carico di lavoro un'identità che il modello di distribuzione supporta. Dove il dominio lo supporta, un account di servizio gestito di gruppo (gMSA) fornisce un'identità gestita tramite una specifica delle credenziali.

La guida gMSA per i container di Microsoft descrive questa disposizione della specifica delle credenziali e i suoi prerequisiti, tra cui l'appartenenza al dominio e un host in grado di recuperare la credenziale. L'account, il recupero, l'identità del processo dentro il container e i permessi della condivisione devono tutti allinearsi. Un accesso VPN non è quell'identità, e incorporare una password in un'immagine per riprodurre la sessione dell'utente host crea un'esposizione permanente.

Mantenete visibile la fase che fallisce

Un errore di risoluzione, un rifiuto di connessione e una negazione di accesso richiedono prove diverse. Sono rispettivamente una questione di DNS, una questione di routing o filtraggio e una questione di autenticazione o permessi. Leggete la risposta ricevuta dal container invece dell'errore generico dell'applicazione.

Provate con l'identità propria del carico di lavoro e provate anche una negazione.

Pianificate la riconnessione

I percorsi VPN cadono. Quando il tunnel torna, un endpoint può tornare con un altro indirizzo tradotto, e una sessione SMB esistente può essere morta senza che l'applicazione se ne accorga. Gestitelo nell'applicazione: ristabilite il percorso e l'identità, ripetete l'operazione e riconciliate un'operazione su file con un esito sconosciuto invece di presumere che non sia successo nulla.

Annotate la modalità di rete, la fonte DNS e la disposizione dell'identità nelle note di distribuzione. Sono esattamente questi tre fatti che riguarderanno il prossimo errore.