Rede e firewall

Configuração de firewall

Se o appliance roda em uma rede local restrita, libere o acesso de saída aos seguintes endpoints da IronFlock para que ele consiga alcançar a nuvem. Todas as conexões são iniciadas pelo appliance — nenhuma porta de entrada precisa ser aberta no seu firewall.

instance-registry.ironflock.com:443   # baixar e atualizar o software IronFlock e os agentes; o assistente de IA e as notificações por SMS
cbw.ironflock.com:443                 # gerenciar o appliance remotamente a partir da nuvem
web.ironflock.com:443                 # ativar e validar a licença
registry.ironflock.com:443            # baixar imagens de apps ao sincronizar da IronFlock Store pública
regauth.ironflock.com:443             # autenticar esses downloads de imagens da Store pública
app.ironflock.com:443                 # abrir as interfaces de usuário de apps e dispositivos a partir da nuvem (opcional)
smtp-proxy.ironflock.com:2525         # enviar e-mails de conta e notificações (opcional)

As entradas registry.ironflock.com e regauth.ironflock.com são necessárias para sincronizar apps da IronFlock Store pública para a local App Store. O registry.ironflock.com serve as imagens dos apps e o regauth.ironflock.com emite o token que autoriza cada download — ambos precisam estar acessíveis, ou a sincronização (e a navegação/instalação remota de apps) falha. Se o seu appliance só serve apps que você mesmo cria localmente, pode omiti-las. Um app cujas imagens vêm de um registro público, como o Docker Hub, é copiado desse registro durante a sincronização, então o appliance também precisa alcançá-lo.

A entrada app.ironflock.com transporta o túnel de acesso remoto que torna as interfaces de usuário de apps e dispositivos acessíveis enquanto você trabalha na instância a partir do ironflock.com. Ele funciona pela porta 443 como todo o resto, diretamente ou através de um proxy corporativo; somente um appliance instalado com IRONFLOCK_CLOUD_TUNNEL_TCP=1 usa a porta 7000 em vez dela. Se a entrada estiver bloqueada, nada falha de forma visível — essas interfaces simplesmente não abrem a partir da nuvem, mas continuam funcionando na rede local. Se você só usa o appliance localmente, pode omiti-la.

A entrada smtp-proxy.ironflock.com só é necessária se você usar o relay de e-mail integrado da IronFlock. Se você configurar o seu próprio servidor SMTP, pode omiti-la.

Destinos opcionais. O assistente de IA atualiza os metadados de modelos e widgets a partir de raw.githubusercontent.com e cdn.jsdelivr.net, e a busca de endereços para a localização dos dispositivos usa nominatim.openstreetmap.org. Os três são opcionais: se estiverem bloqueados, o assistente recorre aos seus dados integrados e a busca de endereços fica indisponível.

A sincronização de horário não está nesta lista porque não vai para a IronFlock: mesmo assim, o appliance precisa de uma fonte de horário funcional. Libere o UDP 123 de saída para os seus servidores de horário, ou configure o seu servidor de horário interno no host — veja Sincronização de horário (NTP).

Se a sua rede só alcança a internet através de um proxy HTTP corporativo, veja Atrás de um Proxy Corporativo — o instalador pode apontar o daemon do Docker para o seu proxy automaticamente.

Dispositivos conectando-se ao appliance

Dispositivos de borda conectam-se ao appliance, não à nuvem. Se os dispositivos estiverem em um segmento de rede diferente do appliance, libere as redes dos dispositivos para alcançarem o host do appliance nestas portas:

<APPLIANCE_HOST>:18080   # conexão do dispositivo (WebSocket) — obrigatório
<APPLIANCE_HOST>:15001   # registro da local App Store (downloads de imagens de apps) — obrigatório
<APPLIANCE_HOST>:15002   # autenticação do registro (tokens de download de imagens), atualizações do agente de dispositivo e instalador de dispositivos — obrigatório
<APPLIANCE_HOST>:7000    # acesso remoto às UIs dos dispositivos (recurso de túnel opcional)

Estas são conexões diretas — não devem ser roteadas através de um proxy HTTP corporativo. Se a rede de um dispositivo força todo o tráfego através de um proxy, isente o host do appliance do proxy no dispositivo, ou mude o appliance para HTTPS com o seu certificado corporativo: nesse modo, todo o tráfego dos dispositivos — a conexão do dispositivo, os downloads de imagens, as atualizações do agente e o túnel de acesso remoto — passa para uma única porta compatível com proxy: 443 no seu domínio, e funciona através de proxies corporativos e firewalls restritos sem exceções por porta.

