Za firmowym proxy

Wiele sieci fabrycznych i korporacyjnych dociera do internetu wyłącznie przez firmowe proxy HTTP (na przykład proxy Squid na porcie 3128). IronFlock Appliance instaluje się i działa w takiej konfiguracji bez problemów — podajesz swoje proxy w poleceniu instalacyjnym, a instalator konfiguruje za ciebie całą resztę.

Ta strona zakłada, że host Appliance nie ma ustawionych żadnych zmiennych środowiskowych proxy — proxy podajesz jawnie. Wyjaśnia, co instalator obsługuje automatycznie, oraz jeden dodatkowy krok potrzebny dla proxy przechwytujących TLS.

To jest uzupełnienie poświęcone proxy dla sekcji Konfiguracja zapory sieciowej w przewodniku po Appliance. Te same punkty końcowe IronFlock muszą być osiągalne — różnica polega na tym, że tutaj dociera się do nich przez twoje proxy.

Dlaczego proxy wymaga uwagi

Obrazy platformy IronFlock są pobierane przez demona Docker — usługę działającą w tle z własną konfiguracją sieciową, niezależną od twojej powłoki. Nawet na hoście, który poza tym dociera do internetu przez proxy, demon o nim nie wie, dopóki nie zostanie mu to jawnie wskazane. Pozostawiony bez konfiguracji próbuje łączyć się bezpośrednio, sieć go blokuje, a instalacja zatrzymuje się na kroku logowania z przekroczeniem czasu:

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

Co instalator obsługuje za ciebie

Gdy podasz proxy w poleceniu instalacyjnym, instalator konfiguruje za ciebie demona Docker — zapisuje plik drop-in proxy w /etc/systemd/system/docker.service.d/http-proxy.conf i jednorazowo restartuje Docker, aby mógł dotrzeć do rejestru IronFlock. Ten krok jest:

• Bezobsługowy — proxy podajesz raz (zobacz poniżej); instalator zapisuje konfigurację i restartuje za ciebie Docker, bez ręcznej konfiguracji demona.
• Idempotentny — przy późniejszych aktualizacjach restartuje Docker tylko wtedy, gdy proxy faktycznie się zmieniło, więc twoje działające aplikacje nie są zakłócane.
• Całkowicie pomijany, gdy proxy nie zostanie podane — instalacje z bezpośrednim dostępem do internetu nie są tym dotknięte.

Instalator kieruje też przez proxy własne połączenie Appliance z chmurą — walidację licencji oraz łącze zdalnego zarządzania, które pozwala dotrzeć do twojej instancji z ironflock.com. Zapisuje twoje proxy w konfiguracji Appliance, a platforma używa go automatycznie. Aby Appliance pojawił się online, nie jest potrzebna żadna osobna konfiguracja.

Uruchamianie instalatora za proxy

Proxy jest potrzebne w dwóch miejscach: curl potrzebuje go, aby pobrać instalator, a instalator potrzebuje go, aby skonfigurować Docker. Podaj je obu w jednym poleceniu — ustaw adres URL proxy raz, przekaż go do curl za pomocą --proxy, a do instalatora za pomocą --http-proxy / --https-proxy:

# Twoje firmowe proxy — edytuj tę linię
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"

Zastąp adres URL proxy i <your-instance-key> własnymi wartościami. Jeśli twoje proxy wymaga uwierzytelnienia, dołącz poświadczenia do adresu URL: http://user:password@proxy.your-company.com:3128.

Flagi proxy instalatora:

Te same wartości można podać jako zmienne środowiskowe IRONFLOCK_HTTP_PROXY, IRONFLOCK_HTTPS_PROXY i IRONFLOCK_NO_PROXY.

Jeśli host już eksportuje HTTP_PROXY / HTTPS_PROXY, możesz zamiast tego uruchomić sudo -E bash (bez flag), a instalator wykryje je automatycznie — ale na świeżym Appliance są one zwykle nieustawione, więc jawne przekazanie ich w sposób pokazany powyżej jest niezawodną drogą.

Ruch lokalny zawsze omija proxy

Nie musisz zarządzać NO_PROXY ręcznie. Instalator zawsze pozostawia localhost, 127.0.0.1 oraz własny adres hosta Appliance poza proxy (wszystko, co przekażesz za pomocą --no-proxy, jest zachowywane i scalane). Gwarantuje to, że do lokalnego app store i rejestru Appliance dociera się bezpośrednio, nigdy kierując ruch na zewnątrz przez firmowe proxy.

Urządzenia brzegowe

Wszystko powyższe odnosi się w równym stopniu do urządzeń brzegowych konfigurowanych za pomocą narzędzia konfiguracji urządzeń (ironflock-init). Przyjmuje ono te same flagi proxy i konfiguruje się w ten sam sposób — przekaż proxy przy jego uruchamianiu, a poprowadzi przez nie swoje pobierania (menedżer pakietów, instalacja Dockera, pobranie agenta) oraz demona Docker:

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

