Sieć i zapora sieciowa
Konfiguracja zapory sieciowej
Jeśli Appliance działa w ograniczonej sieci lokalnej, zezwól na wychodzący dostęp do poniższych punktów końcowych IronFlock, aby mógł połączyć się z chmurą. Wszystkie połączenia są inicjowane przez Appliance — w twojej zaporze nie trzeba otwierać żadnych portów przychodzących.
instance-registry.ironflock.com:443 # pobieranie i aktualizacja oprogramowania IronFlock oraz agentów; asystent AI i powiadomienia SMS
cbw.ironflock.com:443 # zdalne zarządzanie Appliance z chmury
web.ironflock.com:443 # aktywacja i weryfikacja licencji
registry.ironflock.com:443 # pobieranie obrazów aplikacji podczas synchronizacji z publicznego IronFlock Store
regauth.ironflock.com:443 # uwierzytelnianie tych pobrań obrazów z publicznego Store
app.ironflock.com:443 # otwieranie interfejsów użytkownika aplikacji i urządzeń z chmury (opcjonalne)
smtp-proxy.ironflock.com:2525 # wysyłanie e-maili kont i powiadomień (opcjonalne)Wpisy
registry.ironflock.comiregauth.ironflock.comsą potrzebne do synchronizacji aplikacji z publicznego IronFlock Store do lokalnego App Store.registry.ironflock.comudostępnia obrazy aplikacji, aregauth.ironflock.comwystawia token autoryzujący każde pobranie — oba muszą być osiągalne, w przeciwnym razie synchronizacja (oraz zdalne przeglądanie i instalowanie aplikacji) zawiedzie. Jeśli twój Appliance obsługuje wyłącznie aplikacje, które budujesz lokalnie, możesz je pominąć. Aplikacja, której obrazy pochodzą z publicznego rejestru, takiego jak Docker Hub, jest podczas synchronizacji kopiowana z tego rejestru, więc Appliance musi mieć dostęp również do niego.
Przez wpis
app.ironflock.comprzebiega tunel zdalnego dostępu, który udostępnia interfejsy użytkownika aplikacji i urządzeń, gdy pracujesz na instancji przez ironflock.com. Działa on przez port443, tak jak wszystko inne, bezpośrednio lub przez firmowe proxy; tylko Appliance zainstalowany zIRONFLOCK_CLOUD_TUNNEL_TCP=1używa zamiast niego portu7000. Jeśli ten wpis jest zablokowany, nic nie zgłasza błędu — te interfejsy po prostu nie otwierają się z chmury, choć w sieci lokalnej nadal działają. Jeśli używasz Appliance wyłącznie lokalnie, możesz go pominąć.
Wpis
smtp-proxy.ironflock.comjest potrzebny tylko wtedy, gdy korzystasz z wbudowanego przekaźnika e-mail IronFlock. Jeśli skonfigurujesz własny serwer SMTP, możesz go pominąć.
Opcjonalne miejsca docelowe. Asystent AI odświeża metadane modeli i widgetów z
raw.githubusercontent.comicdn.jsdelivr.net, a wyszukiwanie adresów dla lokalizacji urządzeń korzysta znominatim.openstreetmap.org. Wszystkie trzy są opcjonalne: jeśli są zablokowane, asystent korzysta z wbudowanych danych, a wyszukiwanie adresów jest niedostępne.
Synchronizacja czasu nie znajduje się na tej liście, ponieważ nie prowadzi do IronFlock: appliance i tak potrzebuje działającego źródła czasu. Zezwól na wychodzący ruch UDP
123do swoich serwerów czasu albo skonfiguruj na hoście wewnętrzny serwer czasu — zobacz Synchronizacja czasu (NTP).
Jeśli twoja sieć dociera do internetu wyłącznie przez firmowe proxy HTTP, zobacz Za firmowym proxy — instalator może automatycznie skierować demona Docker na twoje proxy.
Urządzenia łączące się z Appliance
Urządzenia brzegowe łączą się z Appliance, a nie z chmurą. Jeśli urządzenia znajdują się w innym segmencie sieci niż Appliance, zezwól sieciom urządzeń na dostęp do hosta Appliance na następujących portach:
<APPLIANCE_HOST>:18080 # łącze urządzenia (WebSocket) — wymagane
<APPLIANCE_HOST>:15001 # rejestr local App Store (pobieranie obrazów aplikacji) — wymagane
<APPLIANCE_HOST>:15002 # uwierzytelnianie rejestru (tokeny pobierania obrazów), aktualizacje agenta urządzeń oraz instalator urządzeń — wymagane
<APPLIANCE_HOST>:7000 # zdalny dostęp do interfejsów urządzeń (opcjonalna funkcja tunelu)To są bezpośrednie połączenia — nie mogą być kierowane przez firmowe proxy HTTP. Jeśli sieć urządzenia wymusza kierowanie całego ruchu przez proxy, albo wyłącz host Appliance z proxy na urządzeniu, albo przełącz Appliance na HTTPS z twoim firmowym certyfikatem: w tym trybie cały ruch urządzeń — łącze urządzenia, pobieranie obrazów, aktualizacje agenta oraz tunel zdalnego dostępu — przenosi się na jeden, przyjazny dla proxy port: 443 w twojej domenie i działa przez firmowe proxy oraz restrykcyjne zapory bez wyjątków dla poszczególnych portów.
Port
15002obsługuje także aktualizacje agenta urządzeń i instalator urządzeń: urządzenia podłączone do Appliance pobierają aktualizacje agenta — a nowe urządzenia instalator — z samego Appliance, nigdy z internetu; w trybie domenowym zamiast tego zhttps://registry.<APPLIANCE_DOMAIN>/dlprzez port443. Zobacz Aktualizacje agenta urządzeń oraz Rejestrowanie urządzeń bez dostępu do internetu.
Do normalnej pracy urządzenia nie potrzebują dostępu do internetu. Wszystko, co robi podłączone urządzenie — łącze urządzenia, obrazy aplikacji, aktualizacje agenta, zdalny dostęp — trafia do Appliance. Urządzenie łączy się z internetem tylko wtedy, gdy buduje aplikację z pliku Dockerfile, którego obraz bazowy znajduje się w publicznym rejestrze, gdy publikujesz aplikację korzystającą z publicznych obrazów, gdy trzeba jeszcze zainstalować sam Docker oraz — na urządzeniach z FlockOS — aby sprawdzić dostępność aktualizacji systemu operacyjnego pod
instance-registry.ironflock.com. Wdrażane przez ciebie aplikacje mogą mieć własne wymagania sieciowe.
Tożsamość sieciowa hostów IronFlock
Appliance i każde urządzenie brzegowe uruchamiają IronFlock jako bezobsługową usługę systemową: startuje ona wraz z systemem i utrzymuje połączenie przez całą dobę, niezależnie od tego, czy ktoś jest zalogowany. Reguły zapory i proxy dla tych hostów muszą więc być powiązane z maszyną — nigdy z osobą, która akurat jest na niej zalogowana. Dla urządzeń brzegowych obowiązuje to bez względu na to, z jaką platformą się łączą; przewodnik po urządzeniach omawia ten temat w sekcji Zapory i proxy świadome tożsamości.
Ma to największe znaczenie w sieciach z zaporą lub proxy świadomymi tożsamości (identity-aware), które przyznają dostęp na podstawie tożsamości z katalogu, a nie adresu. Jeśli reguła dopuszczająca host IronFlock jest powiązana z użytkownikiem, host traci dostęp za każdym razem, gdy sesja tego użytkownika wygaśnie. Już otwarte połączenia działają dalej, a każde nowe jest po cichu odrzucane, więc host wygląda na sprawny aż do chwili, gdy musi nawiązać połączenie — wtedy zawodzi instalacja aplikacji, aktualizacja agenta lub ponowne połączenie, a po najbliższym restarcie urządzenie pozostaje offline.
Wyłączenie z egzekwowania tożsamości nie jest potrzebne. Poproś zespół sieciowy, aby identyfikował każdy host na podstawie tożsamości, którą ten faktycznie posiada:
| Host | Tożsamość do użycia w regule |
|---|---|
| Urządzenie brzegowe z systemem Windows dołączone do twojej domeny | Jego konto komputera — obiekt komputera lub grupa, np. Urządzenia brzegowe IronFlock |
| Każde inne urządzenie brzegowe (Linux, FlockOS, Windows spoza domeny) oraz Appliance | Nazwany obiekt hosta z zarezerwowanym adresem IP albo tożsamość przypisywana przez twoją kontrolę dostępu do sieci (802.1X lub uwierzytelnianie MAC) |
| Dostęp Appliance do internetu przez proxy wymagające uwierzytelniania | Dedykowane konto usługi dla Appliance — zobacz Uwierzytelnianie w proxy |
Jak to wygląda w popularnych produktach:
- Check Point Identity Awareness: w Access Role wybierz maszynę (obiekt komputera lub grupę) zamiast użytkowników. Tożsamości maszyn są odświeżane dzięki aktywności samego komputera w domenie; jeśli na twojej bramie mogą one wygasać, użyj zamiast tego obiektu sieciowego.
- Palo Alto Networks User-ID: konta komputerów nie tworzą mapowań IP–użytkownik, więc użyj obiektu adresu, tagu lub Device-ID.
- Fortinet FSSO i podobne zapory oparte na katalogu: użyj obiektu adresu dla hosta albo adresu dynamicznego przypisywanego przez twoją kontrolę dostępu do sieci.
- Zscaler, Prisma Access i inne chmurowe bramy bezpieczeństwa: zarejestruj adres Appliance jako lokalizację typu serwer lub IoT (zaufane źródło), aby jego ruch był identyfikowany na podstawie lokalizacji, a nie użytkownika.
Jak rozpoznać ten błąd. Jeśli urządzenie pozostaje online, ale zawodzi każde jego nowe połączenie — pobieranie obrazów, logowanie do rejestru, ponowne łączenie — podczas gdy ping i istniejąca sesja nadal działają, przyczyną jest wygasła reguła tożsamości, a nie samo urządzenie. Nie restartuj agenta, dopóki nowe połączenie z urządzenia znów nie zakończy się powodzeniem: wciąż otwarta sesja jest jedyną, która działa.
Dostęp do twojej instancji przez ironflock.com
Mimo że Appliance jest w pełni lokalną platformą, nie musisz znajdować się w sieci fabryki, aby z niego korzystać. Dopóki Appliance ma połączenie z internetem, a twoje konto Appliance jest połączone z kontem na ironflock.com (zobacz Powiązanie kont), możesz przejść do swojej instancji bezpośrednio z chmurowego UI IronFlock — bez VPN, bez przekierowania portów, bez dodatkowych narzędzi.
Oznacza to:
- Jeden ujednolicony interfejs — zarządzaj projektami w chmurze i instancjami Appliance obok siebie z jednej karty przeglądarki.
- Praca z dowolnego miejsca — operatorzy, deweloperzy i wsparcie techniczne mogą dotrzeć do Appliance przez internet, podczas gdy wszystkie dane produkcyjne i workloady pozostają lokalnie na Appliance.
- Łatwy nadzór nad wieloma lokalizacjami — jeśli prowadzisz kilka Appliance w różnych fabrykach, każdy pojawia się na twoim koncie ironflock.com i jest oddalony o jedno kliknięcie.
Gdy Appliance utraci dostęp do internetu, nadal działa lokalnie i pozostaje dostępny z poziomu sieci fabryki pod adresem http://<appliance-host> — jedynie ścieżka zdalnego dostępu jest wstrzymana do czasu przywrócenia łączności.