Configure os Sentinel Gateways

Leve suas filiais e data centers ao Infrastructure Defense sem depender do link de internet. Um Sentinel Gateway é um appliance que faz o relay dos agentes até a nuvem, guarda em cache releases de agente e conteúdo de patch verificados antes da janela de manutenção, atende os gerenciadores de pacote do Linux, controla a banda por horário e pode ficar atrás de outro gateway. Este guia explica o que ele é, como instalar, atribuir e aninhar, e como ler o que ele economizou.

O agente Sentinel Host mostra o interior de cada servidor, e o Sentinel Probe mostra a rede ao redor deles. Os dois reportam à nuvem da WASViking^® pela internet, e o mesmo vale para cada patch que uma janela de manutenção instala. Em um site com link fino, política de saída restrita ou centenas de hosts puxando a mesma atualização cumulativa, esse link é o gargalo. O Sentinel Gateway é o terceiro componente do Infrastructure Defense e tira essa dependência do caminho: um appliance por site, e o site fala com a internet uma vez só.

Os hosts discam para o gateway do seu site. Um gateway de filial pode ficar atrás de um gateway de data center, e só esse alcança a internet. Nada termina o canal com a nuvem.

O que é um Sentinel Gateway

Um Sentinel Gateway é um único programa em uma máquina Ubuntu Server dentro da sua rede. Ele se registra com uma chave de ativação, como um probe, e a partir daí atende os Sentinel Hosts dos sites que você atribui a ele de quatro maneiras, cada uma um papel que você liga pelo portal:

• Relay. Agentes sem rota para a internet discam para o gateway em vez da nuvem. O gateway encaminha a conexão pelo nome do servidor e nunca a abre: o canal de TLS mútuo entre o agente e a nuvem continua de ponta a ponta, e o agente segue verificando o certificado da própria nuvem. Um host em uma VLAN isolada se registra, reporta e executa jobs por ele.
• Cache. As releases do agente são baixadas uma vez e servidas a todos os hosts do site a partir de um repositório endereçado por conteúdo, verificadas pelo checksum que a nuvem fixou e pela assinatura da release.
• Distribuição de patch. Quando um job do Resolve é aprovado, a nuvem diz ao gateway quais arquivos a janela vai precisar, e o gateway os traz antes da hora: atualizações cumulativas do Windows, instaladores de terceiros vindos dos manifestos públicos de pacotes, pacotes do macOS e os instaladores que você mesmo envia. Cada arquivo é verificado contra a assinatura do fabricante e as raízes confiáveis antes que um host possa recebê-lo, e o host o verifica de novo antes de instalar.
• Cache de repositório. Os hosts Linux do site rodam apt e dnf pelo gateway durante um job, então o segundo host que instala o mesmo pacote o encontra na LAN. Os índices de repositório são revalidados, e os arquivos de pacote ficam guardados enquanto a cota permitir.

Todo listener que o gateway abre usa TLS mútuo com o certificado que a plataforma emitiu no registro, e ele só atende agentes da sua própria organização: um gateway de um cliente nunca responde a outro em uma rede compartilhada.

O que ele não faz

O gateway distribui conteúdo que pode ser verificado. As atualizações de sistema operacional do macOS continuam vindo do canal do próprio fabricante. Repositórios HTTPS são encaminhados para os gerenciadores de pacote, não guardados em cache. Um instalador em imagem de disco não pode ser verificado fora da plataforma a que se destina, então um aplicativo do macOS chega como pacote assinado ou continua um passo manual. A tela Patches diz, por atualização, se ela vai chegar pelo gateway, pelo canal de pacotes no host ou se precisa que você a obtenha.

Antes de começar

O Infrastructure Defense é habilitado por organização pelo seu contato ou parceiro WASViking. Configurar um gateway exige a permissão Manage no módulo. Você vai precisar de:

• Uma máquina com Ubuntu Server 22.04 LTS ou 24.04 LTS, com 4 vCPU e 16 GB de memória para um site de algumas centenas de hosts.
• Um disco para o repositório de conteúdo, em um ponto de montagem próprio, para que um cache cheio nunca lote o disco do sistema operacional. Planeje 150 GB para um site que aplica patches em servidores Windows; a cota é você quem define.
• Saída HTTPS do gateway para a nuvem da WASViking, o bucket de releases e os domínios de fabricantes que a política permite. Nada mais sai do site por ele.
• Entrada dos hosts do site para o gateway nas portas TCP 8443 (conteúdo) e 8444 (relay). As duas portas são configuráveis.

