Hinter einem Unternehmens-Proxy

Viele Fabrik- und Unternehmensnetzwerke erreichen das Internet nur über einen Unternehmens-HTTP-Proxy (zum Beispiel einen Squid-Proxy auf Port 3128). Die IronFlock Appliance installiert und läuft in diesem Setup sauber — Sie geben Ihren Proxy beim Installationsbefehl an, und der Installer konfiguriert alles Übrige für Sie.

Diese Seite geht davon aus, dass auf dem Appliance-Host keine Proxy-Umgebungsvariablen gesetzt sind — Sie geben den Proxy explizit an. Sie erklärt, was der Installer automatisch übernimmt, und den einen zusätzlichen Schritt, der für Proxys nötig ist, die TLS abfangen.

Dies ist das Proxy-Pendant zum Abschnitt Firewall-Konfiguration des Appliance-Leitfadens. Dieselben IronFlock-Endpunkte müssen erreichbar sein — der Unterschied besteht darin, dass sie hier über Ihren Proxy erreicht werden.

Warum ein Proxy Aufmerksamkeit erfordert

Die IronFlock-Plattform-Images werden vom Docker-Daemon heruntergeladen — einem Hintergrunddienst mit eigener Netzwerkkonfiguration, getrennt von Ihrer Shell. Selbst auf einem Host, der das Internet ansonsten über den Proxy erreichen kann, weiß der Daemon nichts davon, sofern er es nicht ausdrücklich mitgeteilt bekommt. Bleibt er unkonfiguriert, versucht er sich direkt zu verbinden, das Netzwerk blockiert ihn, und die Installation bricht beim Login-Schritt mit einem Timeout ab:

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

Was der Installer für Sie übernimmt

Wenn Sie beim Installationsbefehl einen Proxy angeben, konfiguriert der Installer den Docker-Daemon für Sie — er schreibt ein Proxy-Drop-in unter /etc/systemd/system/docker.service.d/http-proxy.conf und startet Docker einmal neu, damit es die IronFlock-Registry erreichen kann. Dieser Schritt ist:

• Ohne Handarbeit — Sie geben den Proxy einmal an (siehe unten); der Installer schreibt die Konfiguration und startet Docker für Sie neu, kein manuelles Daemon-Setup.
• Idempotent — bei späteren Updates startet er Docker nur neu, wenn sich der Proxy tatsächlich geändert hat, sodass Ihre laufenden Apps nicht gestört werden.
• Komplett übersprungen, wenn kein Proxy angegeben wird — Installationen mit direkter Internetverbindung sind nicht betroffen.

Der Installer leitet außerdem die eigene Verbindung der Appliance zur Cloud über den Proxy — die Lizenzvalidierung und die Remote-Management-Verbindung, über die Sie Ihre Instanz von ironflock.com aus erreichen. Er hinterlegt Ihren Proxy in der Appliance-Konfiguration, und die Plattform verwendet ihn automatisch. Für das Online-Gehen der Appliance ist kein separates Setup erforderlich.

Den Installer hinter einem Proxy ausführen

Der Proxy wird an zwei Stellen benötigt: curl benötigt ihn, um den Installer herunterzuladen, und der Installer benötigt ihn, um Docker zu konfigurieren. Geben Sie ihn beiden in einem Befehl an — setzen Sie die Proxy-URL einmal, übergeben Sie sie an curl mit --proxy und an den Installer mit --http-proxy / --https-proxy:

# Ihr Unternehmens-Proxy — diese Zeile bearbeiten
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"

Ersetzen Sie die Proxy-URL und <your-instance-key> durch Ihre eigenen Werte. Wenn Ihr Proxy eine Authentifizierung erfordert, geben Sie die Zugangsdaten in der URL an: http://user:password@proxy.your-company.com:3128.

Proxy-Flags des Installers:

