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 centralnym pliku konfiguracyjnym Appliance, /opt/ironflock/.env, a platforma używa go automatycznie — ten plik pozostaje autorytatywnym źródłem przy każdej późniejszej aktualizacji (zobacz Późniejsza zmiana lub usunięcie proxy). 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:[email protected]:3128 — którego konta użyć, wyjaśnia sekcja Uwierzytelnianie w proxy.

Flagi proxy instalatora:

Flaga	Przeznaczenie
`--http-proxy <url>`	Proxy dla zwykłego ruchu HTTP od demona Docker.
`--https-proxy <url>`	Proxy dla ruchu HTTPS (to ono ma znaczenie przy pobieraniu obrazów).
`--no-proxy <list>`	Dodatkowe hosty (rozdzielone przecinkami), które mają omijać proxy.

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ą. Zmienne środowiskowe powłoki mają znaczenie tylko przy pierwszej instalacji: gdy Appliance jest już zainstalowany, pierwszeństwo ma jego zapisana konfiguracja (zobacz Późniejsza zmiana lub usunięcie proxy).

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.

Uwierzytelnianie w proxy

Jeśli twoje proxy wymaga logowania, nadaj Appliance własne konto usługi zamiast konta konkretnej osoby. Jego ruch pojawia się wtedy w logach proxy pod nazwą, którą kontroluje twój zespół sieciowy: może on ograniczyć, do czego to konto ma dostęp, a także je wyłączyć lub zmienić jego hasło bez ingerowania w czyjekolwiek osobiste dane logowania. To strona proxy zagadnienia opisanego w sekcji Tożsamość sieciowa hostów IronFlock.

Obsługiwane: uwierzytelnianie Basic. Umieść konto w adresie URL proxy — http://user:[email protected]:3128 — w poleceniu instalacyjnym albo w /opt/ironflock/.env, a następnie uruchom sudo ironflock-update. Znaki specjalne w haśle zakoduj w adresie URL (na przykład @ → %40).
Jeszcze nieobsługiwane: uwierzytelnianie zintegrowane z systemem Windows (Kerberos, NTLM). Jeśli twoje proxy nie akceptuje niczego innego, poproś zespół sieciowy o dopuszczenie konta usługi z uwierzytelnianiem Basic albo o wpuszczanie adresu Appliance bez uwierzytelniania jako nazwanego hosta.

Co przekazać zespołowi sieciowemu na temat ruchu:

Trafia on wyłącznie do punktów końcowych z listy w sekcji Konfiguracja zapory sieciowej, przez HTTPS na porcie 443. Przekaźnik e-mail na porcie 2525 nigdy nie korzysta z proxy.
Łącze zdalnego zarządzania z cbw.ironflock.com to długotrwałe połączenie WebSocket z ruchem keep-alive co kilka sekund. Jeśli proxy zrywa długotrwałe połączenia po określonym czasie, Appliance sam łączy się ponownie w ciągu kilku sekund, ale zdalni użytkownicy mogą za każdym razem zauważyć krótką przerwę — tam, gdzie to możliwe, wyłącz to połączenie z limitów czasu życia połączeń.

Późniejsza zmiana lub usunięcie proxy

Proxy jest zapisywane w centralnym pliku konfiguracyjnym Appliance, /opt/ironflock/.env. Ten plik jest autorytatywnym źródłem: to, co zawiera, jest tym, co stosuje każda aktualizacja. Rekonfiguracja proxy na zainstalowanym Appliance wymaga więc dwóch kroków:

Edytuj wpisy HTTP_PROXY, HTTPS_PROXY i NO_PROXY w /opt/ironflock/.env.
Uruchom sudo ironflock-update.

Aktualizacja ponownie stosuje ustawienia wszędzie w jednym przebiegu — w demonie Docker, usługach platformy, agencie urządzenia i tunelu zdalnego dostępu — restartując tylko to, co faktycznie się zmieniło.

Alternatywnie przekaż nowe wartości jako flagi — nadpisują one plik i są do niego z powrotem zapisywane:


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

Każde ustawienie jest niezależne: przekazanie samego --https-proxy pozostawia twoją istniejącą listę NO_PROXY nietkniętą (brakujący schemat HTTP jest odzwierciedlany automatycznie).

Aby usunąć proxy — na przykład po przeniesieniu Appliance do sieci z bezpośrednim dostępem do internetu — wyczyść wpisy w /opt/ironflock/.env (HTTP_PROXY=, HTTPS_PROXY=) lub przekaż jawnie puste flagi, a następnie uruchom aktualizację:


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