Skrypt bootstrap, który pobiera narzędzie konfiguracji, uruchamia się przed nim, więc temu krokowi również podaj proxy — wyeksportuj je najpierw w powłoce, aby jego pobieranie się powiodło:

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

Jeśli urządzenie pobiera obrazy aplikacji z lokalnego app store Appliance, a nie z chmury, dodaj host tego rejestru za pomocą --no-proxy, aby te pobrania pozostały w sieci lokalnej.

Na urządzeniach z systemem Windows agent działa jako usługa systemu Windows; przekaż proxy instalatorowi usługi — zostanie zapisane w środowisku usługi i obejmie połączenie z platformą oraz automatyczne aktualizacje agenta:

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

Docker Desktop nie odczytuje tego ustawienia: skonfiguruj jego proxy osobno w Settings → Resources → Proxies, aby działało również pobieranie obrazów.

Proxy przechwytujące TLS (firmowy urząd certyfikacji)

Wiele firmowych proxy inspekcjonuje ruch HTTPS, ponownie podpisując go firmowym urzędem certyfikacji (CA). W takim przypadku skonfigurowanie proxy jest konieczne, ale niewystarczające — host Appliance musi również ufać temu CA, w przeciwnym razie każde połączenie z chmurą (pobieranie obrazów, walidacja licencji, łącze zarządzania) zostanie odrzucone.

Zainstaluj CA raz, w systemowym magazynie zaufania hosta. Appliance montuje ten magazyn zaufania we wszystkich swoich kontenerach, więc Docker i każda usługa IronFlock uwzględniają CA — nie ma nic do skonfigurowania na poziomie pojedynczego kontenera czy usługi. Ponieważ kontenery odczytują go przy uruchomieniu, zrestartuj stos po dodaniu lub zmianie CA (krok 3 poniżej).

1. Uzyskaj firmowy CA

Poproś swój zespół sieciowy o główny CA „inspekcji SSL” / „przechwytywania TLS” proxy — ten sam certyfikat, który jest już wdrożony na zarządzanych maszynach firmowych — w postaci pliku .crt. To najczystsze źródło.

Zainstaluj wystawiający CA, a nie certyfikat pojedynczego hosta. Częstym błędem jest zapisanie ponownie podpisanego przez proxy certyfikatu dla jednego hosta (np. tylko instance-registry.ironflock.com). Sprawia to, że działa tylko ten jeden host, a wszystkie pozostałe hosty w chmurze nadal zawodzą. Potrzebujesz CA, który podpisuje te certyfikaty.

Jeśli nie możesz uzyskać pliku bezpośrednio, ale proxy prezentuje swój pełny łańcuch, możesz wyodrębnić CA z połączenia — zastąp <PROXY_HOST>:<PROXY_PORT> swoim proxy:

# Przechwyć łańcuch, jeden PEM na certyfikat. c1 to liść danego hosta (pomiń go);
# c2..cN to firmowy łańcuch CA do zaufania.
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}'
 
# Opcjonalnie — sprawdź, co wróciło:
for f in /tmp/proxy-c*.pem; do echo "== $f =="; openssl x509 -in "$f" -noout -subject -issuer; done

2. Zainstaluj go i przebuduj magazyn zaufania

Jeśli twój zespół IT dał ci .crt bezpośrednio:

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