Dieselben Werte können als Umgebungsvariablen IRONFLOCK_HTTP_PROXY, IRONFLOCK_HTTPS_PROXY und IRONFLOCK_NO_PROXY angegeben werden.

Wenn der Host HTTP_PROXY / HTTPS_PROXY bereits exportiert, können Sie stattdessen sudo -E bash (ohne die Flags) ausführen, und der Installer erkennt sie automatisch — auf einer frischen Appliance sind diese aber meist nicht gesetzt, sodass das explizite Übergeben wie oben der verlässliche Weg ist.

Lokaler Verkehr umgeht den Proxy immer

Sie müssen NO_PROXY nicht von Hand verwalten. Der Installer hält localhost, 127.0.0.1 und die eigene Host-Adresse der Appliance stets vom Proxy fern (alles, was Sie mit --no-proxy übergeben, wird beibehalten und zusammengeführt). Dadurch werden der lokale App Store und die Registry der Appliance direkt erreicht und niemals über den Unternehmens-Proxy nach außen geleitet.

Edge-Geräte

Alles oben Genannte gilt gleichermaßen für Edge-Geräte, die mit dem Geräte-Setup-Tool (ironflock-init) eingerichtet werden. Es nimmt die gleichen Proxy-Flags entgegen und konfiguriert sich auf dieselbe Weise — übergeben Sie den Proxy beim Ausführen, und es leitet seine Downloads (Paketmanager, Docker-Installation, Agent-Download) und den Docker-Daemon für Sie über den Proxy:

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

Das Bootstrap-Skript, das das Setup-Tool herunterlädt, läuft davor, geben Sie also auch diesem Schritt den Proxy mit — exportieren Sie ihn zuerst in der Shell, damit der Download gelingt:

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

Wenn das Gerät App-Images aus einem lokalen Appliance-App-Store statt aus der Cloud bezieht, fügen Sie den Host dieser Registry mit --no-proxy hinzu, damit diese Downloads im lokalen Netzwerk bleiben.

Auf Windows-Geräten läuft der Agent als Windows-Dienst; übergeben Sie den Proxy dem Dienst-Installer — er wird in der Dienstumgebung hinterlegt und deckt die Plattformverbindung sowie die Selbst-Updates des Agenten ab:

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

Docker Desktop liest diese Einstellung nicht: Konfigurieren Sie dessen Proxy separat unter Settings → Resources → Proxies, damit auch Image-Pulls funktionieren.

TLS-abfangende Proxys (Unternehmens-CA)

Viele Unternehmens-Proxys inspizieren HTTPS-Verkehr, indem sie ihn mit einer firmeneigenen Zertifizierungsstelle (CA) neu signieren. Für diese ist die Konfiguration des Proxys notwendig, aber nicht ausreichend — der Appliance-Host muss zusätzlich dieser CA vertrauen, andernfalls wird jede Cloud-Verbindung (Image-Downloads, Lizenzvalidierung, die Management-Verbindung) abgewiesen.

Installieren Sie die CA einmalig im System-Vertrauensspeicher des Hosts. Die Appliance bindet diesen Vertrauensspeicher in alle ihre Container ein, sodass Docker und jeder IronFlock-Dienst die CA übernehmen — es gibt nichts pro Container oder pro Dienst zu konfigurieren. Da die Container ihn beim Start einlesen, starten Sie den Stack nach dem Hinzufügen oder Ändern der CA neu (Schritt 3 unten).

1. Den Unternehmens-CA beschaffen

Fragen Sie Ihr Netzwerk-Team nach dem „SSL-Inspection”- / „TLS-Interception”-Root-CA des Proxys — demselben Zertifikat, das bereits auf verwalteten Unternehmensrechnern ausgerollt ist — als .crt-Datei. Das ist die sauberste Quelle.