A porta 15002 também serve as atualizações do agente de dispositivo e o instalador de dispositivos: os dispositivos conectados ao appliance baixam as atualizações do agente — e os dispositivos novos, o instalador — do próprio appliance, nunca da internet; no modo domínio, em vez disso, de https://registry.<APPLIANCE_DOMAIN>/dl pela porta 443. Veja Atualizações do agente de dispositivo e Registrar dispositivos sem acesso à internet.

Os dispositivos não precisam de acesso à internet para a operação normal. Tudo o que um dispositivo conectado ao appliance faz — a conexão do dispositivo, as imagens de apps, as atualizações do agente, o acesso remoto — vai para o appliance. Um dispositivo só acessa a internet quando constrói um app a partir de um Dockerfile cuja imagem base está em um registro público, quando você publica um app que usa imagens públicas, quando o próprio Docker ainda precisa ser instalado e — em dispositivos com FlockOS — para verificar atualizações do sistema operacional em instance-registry.ironflock.com. Os apps que você implanta podem ter necessidades de rede próprias.

Identidade de rede para hosts do IronFlock

O appliance e cada dispositivo de borda executam o IronFlock como um serviço do sistema sem supervisão: ele inicia com o boot e permanece conectado o tempo todo, haja ou não alguém com sessão iniciada. Por isso, as regras de firewall e de proxy para esses hosts precisam estar vinculadas à máquina — nunca à pessoa que por acaso tenha uma sessão iniciada nela. Para os dispositivos de borda, isso vale seja qual for a plataforma à qual se conectam; o guia de dispositivos trata do assunto em Firewalls e Proxies com Reconhecimento de Identidade.

Isso importa sobretudo em redes com um firewall ou proxy com reconhecimento de identidade (identity-aware), que concede acesso pela identidade no diretório em vez de pelo endereço. Se a regra que libera um host IronFlock estiver vinculada a um usuário, o host perde o acesso sempre que a sessão desse usuário expira. As conexões já abertas continuam funcionando enquanto cada conexão nova é descartada silenciosamente, de modo que o host parece saudável até precisar se conectar de novo — aí falham a instalação de um app, uma atualização do agente ou uma reconexão, e após o próximo reinício o dispositivo permanece offline.

Não é necessária nenhuma isenção da aplicação de políticas por identidade. Peça à sua equipe de rede que identifique cada host pela identidade que ele realmente tem:

Como isso se traduz nos produtos mais comuns:

• Check Point Identity Awareness: na Access Role, selecione a máquina (objeto de computador ou grupo) em vez de usuários. As identidades de máquina são renovadas pela própria atividade do computador no domínio; se elas puderem expirar no seu gateway, use um objeto de rede em vez disso.
• Palo Alto Networks User-ID: contas de computador não geram mapeamentos de IP para usuário, então use um objeto de endereço, uma tag ou o Device-ID.
• Fortinet FSSO e firewalls semelhantes baseados em diretório: use um objeto de endereço para o host, ou o endereço dinâmico atribuído pelo seu controle de acesso à rede.
• Zscaler, Prisma Access e outros gateways de segurança em nuvem: registre o endereço do appliance como um local de servidor ou de IoT (uma origem confiável), para que o tráfego dele seja identificado pelo local e não pelo usuário.

Como reconhecer a falha. Um dispositivo que continua online, mas falha em toda conexão nova — downloads de imagens, logins no registro, reconexões —, enquanto os pings e a sessão já existente continuam funcionando, indica uma regra de identidade expirada, e não um problema no dispositivo. Não reinicie o agente até que uma conexão nova a partir do dispositivo volte a ter sucesso: a sessão que ainda está aberta é a única que funciona.

Acesse sua instância pelo ironflock.com

Mesmo sendo uma plataforma totalmente local, o appliance não exige que você esteja na rede da fábrica para utilizá-lo. Desde que o appliance tenha conexão à internet e sua conta do appliance esteja conectada à sua conta no ironflock.com (veja Vinculando contas), você pode entrar na sua instância diretamente pela UI cloud do IronFlock — sem VPN, sem redirecionamento de portas, sem ferramentas adicionais.

Isso significa:

• Uma UI unificada — gerencie seus projetos na nuvem e suas instâncias de appliance lado a lado em uma única aba do navegador.
• Trabalhe de qualquer lugar — operadores, desenvolvedores e equipe de suporte podem acessar o appliance pela internet, enquanto todos os dados de produção e workloads permanecem locais no appliance.
• Visão multi-site simplificada — se você opera vários appliances em fábricas diferentes, cada um aparece em sua conta do ironflock.com e está a um clique de distância.

Quando o appliance perde acesso à internet, ele continua rodando localmente e permanece acessível de dentro da rede da fábrica em http://<appliance-host> — apenas o caminho de acesso remoto fica pausado até a conectividade voltar.