Passo 1: crie uma chave de ativação

Abra Infrastructure Defense → Sentinel Gateways na barra lateral do portal e vá para a aba Activation keys. Crie uma chave com um título que sua equipe reconheça, opcionalmente limite quantos gateways ela pode registrar e guarde o valor para o comando de instalação. A página Install da chave traz os downloads do pacote e o comando exato.

Passo 2: instale o gateway

Na máquina Ubuntu Server, instale o pacote e registre com um comando cada:

sudo apt install ./wasviking-sentinel-gateway_<version>_amd64.deb
sudo wasviking-sentinel-gateway install --activation-key <your-activation-key> --store /srv/wasviking/store

O instalador cria um usuário de serviço sem privilégios, registra o caminho do repositório, inscreve o appliance sob sua própria identidade de certificado e inicia o serviço. Em até um minuto o gateway aparece como Online na aba Gateways, com CPU, memória, disco do repositório, IOPS, latência e tráfego de rede. Rode sudo wasviking-sentinel-gateway check na máquina sempre que quiser a visão do próprio appliance: o caminho até a nuvem, o ponto de montagem do repositório e sua folga, as portas dos listeners, o certificado.

Passo 3: ligue os papéis

Abra a página do gateway e use o formulário da aba Policy. Marque Relay para deixar os agentes discarem para a nuvem por ele, Cache para servir releases do agente, Patch distribution para preparar o conteúdo dos jobs aprovados e Repository cache para atender apt e dnf. Os dois últimos precisam do cache, e o formulário o habilita para você. Defina o Address agents dial quando os hosts devem usar um nome DNS ou um endereço diferente do primeiro que o appliance reportou: ele entra no certificado que a nuvem emite. O appliance adota a mudança no próximo heartbeat, e a página mostra a política como aplicada quando ele responde.

Passo 4: atribua os sites que ele atende

Um site é um grupo de redes: um nome, um ou mais CIDRs, a lista ordenada de gateways que o atendem, se seus hosts ainda podem discar direto para a nuvem e se o proxy do gerenciador de pacotes permanece entre um job e outro. Crie um na aba Sites e adicione o gateway a ele. Todo host cujo endereço cai dentro das redes do site é mapeado a ele no próximo inventário e recebe a lista de gateways no próximo heartbeat; um host que você quer em outro lugar pode ser fixado a um site na página do ativo. A partir daí o agente disca para os gateways do seu site em ordem de prioridade, permanece no que respondeu e cai para o próximo em caso de falha, e a página do host mostra a que site ele pertence.

Um host instalado em uma rede sem rota de saída se registra pelo gateway desde o primeiro minuto:

sudo wasviking-sentinel-host install --activation-key <host-key> --gateway 10.20.0.6

A nuvem substitui essa entrada manual pela lista do site assim que o host é mapeado.

Passo 5: controle a banda

A página do gateway tem uma aba Bandwidth: uma lista ordenada de janelas (dias, início, fim) com a taxa de download da internet, a taxa de entrega para a LAN e o número de downloads simultâneos dentro de cada uma, mais um padrão fora delas. Um formato comum é 50 Mbps de download no horário comercial e sem limite à noite. O prefetch respeita isso: quando um job é aprovado, o gateway baixa o conteúdo sob a política em ordem de prazo, e a tela Resolve mostra Content staged N of M para o job conforme os arquivos chegam. Um job cujo conteúdo não ficou pronto a tempo roda mesmo assim; o host então baixa o que falta do jeito de sempre.

Passo 6: entregue a ele o que ele não consegue baixar sozinho

Alguns instaladores não são publicados onde um gateway consegue buscar. A aba Installer uploads os recebe de você: escolha a plataforma, nomeie o aplicativo como o inventário o lista, informe a versão e a arquitetura, escolha o tipo de instalador e as opções silenciosas, e envie o arquivo pelo navegador. Para um pacote do macOS você pode fixar o Team ID do desenvolvedor. A plataforma fixa o hash do arquivo, um gateway baixa e verifica a assinatura, e a linha mostra Verified by com o assinante ou Rejected com o motivo. A partir daí a tela Patches classifica essa atualização como Automatic, via gateway com a origem From your upload, e o próximo job a instala a partir do conteúdo do gateway.