Konfiguracja proxy zostaje ponownie usunięta z demona Docker i agenta urządzenia, a Appliance wraca do połączeń bezpośrednich. Twoja lista NO_PROXY jest zachowywana na wypadek późniejszego ponownego włączenia.

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 — obejmuje ono połączenie z platformą oraz automatyczne aktualizacje agenta:


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

Które hosty omijają proxy

NO_PROXY działa na nazwę hosta, z którą łączy się klient, nigdy na adres, na który ta nazwa się rozwiązuje. Appliance, do którego urządzenie sięga po nazwie — czyli każdy appliance w trybie domeny, zobacz Interfejsy aplikacji i HTTPS — musi zatem zostać wymieniony wprost. W przeciwnym razie agent kieruje połączenie z lokalnym appliance przez firmowe proxy, a ponieważ większość proxy odmawia trasowania z powrotem do sieci wewnętrznej, urządzenie nigdy nie pojawia się online.

Instalator ustala to na podstawie własnego pliku .flock urządzenia. Obok localhost i 127.0.0.1 dodaje domenę appliance — zarówno w postaci zwykłej, jak i z kropką na początku — oraz każdy host rejestru, z którym łączy się bez TLS. Urządzenia chmurowe nie dostają nic poza dwoma wpisami loopback, ponieważ ich punkty końcowe są publiczne i proxy rzeczywiście jest im potrzebne.

Wszystko inne, czego wymaga Twoja instalacja, podajesz w -no-proxy, odpowiedniku flagi o tej samej nazwie w 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"

Późniejsza zmiana ustawień

Wynik zapisywany jest do %ProgramData%\IronFlock\Reagent\proxy.env i od tej chwili to ten plik jest rozstrzygający:


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

Zmodyfikuj go i uruchom ponownie reagent.exe service install, aby zastosować zmianę. Późniejsza instalacja nigdy nie nadpisuje tego pliku, a service uninstall zachowuje katalog agenta — Twoje ustawienia przetrwają więc cykl odinstalowania i instalacji, którego wymaga ponowna instalacja usługi. Użyj -force-proxy, aby celowo zastąpić plik wartościami z flag.

Usuń wpis, jeśli ta lokalizacja sięga do appliance przez proxy. Oba warianty występują naprawdę: appliance w tej samej sieci zakładowej jest osiągany bezpośrednio, natomiast hostowany centralnie bywa dostępny wyłącznie przez firmowe proxy. Instalator nie potrafi ich rozróżnić, dlatego zapisuje hosty dosłownie — usuń te, które nie dotyczą Twojej sieci.

Docker konfiguruje się osobno

Docker Desktop nie czyta ani proxy.env, ani środowiska usługi. Obrazy pobiera demon Dockera, który ma własne ustawienia w Settings → Resources → Proxies, wraz z własną listą wykluczeń — a ta również potrzebuje hosta appliance. Proxy poprawione po stronie agenta nie naprawia docker pull.

Urządzenia z Linuksem

ironflock-init przyjmuje --no-proxy bezpośrednio, więc appliance można wskazać już podczas instalacji:


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

Powstaje wtedy drop-in systemd w /etc/systemd/system/reagent.service.d/http-proxy.conf. Nie edytuj tego pliku, aby później zmienić ustawienia — narzędzie instalacyjne nadpisuje go. Zamiast tego użyj systemctl edit reagent: tworzy to plik override.conf, który systemd stosuje po drop-inie instalatora i którego IronFlock nigdy nie modyfikuje:


sudo systemctl edit reagent


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


sudo systemctl restart reagent

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 o dwie konkretne rzeczy:

Wyjątek od skanowania dla pobrań obrazów z instance-registry.ironflock.com, aby ogólna klasyfikacja jako riskware nie blokowała komponentu tunelu. To węższy zakres niż wyłączenie całego ruchu IronFlock z inspekcji TLS — pozostały ruch Appliance może nadal podlegać inspekcji.
Odnotowanie wykrycia jako znanego fałszywego alarmu. frp to powszechnie używane reverse proxy open source; IronFlock wykorzystuje je wyłącznie do opisanej powyżej funkcji zdalnego dostępu, chronionej systemem uprawnień.

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 w /opt/ironflock/.env i ponownie stosowane przy każdej aktualizacji. 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. Aby skierować Appliance na inne proxy — lub całkowicie odłączyć go od proxy — zobacz Późniejsza zmiana lub usunięcie proxy.

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.