Dietro un Proxy Aziendale

Molte reti di fabbrica e aziendali raggiungono internet solo attraverso un proxy HTTP aziendale (ad esempio un proxy Squid sulla porta 3128). L’IronFlock Appliance si installa e funziona senza problemi in questa configurazione — fornisci il tuo proxy nel comando di installazione e l’installer configura tutto il resto per te.

Questa pagina presuppone che l’host dell’Appliance non abbia variabili d’ambiente proxy impostate — fornisci il proxy esplicitamente. Spiega ciò che l’installer gestisce automaticamente e l’unico passaggio aggiuntivo necessario per i proxy che intercettano il TLS.

Questo è il complemento sul proxy della sezione Configurazione del Firewall della guida all’Appliance. Gli stessi endpoint IronFlock devono essere raggiungibili — la differenza è che qui vengono raggiunti attraverso il tuo proxy.

Perché un Proxy Richiede Attenzione

Le immagini della piattaforma IronFlock vengono scaricate dal daemon Docker — un servizio in background con una propria configurazione di rete, separata dalla tua shell. Anche su un host che per il resto può raggiungere internet attraverso il proxy, il daemon non ne è a conoscenza a meno che non gli venga indicato esplicitamente. Se lasciato non configurato, tenta di connettersi direttamente, la rete lo blocca e l’installazione si ferma al passo di login con un timeout:


Error response from daemon: Get "https://instance-registry.ironflock.com/v2/":
net/http: request canceled while waiting for connection (Client.Timeout exceeded)

Cosa Gestisce l’Installer per Te

Quando fornisci un proxy nel comando di installazione, l’installer configura il daemon Docker per te — scrive un drop-in del proxy in /etc/systemd/system/docker.service.d/http-proxy.conf e riavvia Docker una volta affinché possa raggiungere il registry IronFlock. Questo passaggio è:

Automatico — fornisci il proxy una sola volta (vedi sotto); l’installer scrive la configurazione e riavvia Docker per te, senza alcuna configurazione manuale del daemon.
Idempotente — negli aggiornamenti successivi riavvia Docker solo se il proxy è effettivamente cambiato, così le tue app in esecuzione non vengono disturbate.
Saltato completamente quando non viene fornito alcun proxy — le installazioni con accesso diretto a internet non sono interessate.

L’installer instrada anche la connessione propria dell’Appliance al cloud attraverso il proxy — la convalida della licenza e il collegamento di gestione remota che ti permette di raggiungere la tua istanza da ironflock.com. Registra il tuo proxy nella configurazione dell’Appliance e la piattaforma lo utilizza automaticamente. Non è necessaria alcuna configurazione separata affinché l’Appliance vada online.

Eseguire l’Installer Dietro un Proxy

Il proxy è necessario in due punti: curl ne ha bisogno per scaricare l’installer e l’installer ne ha bisogno per configurare Docker. Forniscilo a entrambi in un unico comando — imposta l’URL del proxy una sola volta, passalo a curl con --proxy e all’installer con --http-proxy / --https-proxy:


# Il tuo proxy aziendale — modifica questa riga
PROXY="http://proxy.your-company.com:3128"
 
curl -fsSL --proxy "$PROXY" \
  https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
  | sudo bash -s -- <your-instance-key> --http-proxy "$PROXY" --https-proxy "$PROXY"

Sostituisci l’URL del proxy e <your-instance-key> con i tuoi valori. Se il tuo proxy richiede l’autenticazione, includi le credenziali nell’URL: http://user:password@proxy.your-company.com:3128.

Flag del proxy dell’installer:

Flag	Scopo
`--http-proxy <url>`	Proxy per il traffico HTTP non cifrato dal daemon Docker.
`--https-proxy <url>`	Proxy per il traffico HTTPS (quello che conta per il download delle immagini).
`--no-proxy <list>`	Host aggiuntivi separati da virgole che devono bypassare il proxy.

Gli stessi valori possono essere forniti come variabili d’ambiente IRONFLOCK_HTTP_PROXY, IRONFLOCK_HTTPS_PROXY e IRONFLOCK_NO_PROXY.

Se l’host esporta già HTTP_PROXY / HTTPS_PROXY, puoi invece eseguire sudo -E bash (senza i flag) e l’installer le rileverà automaticamente — ma su un Appliance nuovo queste sono di solito non impostate, quindi passarle esplicitamente come sopra è il percorso affidabile.

Il traffico locale bypassa sempre il proxy

Non devi gestire NO_PROXY manualmente. L’installer mantiene sempre localhost, 127.0.0.1 e l’indirizzo host dell’Appliance fuori dal proxy (tutto ciò che passi con --no-proxy viene mantenuto e unito). Questo garantisce che l’app store locale e il registry dell’Appliance vengano raggiunti direttamente, senza mai essere instradati attraverso il proxy aziendale.

Dispositivi Edge

Tutto quanto sopra si applica allo stesso modo ai dispositivi edge configurati con lo strumento di configurazione dei dispositivi (ironflock-init). Accetta gli stessi flag del proxy e si configura allo stesso modo — passa il proxy quando lo esegui e instrada i suoi download (gestore di pacchetti, installazione di Docker, download dell’agente) e il daemon Docker attraverso il proxy per te:


sudo ./ironflock-init -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY"

Lo script di bootstrap che scarica lo strumento di configurazione viene eseguito prima di esso, quindi fornisci il proxy anche a quel passaggio — esportalo prima nella shell affinché il suo download vada a buon fine:


export HTTP_PROXY="$PROXY"
export HTTPS_PROXY="$PROXY"
curl -sSL --proxy "$PROXY" https://instance-registry.ironflock.com/dl/reswarmify/install.sh | bash

Se il dispositivo scarica le immagini delle app da un app store di un Appliance locale anziché dal cloud, aggiungi l’host di quel registry con --no-proxy affinché quei download restino sulla rete locale.

Sui dispositivi Windows l’agente viene eseguito come servizio Windows; passa il proxy all’installer del servizio — viene salvato nell’ambiente del servizio e copre la connessione alla piattaforma e gli aggiornamenti automatici dell’agente:


reagent.exe service install -config path\to\config.flock -proxy "http://proxy.example.com:3128"

Docker Desktop non legge questa impostazione: configura il suo proxy separatamente in Settings → Resources → Proxies perché funzionino anche i pull delle immagini.

Proxy con Intercettazione TLS (CA Aziendale)

Molti proxy aziendali ispezionano il traffico HTTPS rifirmandolo con un’autorità di certificazione (CA) aziendale. Per questi, configurare il proxy è necessario ma non sufficiente — l’host dell’Appliance deve anche fidarsi di quella CA, altrimenti ogni connessione al cloud (download delle immagini, convalida della licenza, collegamento di gestione) viene rifiutata.

Installa la CA una sola volta, nello store di trust del sistema dell’host. L’Appliance monta quello store di trust in tutti i suoi container, così Docker e ogni servizio IronFlock rilevano la CA — non c’è nulla da configurare per singolo container o per singolo servizio. Poiché i container la leggono all’avvio, riavvia lo stack dopo aver aggiunto o modificato la CA (passo 3 sotto).

1. Ottenere la CA aziendale

Chiedi al tuo team di rete la root CA di “SSL inspection” / “intercettazione TLS” del proxy — lo stesso certificato già distribuito alle macchine aziendali gestite — come file .crt. È la fonte più pulita.

Installa la CA emittente, non il certificato di un singolo host. L’errore comune è salvare il certificato rifirmato dal proxy per un solo hostname (ad esempio solo instance-registry.ironflock.com). In questo modo funziona solo quell’host e tutti gli altri host del cloud continuano a fallire. Ti serve la CA che firma quei certificati.

Se non riesci a ottenere il file direttamente ma il proxy presenta la sua catena completa, puoi estrarre la CA dal collegamento — sostituisci <PROXY_HOST>:<PROXY_PORT> con il tuo proxy:


# Cattura la catena, un PEM per certificato. c1 è il leaf del singolo host (saltalo);
# c2..cN sono la catena della CA aziendale da considerare attendibile.
echo quit | openssl s_client -connect instance-registry.ironflock.com:443 \
  -proxy <PROXY_HOST>:<PROXY_PORT> -showcerts 2>/dev/null \
  | awk '/BEGIN CERTIFICATE/{n++; c=1} c{print > ("/tmp/proxy-c" n ".pem")} /END CERTIFICATE/{c=0}'
 
# Facoltativo — ispeziona ciò che è stato restituito:
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. Installarla e ricostruire lo store di trust

Se il tuo team IT ti ha fornito il file .crt direttamente:


sudo cp corporate-root-ca.crt /usr/local/share/ca-certificates/corporate-proxy-ca.crt
sudo update-ca-certificates

Se l’hai estratta dalla catena qui sopra, considera attendibile ogni certificato tranne il leaf (c1):


i=0; for f in $(ls -v /tmp/proxy-c*.pem | tail -n +2); do
  i=$((i+1)); sudo cp "$f" "/usr/local/share/ca-certificates/corporate-proxy-ca-$i.crt"
done
sudo update-ca-certificates

3. Verifica

Ogni host del cloud IronFlock deve ora essere convalidato attraverso il proxy — uno stato HTTP, non un errore TLS:


for H in instance-registry.ironflock.com web.ironflock.com cbw.ironflock.com \
         registry.ironflock.com regauth.ironflock.com; do
  curl -x http://<PROXY_HOST>:<PROXY_PORT> -sS -o /dev/null -w "$H -> %{http_code}\n" "https://$H/"
done

Un codice come 200, 401 o 404 per tutti e cinque significa che la CA è corretta. Quindi riavvia lo stack affinché i servizi la rilevino (oppure riesegui l’installer):


sudo systemctl restart ironflock.service

Accesso Remoto alle Interfacce Utente dei Dispositivi

