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 nel file di configurazione centrale dell’Appliance, /opt/ironflock/.env, e la piattaforma lo utilizza automaticamente — quel file resta la fonte autoritativa a ogni aggiornamento successivo (vedi Modificare o Rimuovere il Proxy in Seguito). 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:[email protected]:3128 — vedi Autenticazione al Proxy per sapere quale account usare.

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. Le variabili d’ambiente della shell inizializzano solo la prima installazione: una volta che l’Appliance è installato, la sua configurazione registrata ha la precedenza (vedi Modificare o Rimuovere il Proxy in Seguito).

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.

Autenticazione al Proxy

Se il tuo proxy richiede un login, assegna all’Appliance un proprio account di servizio anziché l’account di una persona. Il suo traffico compare così nei log del proxy sotto un nome controllato dal tuo team di rete, che può limitare ciò che l’account è autorizzato a raggiungere e disattivarlo o cambiarne le credenziali senza toccare il login personale di nessuno. È il lato proxy di Identità di Rete per gli Host IronFlock.

Supportata: autenticazione Basic. Inserisci l’account nell’URL del proxy — http://user:[email protected]:3128 — nel comando di installazione, oppure in /opt/ironflock/.env seguito da sudo ironflock-update. Codifica in URL i caratteri speciali presenti nella password (ad esempio @ → %40).
Non ancora supportata: autenticazione integrata di Windows (Kerberos, NTLM). Se il tuo proxy non accetta altro, chiedi al tuo team di rete di consentire l’account di servizio con autenticazione Basic, oppure di ammettere l’indirizzo dell’Appliance senza autenticazione come host denominato.

Cosa comunicare al tuo team di rete su questo traffico:

Va esclusivamente verso gli endpoint dell’elenco Configurazione del Firewall, in HTTPS sulla porta 443. Il relay e-mail sulla porta 2525 non usa mai il proxy.
La connessione di gestione remota verso cbw.ironflock.com è un WebSocket di lunga durata con traffico keep-alive ogni pochi secondi. Se il proxy interrompe le connessioni di lunga durata dopo un tempo fisso, l’Appliance si riconnette da solo entro pochi secondi, ma gli utenti remoti possono notare ogni volta una breve interruzione — dove possibile, esenta questa connessione dai limiti di durata delle connessioni.

Modificare o Rimuovere il Proxy in Seguito

Il proxy viene registrato nel file di configurazione centrale dell’Appliance, /opt/ironflock/.env. Quel file è la fonte autoritativa: qualunque cosa contenga è ciò che ogni aggiornamento applica. Riconfigurare il proxy su un Appliance installato richiede quindi due passaggi:

Modifica le voci HTTP_PROXY, HTTPS_PROXY e NO_PROXY in /opt/ironflock/.env.
Esegui sudo ironflock-update.

L’aggiornamento riapplica le impostazioni ovunque in un solo passaggio — il daemon Docker, i servizi della piattaforma, l’agente del dispositivo e il tunnel di accesso remoto — riavviando solo ciò che è effettivamente cambiato.

In alternativa, passa i nuovi valori come flag — hanno la precedenza sul file e vengono salvati al suo interno:


sudo ironflock-update --https-proxy "http://user:[email protected]:3128"

Ogni impostazione è indipendente: passare solo --https-proxy lascia intatta la tua lista NO_PROXY esistente (lo schema HTTP mancante viene replicato automaticamente).

Per rimuovere il proxy — ad esempio dopo aver spostato l’Appliance su una rete con accesso diretto a internet — svuota le voci in /opt/ironflock/.env (HTTP_PROXY=, HTTPS_PROXY=), oppure passa flag esplicitamente vuoti, quindi aggiorna:


sudo ironflock-update --http-proxy "" --https-proxy ""

La configurazione del proxy viene nuovamente rimossa dal daemon Docker e dall’agente del dispositivo e l’Appliance torna alle connessioni dirette. La tua lista NO_PROXY viene mantenuta per una successiva riabilitazione.

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 — 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"

Quali host aggirano il proxy

