Skip to Content

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.com i regauth.ironflock.com są potrzebne do synchronizacji aplikacji z publicznego IronFlock Store do lokalnego App Store. registry.ironflock.com udostępnia obrazy aplikacji, a regauth.ironflock.com wystawia 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.com przebiega 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 port 443, tak jak wszystko inne, bezpośrednio lub przez firmowe proxy; tylko Appliance zainstalowany z IRONFLOCK_CLOUD_TUNNEL_TCP=1 używa zamiast niego portu 7000. 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.com jest 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.com i cdn.jsdelivr.net, a wyszukiwanie adresów dla lokalizacji urządzeń korzysta z nominatim.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 123 do 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 15002 obsł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 z https://registry.<APPLIANCE_DOMAIN>/dl przez port 443. 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:

HostTożsamość do użycia w regule
Urządzenie brzegowe z systemem Windows dołączone do twojej domenyJego konto komputera — obiekt komputera lub grupa, np. Urządzenia brzegowe IronFlock
Każde inne urządzenie brzegowe (Linux, FlockOS, Windows spoza domeny) oraz ApplianceNazwany 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 uwierzytelnianiaDedykowane 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.

Last updated on