IronFlock ti permette di aprire un’interfaccia utente che gira su un dispositivo edge o una macchina — un HMI di macchina, una pagina PLC, una schermata di configurazione o dashboard sul dispositivo — direttamente all’interno di IronFlock, da qualsiasi luogo. Questo è un abilitatore chiave per il servizio e supporto remoto: un tecnico può raggiungere l’interfaccia di una macchina senza essere in loco o sulla rete locale. L’accesso è sempre mediato e protetto dal sistema di privilegi IronFlock, così solo gli utenti autorizzati raggiungono un determinato dispositivo.

Questo tunnel di accesso remoto è basato su frp (Fast Reverse Proxy), una tecnologia open source matura e ampiamente utilizzata. IronFlock la usa esclusivamente per fornire l’accesso alle interfacce dei dispositivi descritto sopra.

Perché un proxy aziendale può creare problemi

frp ha potenti capacità di attraversamento della rete e, per questo motivo, i prodotti di sicurezza antivirus e proxy spesso lo segnalano genericamente come riskware — anche se, in quanto componente open source con una lunga tradizione, è sicuro e viene utilizzato qui solo per la funzionalità di accesso remoto autorizzata. Quando ciò accade, il proxy blocca il download del componente IronFlock che contiene frp.

Questo non compromette il tuo Appliance: il tunnel di accesso remoto è una funzionalità opzionale, quindi se quel componente viene bloccato la piattaforma si installa e funziona normalmente e semplicemente opera senza l’accesso alle interfacce dei dispositivi. Nella dashboard, i controlli di accesso remoto di un dispositivo indicano quindi che l’accesso remoto non è disponibile su questo Appliance.

Cosa deve consentire l’IT aziendale

Se la tua organizzazione vuole beneficiare delle funzionalità di servizio remoto di IronFlock, il componente IronFlock che contiene frp deve poter essere scaricato attraverso il proxy aziendale. Chiedi al tuo team di rete/sicurezza di:

Esentare il traffico di download di IronFlock dalla scansione dei contenuti antivirus / malware e dal blocco del download di file per il componente frp — l’opzione più pulita è aggiungere gli endpoint di IronFlock alla lista do-not-decrypt (bypass dell’ispezione TLS) del proxy.
Trattare il rilevamento di frp come un’eccezione approvata: si tratta di un noto falso positivo per l’uso legittimo di questa libreria open source.

Si applicano gli stessi endpoint IronFlock già elencati per l’Appliance — consulta Configurazione del Firewall; qui si tratta di non scansionare/bloccare quel traffico, oltre al semplice instradarlo.

Una volta consentito il passaggio di frp, basta rieseguire l’aggiornamento — la funzionalità si attiva automaticamente non appena il download va a buon fine, senza altre modifiche:


sudo ironflock-update

Funzionamento senza accesso remoto

Se non hai bisogno dell’accesso alle interfacce dei dispositivi — o vuoi un’installazione pulita mentre viene predisposta l’eccezione del proxy — puoi disabilitare esplicitamente il tunnel. Tutto il resto si installa normalmente:


# in fase di installazione, aggiunto al comando di installazione
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# oppure su un Appliance già installato
sudo ironflock-update --no-tunnel

La scelta viene ricordata tra un aggiornamento e l’altro. Riabilitalo in seguito (una volta che frp è consentito) con --tunnel:


sudo ironflock-update --tunnel

Risoluzione dei Problemi

L’installazione si ferma a “Logging in to instance-registry.ironflock.com” con un errore Client.Timeout. Il daemon Docker non riesce a raggiungere il registry. Riesegui l’installer e passa il tuo proxy con --http-proxy / --https-proxy, come mostrato sopra.

Il login continua a fallire dopo aver configurato il proxy. Il tuo proxy molto probabilmente intercetta il TLS. Installa la CA aziendale come descritto in Proxy con Intercettazione TLS, quindi riesegui.

Verifica che il daemon Docker veda il proxy:


sudo systemctl show --property=Environment docker
sudo docker login instance-registry.ironflock.com

Se docker login riesce da solo, l’installazione dell’Appliance supererà il passo che falliva.

Un singolo componente non riesce a scaricarsi mentre tutto il resto si installa correttamente. Di solito si tratta del componente di accesso remoto basato su frp bloccato dal tuo proxy o antivirus come riskware. L’installazione si completa comunque — solo l’accesso alle interfacce dei dispositivi non è disponibile. Per abilitarlo, fai in modo che il tuo team del proxy consenta quel traffico come descritto in Accesso Remoto alle Interfacce Utente dei Dispositivi, quindi riesegui ironflock-update. Per installare deliberatamente senza di esso, passa --no-tunnel.

Aggiornamenti

Una volta che un Appliance è installato dietro un proxy, le sue impostazioni del proxy vengono ricordate. Sia gli aggiornamenti manuali sia gli aggiornamenti automatici in background continuano a funzionare attraverso il proxy senza alcuna azione aggiuntiva — consulta Manutenzione nella guida all’Appliance.

Se l’accesso remoto alle interfacce dei dispositivi è stato bloccato al momento dell’installazione, ogni aggiornamento lo ritenta automaticamente — così, una volta che il tuo proxy consente frp, l’aggiornamento successivo attiva la funzionalità senza passaggi aggiuntivi.