NO_PROXY si applica al nome host che il client compone, mai all’indirizzo in cui quel nome viene risolto. Un appliance che il dispositivo raggiunge tramite il suo nome — cioè qualsiasi appliance in modalità dominio, vedi Interfacce delle app e HTTPS — deve quindi essere indicato esplicitamente, altrimenti l’agente invia la connessione all’appliance locale attraverso il proxy aziendale. Poiché la maggior parte dei proxy rifiuta di instradare di nuovo verso la rete interna, il dispositivo non va mai online.

L’installer lo ricava dal .flock del dispositivo stesso. Accanto a localhost e 127.0.0.1 aggiunge il dominio dell’appliance — sia nella forma semplice sia in quella con il punto iniziale — e qualsiasi host di registry contattato senza TLS. I dispositivi cloud non ricevono nulla oltre alle due voci di loopback, perché i loro endpoint sono pubblici e il proxy serve davvero.

Tutto il resto di cui la tua installazione ha bisogno va in -no-proxy, la controparte dell’omonimo flag di ironflock-init:


reagent.exe service install -config path\to\config.flock `
  -proxy "http://proxy.example.com:3128" `
  -no-proxy "buildserver.corp.example,10.0.0.0/8"

Modificare le impostazioni in seguito

Il risultato viene scritto in %ProgramData%\IronFlock\Reagent\proxy.env, e da quel momento è quel file a fare fede:


HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128
NO_PROXY=localhost,127.0.0.1,appliance.corp.example,.appliance.corp.example

Modificalo e riesegui reagent.exe service install per applicare la modifica. Un’installazione successiva non sovrascrive mai il file e service uninstall conserva la directory dell’agente: le tue impostazioni sopravvivono quindi al ciclo di disinstallazione/installazione che una reinstallazione del servizio richiede. Usa -force-proxy per sostituire deliberatamente il file con i valori dei flag.

Elimina una voce se questa installazione raggiunge l’appliance attraverso il proxy. Entrambi gli scenari esistono davvero: un appliance sulla stessa LAN di stabilimento viene raggiunto direttamente, mentre uno ospitato centralmente può essere accessibile solo tramite il proxy aziendale. L’installer non può distinguerli, quindi scrive gli host alla lettera — rimuovi quelli che non valgono per la tua rete.

Docker si configura separatamente

Docker Desktop non legge né proxy.env né l’ambiente del servizio. Le immagini vengono scaricate dal daemon Docker, che ha impostazioni proprie in Settings → Resources → Proxies, inclusa la propria lista di esclusioni — e anche a quella serve l’host dell’appliance. Un proxy corretto sul lato agente non risolve docker pull.

Dispositivi Linux

ironflock-init accetta --no-proxy direttamente, quindi l’appliance può essere indicato già durante il setup:


sudo ./ironflock-init -c mydevice.flock \
  --http-proxy "$PROXY" --https-proxy "$PROXY" \
  --no-proxy "appliance.corp.example.com"

Questo crea un drop-in systemd in /etc/systemd/system/reagent.service.d/http-proxy.conf. Non modificare quel file per regolare le impostazioni in seguito — lo strumento di setup lo riscrive. Usa invece systemctl edit reagent, che crea un override.conf applicato da systemd dopo il drop-in dell’installer e che IronFlock non tocca mai:


sudo systemctl edit reagent


[Service]
Environment="NO_PROXY=localhost,127.0.0.1,appliance.corp.example.com"


sudo systemctl restart reagent

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 due cose precise:

Un’eccezione alla scansione per i download di immagini da instance-registry.ironflock.com, così il verdetto generico di riskware non blocca il componente del tunnel. È un intervento più mirato rispetto all’esclusione di tutto il traffico IronFlock dall’ispezione TLS — il resto del traffico dell’Appliance può continuare a essere ispezionato.
La registrazione del rilevamento come falso positivo noto. frp è un reverse proxy open source ampiamente utilizzato; IronFlock lo usa solo per la funzionalità di accesso remoto con controllo degli accessi descritta sopra.

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 in /opt/ironflock/.env e riapplicate a ogni aggiornamento. 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. Per indirizzare l’Appliance verso un proxy diverso — o scollegarlo completamente dal proxy — consulta Modificare o Rimuovere il Proxy in Seguito.

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.