Passo 7: aninhe uma filial atrás do data center

Uma filial muitas vezes não tem caminho próprio para a internet, só um link com o data center. Instale um gateway na filial e, na página dele, escolha o gateway do data center como Upstream gateway. O appliance da filial passa a alcançar a nuvem pelo relay do data center, pede ao data center cada objeto antes de ir à internet e envia as faltas do gerenciador de pacotes pelo cache de repositório do próprio data center. O gateway do data center também prepara o conteúdo dos sites da filial, então a janela da filial começa aquecida. Um appliance de filial instalado sem rota nenhuma se registra pelo gateway do data center com uma opção:

sudo wasviking-sentinel-gateway install --activation-key <your-activation-key> --store /srv/wasviking/store --upstream 10.20.0.6

O portal recusa um ciclo, e cada arquivo é verificado na filial tanto quanto no data center: o aninhamento nunca confia em bytes que a filial não conferiu por conta própria. A página do gateway mostra a cadeia (este gateway, depois o upstream, depois a nuvem), os gateways aninhados atrás dele e quanto veio pelo upstream em vez da internet.

Lendo os números

A aba Gateways abre com a frota: gateways, sua saúde, agentes conectados, tamanho do cache e taxa de acerto, e os últimos trinta dias de Bandwidth saved, Served locally e Patch files served. A página de um gateway mantém no topo a saúde, o uptime, o disco do repositório e a taxa de acerto, e divide o restante em abas: Performance traz os recursos com IOPS e latência do disco do repositório e os gráficos de doze horas, vinte e quatro horas e sete dias, Serving as requisições do cache e do cache de repositório, Patch content o conteúdo que ele guarda com o assinante de cada arquivo, e Bandwidth a política de banda. Os mesmos totais de trinta dias aparecem na aba Infrastructure Defense do seu perfil de conta e na seção Content delivery do relatório em PDF do Infrastructure Defense, então o número que você mostra à gestão é o número que os appliances mediram.

Dia dois

A plataforma dispara um alerta quando um gateway fica offline, quando o disco do repositório, a CPU ou a memória sobem demais, quando a versão fica para trás, quando o certificado se aproxima do vencimento, quando um arquivo falha na verificação ou quando o prefetch está atrasado em relação ao prazo de uma janela; cada alerta se resolve sozinho no próximo heartbeat saudável.

Você gerencia esses alertas na aba Monitoring alerts. Cada condição tem uma regra que pode ser desligada e, quando depende de um número, o limiar dentro da própria frase: as marcas de disco do repositório, memória, CPU e latência de disco com o tempo que precisam se manter, capacidade de conexões, quanto tempo sem heartbeat significa offline e quão perto do vencimento um certificado merece uma mensagem. Os limiares decidem quando uma leitura vira uma condição, então a saúde na aba Gateways os acompanha; uma regra desligada só interrompe a mensagem. Na mesma aba você escolhe quem é avisado: inscreva os canais de notificação da sua organização (e-mail, Slack, Microsoft Teams, HTTP API) no evento Sentinel Gateway Monitoring, adicione até dez destinatários extras para quem só quer o e-mail dos appliances e envie um teste que segue o mesmo caminho de um alerta real. Um gateway em manutenção pode ser silenciado por uma hora, quatro horas, um dia, uma semana ou até você retomar: as condições continuam registradas e nenhuma mensagem é enviada.

Um gateway aparece como offline nas telas no momento em que o serviço para. O alerta de offline espera a janela de offline, tanto quando o gateway sumiu quanto quando foi parado de propósito, então um restart ou uma atualização que volta em segundos nunca envia mensagem, e um gateway que continua parado sempre envia. Um gateway desativado no portal não gera alerta.

A aba Operations da página do gateway oferece as ações rápidas: atualizar a política, coletar os logs, reiniciar, atualizar para a release estável, rotacionar o certificado. Na máquina, status imprime o que o serviço reportou por último e check testa o caminho até a nuvem e, em um appliance aninhado, o gateway upstream.

O que ver a seguir

• Configure o Infrastructure Defense para o agente de host que o gateway atende.
• Configure os Sentinel Probes para a visão de rede dos mesmos sites.
• Infrastructure Defense para entender como o score, o Resolve e os relatórios se encaixam.