Jeśli wyodrębniłeś go z powyższego łańcucha, zaufaj każdemu certyfikatowi z wyjątkiem liścia (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. Zweryfikuj

Każdy host IronFlock w chmurze musi teraz walidować przez proxy — status HTTP, a nie błąd 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

Kod taki jak 200, 401 lub 404 dla wszystkich pięciu oznacza, że CA jest poprawny. Następnie zrestartuj stos, aby usługi go uwzględniły (lub uruchom ponownie instalator):

sudo systemctl restart ironflock.service

Zdalny dostęp do interfejsów użytkownika urządzeń

IronFlock pozwala otworzyć interfejs użytkownika działający na urządzeniu brzegowym lub maszynie — HMI maszyny, stronę PLC, ekran konfiguracji lub pulpitu na urządzeniu — bezpośrednio w IronFlock, z dowolnego miejsca. To kluczowy element umożliwiający zdalny serwis i wsparcie: inżynier może dotrzeć do interfejsu maszyny bez przebywania on-site ani w sieci lokalnej. Dostęp jest zawsze pośredniczony i strzeżony przez system uprawnień IronFlock, więc do danego urządzenia docierają wyłącznie autoryzowani użytkownicy.

Ten tunel zdalnego dostępu jest zbudowany na frp (Fast Reverse Proxy) — dojrzałej, powszechnie używanej technologii open source. IronFlock wykorzystuje go wyłącznie do zapewnienia opisanego powyżej dostępu do interfejsów urządzeń.

Dlaczego firmowe proxy może przeszkadzać

frp ma zaawansowane możliwości pokonywania barier sieciowych i z tego powodu produkty antywirusowe oraz zabezpieczające proxy często oznaczają go ogólnie jako riskware — mimo że jako komponent open source z długą historią jest bezpieczny i jest tu używany wyłącznie do usankcjonowanej funkcji zdalnego dostępu. Gdy tak się dzieje, proxy blokuje pobranie komponentu IronFlock zawierającego frp.

To nie psuje twojego Appliance: tunel zdalnego dostępu jest funkcją opcjonalną, więc jeśli ten komponent zostanie zablokowany, platforma instaluje się i działa normalnie, po prostu funkcjonując bez dostępu do interfejsów urządzeń. W panelu elementy sterujące zdalnym dostępem danego urządzenia wskazują wtedy, że zdalny dostęp nie jest dostępny na tym Appliance.

Na co musi zezwolić firmowe IT

Jeśli twoja organizacja chce skorzystać z funkcji zdalnego serwisu IronFlock, komponent IronFlock zawierający frp musi mieć zezwolenie na pobranie przez firmowe proxy. Poproś swój zespół sieciowy/bezpieczeństwa, aby:

• Wyłączył ruch pobierania IronFlock ze skanowania treści antywirusowego / pod kątem złośliwego oprogramowania oraz z blokowania pobierania plików dla komponentu frp — najczystszą opcją jest dodanie punktów końcowych IronFlock do listy do-not-decrypt (pomijania inspekcji TLS) proxy.
• Traktował wykrycie frp jako zatwierdzony wyjątek: to dobrze znany fałszywy alarm dla legalnego użycia tej biblioteki open source.

Obowiązują te same punkty końcowe IronFlock, które są już wymienione dla Appliance — zobacz Konfiguracja zapory sieciowej; tu chodzi o niepoddawanie tego ruchu skanowaniu/blokowaniu, ponad samym jego kierowaniem.

Gdy frp zostanie już przepuszczony, wystarczy uruchomić ponownie aktualizację — funkcja włącza się automatycznie, gdy tylko pobranie się powiedzie, bez żadnych innych zmian:

sudo ironflock-update

Działanie bez zdalnego dostępu

Jeśli nie potrzebujesz dostępu do interfejsów urządzeń — lub chcesz czystej instalacji w czasie, gdy załatwiany jest wyjątek proxy — możesz jawnie wyłączyć tunel. Cała reszta instaluje się jak zwykle:

# w czasie instalacji, dołączone do polecenia instalacyjnego
... | sudo bash -s -- <your-instance-key> --no-tunnel
 
# lub na już zainstalowanym Appliance
sudo ironflock-update --no-tunnel

Wybór jest zapamiętywany między aktualizacjami. Włącz go ponownie później (gdy frp zostanie przepuszczony) za pomocą --tunnel:

sudo ironflock-update --tunnel

Rozwiązywanie problemów

Instalacja zatrzymuje się na „Logging in to instance-registry.ironflock.com” z błędem Client.Timeout. Demon Docker nie może dotrzeć do rejestru. Uruchom ponownie instalator i przekaż swoje proxy za pomocą --http-proxy / --https-proxy, jak pokazano powyżej.

Logowanie nadal nie powiodło się po skonfigurowaniu proxy. Twoje proxy najprawdopodobniej przechwytuje TLS. Zainstaluj firmowy CA zgodnie z opisem w sekcji Proxy przechwytujące TLS, a następnie uruchom ponownie.

Sprawdź, czy demon Docker widzi proxy:

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

Jeśli docker login powiedzie się samodzielnie, instalacja Appliance przejdzie poza nieudany krok.

Pojedynczy komponent nie może się pobrać, podczas gdy cała reszta instaluje się bez problemów. To zwykle komponent zdalnego dostępu oparty na frp, blokowany przez twoje proxy lub antywirus jako riskware. Instalacja i tak kończy się pomyślnie — niedostępny jest jedynie dostęp do interfejsów urządzeń. Aby go włączyć, poproś zespół zarządzający proxy o przepuszczenie tego ruchu zgodnie z opisem w sekcji Zdalny dostęp do interfejsów użytkownika urządzeń, a następnie uruchom ponownie ironflock-update. Aby celowo zainstalować bez tego komponentu, przekaż --no-tunnel.

Aktualizacje

Gdy Appliance zostanie zainstalowany za proxy, jego ustawienia proxy są zapamiętywane. Zarówno ręczne aktualizacje, jak i automatyczne aktualizacje w tle nadal działają przez proxy bez dodatkowych działań — zobacz Utrzymanie w przewodniku po Appliance.

Jeśli zdalny dostęp do interfejsów urządzeń został zablokowany w czasie instalacji, każda aktualizacja automatycznie ponawia jego próbę — więc gdy tylko twoje proxy przepuści frp, następna aktualizacja włączy tę funkcję bez żadnych dodatkowych kroków.