Installieren Sie den ausstellenden CA, nicht das Zertifikat eines einzelnen Hosts. Der häufige Fehler besteht darin, das vom Proxy neu signierte Zertifikat für einen Hostnamen zu speichern (z. B. nur instance-registry.ironflock.com). Dadurch funktioniert nur dieser eine Host, während alle anderen Cloud-Hosts weiterhin fehlschlagen. Sie benötigen den CA, der diese Zertifikate signiert.

Wenn Sie die Datei nicht direkt erhalten können, der Proxy aber seine vollständige Kette präsentiert, können Sie den CA von der Leitung extrahieren — ersetzen Sie <PROXY_HOST>:<PROXY_PORT> durch Ihren Proxy:

# Die Kette erfassen, ein PEM pro Zertifikat. c1 ist das hostspezifische Leaf (überspringen);
# c2..cN sind die zu vertrauende Unternehmens-CA-Kette.
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}'
 
# Optional — prüfen, was zurückkam:
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. Ihn installieren und den Vertrauensspeicher neu aufbauen

Wenn Ihr IT-Team Ihnen die .crt direkt gegeben hat:

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

Wenn Sie ihn aus der obigen Kette extrahiert haben, vertrauen Sie jedem Zertifikat außer dem 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. Überprüfen

Jeder IronFlock-Cloud-Host muss sich nun über den Proxy validieren lassen — ein HTTP-Status, kein TLS-Fehler:

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

Ein Code wie 200, 401 oder 404 für alle fünf bedeutet, dass der CA korrekt ist. Starten Sie dann den Stack neu, damit die Dienste ihn übernehmen (oder führen Sie den Installer erneut aus):

sudo systemctl restart ironflock.service

Remote-Zugriff auf Geräte-Benutzeroberflächen

IronFlock ermöglicht es Ihnen, eine Benutzeroberfläche, die auf einem Edge-Gerät oder einer Maschine läuft — ein Maschinen-HMI, eine SPS-Seite, ein geräteinternes Konfigurations- oder Dashboard-Bildschirm — direkt innerhalb von IronFlock zu öffnen, von überall aus. Dies ist ein zentraler Wegbereiter für Remote-Service und -Support: Ein Techniker kann die Oberfläche einer Maschine erreichen, ohne vor Ort oder im lokalen Netzwerk zu sein. Der Zugriff wird stets durch das IronFlock-Berechtigungssystem vermittelt und abgesichert, sodass nur autorisierte Benutzer ein bestimmtes Gerät erreichen.

Dieser Remote-Access-Tunnel basiert auf frp (Fast Reverse Proxy), einer ausgereiften, weit verbreiteten Open-Source-Technologie. IronFlock verwendet sie ausschließlich, um den oben beschriebenen Zugriff auf Geräteoberflächen bereitzustellen.

Warum ein Unternehmens-Proxy im Weg stehen kann

frp verfügt über leistungsfähige Fähigkeiten zur Netzwerk-Traversierung, und aus diesem Grund stufen Antiviren- und Proxy-Sicherheitsprodukte es häufig pauschal als Riskware ein — obwohl es als Open-Source-Komponente mit langer Erfolgsgeschichte sicher ist und hier nur für die genehmigte Remote-Access-Funktion verwendet wird. In diesem Fall blockiert der Proxy den Download der IronFlock-Komponente, die frp enthält.

Dies macht Ihre Appliance nicht funktionsunfähig: Der Remote-Access-Tunnel ist eine optionale Funktion, sodass die Plattform bei blockierter Komponente normal installiert und läuft und einfach ohne Zugriff auf Geräteoberflächen arbeitet. Im Dashboard zeigen die Remote-Access-Steuerelemente eines Geräts dann an, dass der Remote-Zugriff auf dieser Appliance nicht verfügbar ist.

Was die Unternehmens-IT freigeben muss

Wenn Ihre Organisation von den Remote-Service-Funktionen von IronFlock profitieren möchte, muss die IronFlock-Komponente, die frp enthält, durch den Unternehmens-Proxy heruntergeladen werden dürfen. Bitten Sie Ihr Netzwerk-/Sicherheitsteam darum:

• Den Download-Verkehr von IronFlock von der Antiviren-/Malware-Inhaltsprüfung und der Dateidownload-Blockierung auszunehmen für die frp-Komponente — die sauberste Option ist, die Endpunkte von IronFlock zur Do-not-decrypt-Liste (TLS-Inspection-Bypass) des Proxys hinzuzufügen.
• Die frp-Erkennung als genehmigte Ausnahme zu behandeln: Es handelt sich um einen bekannten False Positive bei legitimer Nutzung dieser Open-Source-Bibliothek.

Dieselben IronFlock-Endpunkte, die bereits für die Appliance aufgeführt sind, gelten hier — siehe Firewall-Konfiguration; hier geht es darum, diesen Verkehr nicht zu prüfen/blockieren, zusätzlich dazu, ihn lediglich zu leiten.

Sobald frp durchgelassen wird, führen Sie einfach das Update erneut aus — die Funktion schaltet sich automatisch ein, sobald der Download gelingt, ohne weitere Änderung:

sudo ironflock-update

Betrieb ohne Remote-Zugriff

Wenn Sie keinen Zugriff auf Geräteoberflächen benötigen — oder eine saubere Installation wünschen, während die Proxy-Ausnahme eingerichtet wird — können Sie den Tunnel explizit deaktivieren. Alles Übrige installiert sich wie gewohnt:

# zur Installationszeit, an den Installationsbefehl angehängt
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# oder auf einer bereits installierten Appliance
sudo ironflock-update --no-tunnel

Die Auswahl wird über Updates hinweg gemerkt. Aktivieren Sie sie später wieder (sobald frp erlaubt ist) mit --tunnel:

sudo ironflock-update --tunnel

Fehlerbehebung

Die Installation bleibt bei „Logging in to instance-registry.ironflock.com” mit einem Client.Timeout-Fehler stehen. Der Docker-Daemon kann die Registry nicht erreichen. Führen Sie den Installer erneut aus und übergeben Sie Ihren Proxy mit --http-proxy / --https-proxy, wie oben gezeigt.

Der Login schlägt auch nach der Konfiguration des Proxys weiterhin fehl. Höchstwahrscheinlich fängt Ihr Proxy TLS ab. Installieren Sie den Unternehmens-CA wie unter TLS-abfangende Proxys beschrieben und führen Sie ihn erneut aus.

Prüfen, ob der Docker-Daemon den Proxy sieht:

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

Wenn docker login für sich genommen erfolgreich ist, kommt die Appliance-Installation am fehlschlagenden Schritt vorbei.

Eine einzelne Komponente lässt sich nicht herunterladen, während alles andere problemlos installiert. Dies ist in der Regel die frp-basierte Remote-Access-Komponente, die von Ihrem Proxy oder Antivirus als Riskware blockiert wird. Die Installation wird trotzdem abgeschlossen — nur der Zugriff auf Geräteoberflächen ist nicht verfügbar. Um ihn zu aktivieren, lassen Sie Ihr Proxy-Team diesen Verkehr freigeben, wie unter Remote-Zugriff auf Geräte-Benutzeroberflächen beschrieben, und führen Sie anschließend ironflock-update erneut aus. Um bewusst ohne ihn zu installieren, übergeben Sie --no-tunnel.

Updates

Sobald eine Appliance hinter einem Proxy installiert ist, werden ihre Proxy-Einstellungen gemerkt. Sowohl manuelle Updates als auch automatische Hintergrund-Updates funktionieren weiterhin über den Proxy ohne zusätzliche Maßnahmen — siehe Wartung im Appliance-Leitfaden.

Wenn der Remote-Zugriff auf Geräteoberflächen zur Installationszeit blockiert war, versucht jedes Update ihn automatisch erneut — sobald Ihr Proxy frp also zulässt, schaltet das nächste Update die Funktion ohne zusätzliche Schritte ein.