👨🏻‍💻 🙆🏼 😗 Consul + iptables =: 3 🤵🏿 🕗 ❗️

Em 2010, a Wargaming tinha 50 servidores e um modelo de rede simples: back-end, front-end e firewall. O número de servidores aumentou, o modelo ficou mais complicado: VLANs temporárias e isoladas com ACLs, depois VPNs com VRF, VLANs com ACLs para L2, VRFs de ACLs para L3. Cabeça está girando? Mais será mais divertido.

Quando os servidores começaram a trabalhar 16.000 sem lágrimas com tantos segmentos heterogêneos, tornou-se impossível. Portanto, eles criaram uma solução diferente. Pegamos a pilha do Netfilter, adicionamos o Consul como fonte de dados e obtivemos um firewall distribuído rapidamente. Eles substituíram a ACL nos roteadores e usados como um firewall externo e interno. Para o gerenciamento dinâmico de ferramentas, desenvolvemos o sistema BEFW, que era usado em todos os lugares: desde o controle do acesso do usuário à rede de supermercados até o isolamento dos segmentos de rede.

Como tudo funciona e por que você deve examinar mais de perto esse sistema, diz Ivan Agarkov (annmuor) - o chefe do grupo de segurança de infraestrutura da unidade de Manutenção no centro de desenvolvimento da empresa de Minsk. Ivan é um fã do SELinux, ama Perl, escreve código. Como chefe do grupo IB, ele trabalha regularmente com logs, backups e P&D para proteger a Wargaming de hackers e garantir a operação de todos os servidores de jogos da empresa.

Referência histórica

Antes de contar como fizemos, vou contar como chegamos a isso e por que era necessário. Para fazer isso, transferimos 9 anos atrás: 2010, apenas o World of Tanks apareceu. A Wargaming tinha aproximadamente 50 servidores.

Gráfico de crescimento dos servidores da empresa.

Tivemos um modelo de rede. Durante esse tempo, foi ótimo.

O modelo de rede em 2010.

No front-end, existem bandidos que querem nos quebrar, mas há um firewall nele. Não há firewall no back-end, mas existem 50 servidores lá, todos nós os conhecemos. Tudo funciona bem.

Ao longo de 4 anos, a frota de servidores cresceu 100 vezes, até 5000. As primeiras redes isoladas apareceram - parando: elas não podem entrar em produção e, muitas vezes, coisas perigosas estavam girando lá.

Modelo de rede em 2014.

Por inércia, todas as mesmas peças de ferro foram usadas e todo o trabalho foi realizado em VLANs isoladas: as ACLs são gravadas na VLAN que permitem ou proíbem qualquer conexão.

Em 2016, o número de servidores chegou a 8000. A Wargaming absorveu outros estúdios, surgiram redes afiliadas adicionais. Eles parecem ser nossos, mas não exatamente: a VLAN geralmente não funciona para parceiros, você precisa usar uma VPN com VRF, o isolamento se torna mais complicado. Uma mistura de isolados de LCA cresceu.

O modelo de rede em 2016.

No início de 2018, a frota de carros cresceu para 16.000. Havia 6 segmentos e o restante não contabilizamos, incluindo os fechados, nos quais os dados financeiros eram armazenados. Existem redes de contêiner (Kubernetes), DevOps, redes em nuvem conectadas via VPN, por exemplo, a partir do IVS. Havia muitas regras - doía.

Modelo de rede e métodos de isolamento em 2018.

Para isolamento, usamos: VLAN com ACL em L2, VRF com ACL em L3, VPN e muito mais. Demais.

Problemas

Todo mundo vive com ACLs e VLANs. O que geralmente está errado? Harold, escondendo a dor, responderá a essa pergunta.

Havia muitos problemas, mas havia cinco grandes.

Aumentos de preços geométricos para as novas regras . Cada nova regra foi adicionada por mais tempo que a anterior, porque era necessário primeiro verificar se já havia essa regra.
Não há firewall dentro dos segmentos . Os segmentos foram de alguma forma separados um do outro, por dentro já não há recursos suficientes.
As regras são aplicadas há muito tempo. Mãos que um operador de regra local pode escrever em uma hora. Global levou vários dias.
Dificuldades com a auditoria das regras . Mais precisamente, não foi possível. As primeiras regras foram escritas em 2010 e a maioria de seus autores não trabalhava mais para a empresa.
Baixo nível de controle sobre a infraestrutura . Esse é o principal problema - não sabíamos bem o que estava acontecendo conosco.

É assim que o engenheiro de rede era em 2018 quando ouviu: "Precisamos de mais ACLs".

Soluções

No início de 2018, foi decidido fazer algo a respeito.

O preço da integração está em constante crescimento. O ponto de partida foi que grandes centros de dados não eram mais compatíveis com VLANs e ACLs isoladas, porque a memória dos dispositivos acabou.

Solução: removeu o fator humano e automatizou a provisão de acesso ao máximo.

Novas regras se aplicam por um longo tempo. Solução: agilize a aplicação das regras, torne-a distribuída e paralela. Para fazer isso, você precisa de um sistema distribuído para que as regras sejam entregues por conta própria, sem rsync ou SFTP por mil sistemas.

A falta de um firewall dentro dos segmentos.O firewall dentro dos segmentos começou a voar para nós quando diferentes serviços apareceram na mesma rede. Solução: use um firewall baseado em host. Em quase todos os lugares onde temos Linux, e o iptables está em todo lugar, isso não é um problema.

Dificuldades com a auditoria das regras. Solução: mantenha todas as regras em um único local para revisão e gerenciamento, para que possamos auditar tudo.

Baixo nível de controle sobre a infraestrutura. Solução: faça um inventário de todos os serviços e acessos entre eles.

Este é mais um processo administrativo do que técnico. Às vezes, temos de 200 a 300 novos lançamentos por semana, especialmente durante promoções e feriados. No entanto, isso é apenas para uma equipe de nossos DevOps. Com tantas versões, é impossível ver que tipo de portas, IP e integração são necessárias. Portanto, precisávamos de gerentes de serviço especialmente treinados que entrevistaram as equipes: "O que há e por que você o criou?"

Depois de tudo o que lançamos, o engenheiro de rede em 2019 começou a ficar assim.

Cônsul

Decidimos que colocaríamos tudo o que encontrássemos com a ajuda de gerentes de serviço no Consul e, a partir daí, escreveríamos regras do iptables.

Como decidimos fazer isso?

Coletamos todos os serviços, redes e usuários.
Vamos criar regras do iptables baseadas nelas.
Automatize o controle.
...
LUCRO.

O Consul não é uma API remota; pode trabalhar em todos os nós e gravar no iptables. Resta apenas criar controles automáticos que limpem o excesso e a maioria dos problemas será resolvida! Finalizaremos o restante do processo.

Por que cônsul?

Bem estabelecido. Em 2014-15, usamos como back-end para o Vault, no qual armazenamos senhas.

Não perde dados . Durante o uso, o Consul não perdeu dados em nenhum acidente. Esta é uma enorme vantagem para o sistema de gerenciamento de firewall.

As comunicações P2P aceleram a propagação da mudança . Com o P2P, todas as alterações são rápidas, sem a necessidade de esperar horas.

API REST conveniente. Também consideramos o Apache ZooKeeper, mas ele não possui uma API REST, você precisará colocar muletas.

Funciona como um keystore (KV) e como um diretório (Service Discovery) . Você pode armazenar imediatamente serviços, catálogos, data centers. Isso é conveniente não apenas para nós, mas também para as equipes vizinhas, porque ao criar um serviço global, pensamos grande.

Escrito em Go, que faz parte da pilha Wargaming. Adoramos esse idioma, temos muitos desenvolvedores do Go.

Poderoso sistema ACL. No Consul, você pode usar ACLs para gerenciar quem e o que escrever. Garantimos que as regras do firewall não se sobrepõem a mais nada e não teremos problemas com isso.

Mas a Consul tem suas desvantagens.

Não é escalável no data center, se você não tiver uma versão comercial. É dimensionado apenas pela federação.
Muito dependente da qualidade da rede e da carga do servidor. O Consul não funcionará normalmente como um servidor em um servidor ocupado se houver atrasos na rede, por exemplo, velocidade irregular. Isso ocorre devido às conexões P2P e aos modelos de distribuição de atualização.
Dificuldades com o monitoramento da acessibilidade . No status de cônsul pode dizer que está tudo bem, mas ele morreu há muito tempo.

Resolvemos a maioria desses problemas durante a operação do Consul, então escolhemos. A empresa tem planos para um back-end alternativo, mas aprendemos a lidar com problemas e ainda moramos com a Consul.

Como funciona o cônsul

No data center condicional, instalamos servidores - de três a cinco. Um ou dois servidores não funcionarão: eles não poderão organizar um quorum e decidir quem está certo, quem está errado, quando os dados não coincidem. Mais de cinco não faz sentido, o desempenho cairá.

Os clientes se conectam em qualquer ordem aos servidores: os mesmos agentes, apenas com um sinalizador server = false.

Depois disso, os clientes recebem uma lista de conexões P2P e constroem conexões entre si.

No nível global, estamos interconectando vários data centers. Eles também conectam P2P e se comunicam.

Quando queremos coletar dados de outro data center, a solicitação passa de servidor para servidor. Esse esquema é chamado de protocolo Serv . O protocolo Serf, como o Consul, é desenvolvido pela HashiCorp.

Alguns fatos importantes sobre o Consul

Cônsul tem documentação descrevendo seu trabalho. Darei apenas fatos selecionados que valem a pena conhecer.

Os servidores do Consul selecionam mestres entre os eleitores . O Consul seleciona o assistente na lista de servidores para cada datacenter e todas as solicitações são direcionadas apenas a ele, independentemente do número de servidores. Pendurar o mago não leva à reeleição. Se o assistente não estiver selecionado, as solicitações não serão atendidas por ninguém.

Deseja escala horizontal? Lamento mas não.

Uma solicitação para outro data center passa de mestre para mestre, independentemente de qual servidor ele veio. O mestre selecionado recebe 100% da carga, exceto a carga nas solicitações de encaminhamento. Todos os servidores do datacenter têm uma cópia atualizada dos dados, mas apenas uma responde.

A única maneira de escalar é ativar o modo obsoleto no cliente.

No modo obsoleto, você pode responder sem quorum. Esse é um modo no qual recusamos a consistência dos dados, mas lemos um pouco mais rápido que o normal e qualquer servidor responde. Naturalmente, a gravação é apenas através do mestre.

O Consul não copia dados entre data centers . Ao coletar federação, cada servidor terá apenas seus próprios dados. Para outros, ele sempre se volta para outra pessoa.

A atomicidade das operações não é garantida fora da transação . Lembre-se de que não apenas você pode mudar alguma coisa. Se você desejar de maneira diferente, realize uma transação com um bloqueio.

As operações de bloqueio não garantem o bloqueio . A solicitação vai de mestre para mestre, e não diretamente, portanto, não há garantia de que o bloqueio funcione quando você bloquear, por exemplo, em outro datacenter.

As ACLs também não garantem o acesso (em muitos casos) . A ACL pode não funcionar porque está armazenada em um datacenter da federação - no datacenter da ACL (DC Primário). Se o controlador de domínio não responder, a ACL não funcionará.

Um assistente pairando congelará toda a federação . Por exemplo, na federação há 10 data centers, e em um há uma rede ruim e um mestre cai. Todo mundo que se comunica com ele fica preso em um círculo: um pedido está sendo feito, não há resposta, o fio trava. Não será possível descobrir quando isso acontecerá, em apenas uma ou duas horas a federação inteira cairá. Você não pode fazer nada sobre isso.

Status, quorum e eleições são processados em um thread separado. A re-seleção não ocorrerá, o status não mostrará nada. Você acha que tem um cônsul ativo, você pergunta, e nada acontece - não há resposta. Além disso, o status mostra que está tudo bem.

Enfrentamos esse problema, tivemos que reconstruir partes específicas dos data centers para evitá-lo.

A versão comercial do Consul Enterprise não possui alguns dos inconvenientes acima . Tem muitas funções úteis: votação, distribuição, dimensionamento. Existe apenas um "mas" - um sistema de licenciamento para um sistema distribuído é muito caro.

Life hack: rm -rf /var/lib/consul- uma cura para todas as doenças do agente. Se algo não funcionar para você, basta excluir seus dados e fazer o download dos dados da cópia. Provavelmente, o Consul funcionará.

Befw

Agora vamos falar sobre o que adicionamos ao Consul.

BEFW - um acrônimo para Bed and ack E nd a F a ira de o W todos. Era necessário, de alguma forma, nomear o produto quando eu criei o repositório para colocar o primeiro teste confirmado nele. Este nome permanece.

Modelos de regras

As regras são escritas na sintaxe do iptables.

-N BEFW
-P INPUT DROP
-A INPUT -m state - state RELACIONADO, ESTABELECIDO -j ACEITA
-A ENTRADA -i lo -j ACEITA
-A ENTRADA -j BEFW

Todos nós vamos para a cadeia BEFW, exceto ESTABLISHED, RELATEDe localhost. O modelo pode ser qualquer coisa, este é apenas um exemplo.

Para que serve o BEFW?

Serviços

Temos um serviço, ele sempre tem uma porta, o nó no qual trabalha. No nosso nó, podemos solicitar localmente ao agente e descobrir que temos algum tipo de serviço. Você também pode colocar tags.

Qualquer serviço que esteja sendo executado e registrado no Consul se tornará uma regra do iptables. Temos SSH - porta aberta 22. O script bash é simples: curl e iptables, nada mais é necessário.

clientes

Como abrir o acesso não a todos, mas seletivamente? Pelo nome do serviço, adicione listas de IPs ao repositório KV.

Por exemplo, queremos que todos da décima rede possam acessar o serviço SSH_TCP_22. Adicionar um pequeno campo TTL? e agora temos permissões temporárias, por exemplo, por um dia.

Acessos

Conectamos serviços e clientes: temos um serviço, pois cada armazenamento KV está pronto. Agora, damos acesso não a todos, mas de forma seletiva.

Grupos

Se toda vez que escrevermos milhares de IPs para acessos, ficaremos cansados. Vamos criar agrupamentos - um subconjunto separado em KV. Vamos chamá-lo de Alias (ou grupos) e armazenaremos grupos lá de acordo com o mesmo princípio.

Conectar: agora podemos abrir o SSH não especificamente no P2P, mas em um grupo inteiro ou em vários grupos. Da mesma forma, existe TTL - você pode adicionar e remover temporariamente do grupo.

Integração

Nosso problema é o fator humano e a automação. Até agora, resolvemos assim.

Trabalhamos com o Puppet e transferimos tudo relacionado ao sistema (código do aplicativo) para ele. O Puppetdb (PostgreSQL regular) armazena uma lista de serviços que estão sendo executados lá, você pode encontrá-los por tipo de recurso. Lá você pode encontrar quem vai aonde. Também temos um sistema de solicitação pull e de mesclagem para isso.

Escrevemos befw-sync, a solução mais simples que ajuda a transferir dados. Primeiro, os cookies de sincronização vão para puppetdb. A API HTTP está configurada lá: perguntamos quais serviços temos, o que precisa ser feito. Então eles fazem um pedido ao cônsul.

Existe integração? Sim: eles escreveram as regras, com permissão para aceitar a solicitação de recebimento. Precisa de alguma porta ou adicionar um host a algum grupo? Solicite, analise - não mais "Encontre 200 outras ACLs e tente fazer algo a respeito."

Otimização

O ping do host local com uma cadeia de regras vazia leva 0,075 ms.

Adicione 10.000 tabelas de ip a essa cadeia. Como resultado, o ping aumentará 5 vezes: o iptables é completamente linear, o processamento de cada endereço leva algum tempo.

Para o firewall, para o qual migramos milhares de ACLs, temos muitas regras, e isso introduz um atraso. Para protocolos de jogos, isso é ruim.

Mas se colocarmos 10.000 endereços no ipset, o ping diminuirá ainda mais.

O ponto é que o "O" (complexidade do algoritmo) para o ipset é sempre 1, não importa quantas regras existam. É verdade que há uma limitação - não pode haver mais de 65535 regras. Por enquanto, vivemos com isso: você pode combiná-las, expandi-las e criar dois ipsets em um.

Armazenamento

A continuação lógica do processo de iteração é o armazenamento de informações do cliente para o serviço no ipset.

Agora temos o mesmo SSH e não escrevemos imediatamente 100 IP, mas definimos o nome do ipset para se comunicar e a regra a seguir DROP. Você pode refazer a regra "Quem não está aqui, isso é DROP", mas com mais clareza.

Agora temos regras e conjuntos. A principal tarefa é fazer um conjunto antes de escrever a regra, porque, caso contrário, o iptables não gravará a regra.

Esquema geral

Na forma de um diagrama, tudo o que eu disse se parece com isso.

Comprometa-se com o Puppet, tudo é enviado para o host, os serviços estão aqui, o ipset está lá e quem não está registrado lá não é permitido.

Permitem negar

Para salvar rapidamente o mundo ou desligar rapidamente alguém, no início de todas as correntes, fizemos dois ipset: rules_allowe rules_deny. Como funciona?

Por exemplo, alguém com bots cria uma carga em nossa Web. Anteriormente, era necessário encontrar seu IP pelos logs, encaminhá-lo aos engenheiros de rede para que eles pudessem encontrar a fonte do tráfego e bani-lo. Agora parece diferente.

Nós enviamos para o Consul, espere 2,5 s e pronto. Como o Consul distribui rapidamente por meio do P2P, ele funciona em qualquer lugar e em qualquer lugar do mundo.

Uma vez parei completamente o WOT, cometendo um erro com o firewall. rules_allow- Este é o nosso seguro contra esses casos. Se cometemos um erro com o firewall em algum lugar, algo está bloqueado em algum lugar, sempre podemos enviar um condicional 0.0/0para aumentar tudo rapidamente. Então vamos consertar tudo com as mãos.

Outros conjuntos

Você pode adicionar outros conjuntos no espaço $IPSETS$ .

Pelo que? Às vezes, alguém precisa de um ipset, por exemplo, para emular a desconexão de alguma parte do cluster. Todos podem trazer quaisquer conjuntos, ligar para eles e eles serão retirados do Consul. Ao mesmo tempo, os conjuntos podem participar das regras do iptables e ser como uma equipe NOOP: a consistência será suportada pelo daemon.

Comercial

Costumava ser assim: um usuário conectado a uma rede e recebido parâmetros através de um domínio. Até a próxima geração de firewalls, a Cisco não conseguia entender onde o usuário está e onde está o IP. Portanto, o acesso foi concedido apenas através de máquinas de nome de host.

O que nos fizemos? Casado no momento de receber o endereço. Geralmente é dot1x, Wi-Fi ou VPN - tudo passa pelo RADIUS. Para cada usuário, crie um grupo por nome de usuário e insira um IP com TTL, que é igual ao dhcp.lease - assim que expirar, a regra desaparecerá.

Agora podemos abrir o acesso aos serviços, bem como a outros grupos, por nome de usuário. Nós nos livramos da dor com o nome do host quando eles mudam e tiramos a carga dos engenheiros de rede porque eles não precisavam mais da Cisco. Agora, os próprios engenheiros prescrevem o acesso aos seus servidores.

Isolamento

Paralelamente, começamos a desmontar o isolamento. Os gerentes de serviço fizeram um inventário e analisamos todas as nossas redes. Nós os decompomos nos mesmos grupos e, nos servidores necessários, os grupos foram adicionados, por exemplo, para negar. Agora, o mesmo isolamento de preparação entra em regras_deny na produção, mas não na produção em si.

O esquema funciona de maneira rápida e simples: remova todas as ACLs dos servidores, descarregue o hardware, reduza o número de VLANs isoladas.

Controle de integridade

Anteriormente, um gatilho especial funcionava para nós, informando quando alguém alterava a regra do firewall com as mãos. Eu escrevi um enorme verificador de regras de firewall, foi difícil. Agora a integridade controla o BEFW. Ele zelosamente garante que as regras que ele faz não mudem. Se alguém alterar as regras do firewall, ele retornará tudo de volta. "Eu rapidamente criei um proxy aqui para trabalhar em casa" - não existem mais essas opções.

O BEFW controla o ipset dos serviços e lista em befw.conf, as regras de serviço na cadeia do BEFW. Mas não segue outras cadeias e regras e outro ipset.

Proteção contra acidentes

O BEFW sempre salva o último estado de sucesso diretamente na estrutura binária de state.bin. Se algo desse errado, ele sempre volta a esse estado.bin.

Este é o seguro instável do cônsul quando ele não enviou dados ou alguém cometeu um erro e usou regras que não podiam ser aplicadas. Para que não fiquemos sem um firewall, o BEFW retornará ao último estado se ocorrer um erro em algum momento.

Em situações críticas, é uma garantia de que permaneceremos com um firewall em funcionamento. Abrimos todas as redes cinzentas na esperança de que o administrador venha e corrija-o. Algum dia eu o retirarei nas configurações, mas agora temos apenas três redes cinzentas: 10/8, 172/12 e 192.168 / 16. Como parte do nosso cônsul, esse é um recurso importante que ajuda a se desenvolver ainda mais.

: - BEFW. . GitHub.

Vou falar sobre os bugs que encontramos.

ipset add set 0.0.0.0/0. O que acontece se você adicionar ao ipset 0.0.0.0/0? Todos os IPs serão adicionados? O acesso à Internet será aberto?

Não, temos um bug que nos custa duas horas de inatividade. Além disso, o bug não funciona desde 2016, está no RedHat Bugzilla sob o número # 1297092, mas o encontramos por acidente - a partir do relatório do desenvolvedor.

Agora, o BEFW possui uma regra estrita, que se 0.0.0.0/0transforma em dois endereços: 0.0.0.0/1e 128.0.0.0/1.

conjunto de restauração ipset <arquivo. O que o ipset faz quando você conta restore? Você acha que funciona como o iptables? Recuperar dados?

Nada disso - ele faz uma mesclagem e os endereços antigos não desaparecem, você não fecha o acesso.

Encontramos um bug quando testamos o isolamento. Agora existe um sistema bastante complicado - em vez de ser restoreexecutado create temp, então restore flush tempe restore temp. No final da troca: por atomicidade, porque se você executar pela primeira vez flushe nesse momento algum pacote chegar, ele será descartado e algo dará errado. Portanto, há um pouco de magia negra.

consul kv get -datacenter = outro. Como eu disse, pensamos que estamos solicitando alguns dados, mas obteremos dados ou um erro. Podemos fazer isso através do Consul localmente, mas, neste caso, um e outro irão travar.

O cliente Consul local é um invólucro sobre a API HTTP. Mas ele simplesmente trava e não responde Ctrl + C ou Ctrl + Z, não importa o quê, apenaskill -9no console adjacente. Nos deparamos com isso quando estávamos construindo um grande cluster. Mas ainda não temos solução, estamos nos preparando para corrigir esse erro no Consul.

O líder do cônsul não está respondendo. Nosso mestre no data center não responde, pensamos: "Provavelmente, o algoritmo de re-seleção funcionará agora?"

Não, não funcionará e o monitoramento não mostrará nada: a Consul irá dizer que existe um índice de comprometimento, um líder foi encontrado, está tudo bem.

Como estamos lutando contra isso? service consul restartno cron a cada hora. Se você tem 50 servidores - não é grande coisa. Quando houver 16.000, você entenderá como isso funciona.

Conclusão

Como resultado, obtivemos as seguintes vantagens:

100% de cobertura de todas as máquinas Linux.
Rapidez.
Automação
Engenheiros de ferro e rede libertados da escravidão.
Existem oportunidades de integração quase infinitas: mesmo com o Kubernetes, mesmo com o Ansible, mesmo com o Python.

Contras : Consul, com quem agora vivemos, e um preço muito alto de erro. Como exemplo, uma vez às 18 horas (horário nobre na Rússia), eu decidi algo nas listas de redes. Estávamos construindo isolamento no BEFW naquele momento. Parece que eu estava enganado em algum lugar, indiquei a máscara errada, mas tudo caiu em dois segundos. O monitoramento acende, o oficial de serviço entra: “Tudo está conosco!” O chefe do departamento ficou cinzento quando explicou aos negócios por que isso aconteceu.

O preço do erro é tão alto que criamos nosso próprio e complicado procedimento de profilaxia. Se você implementá-lo em uma grande produção, não precisará fornecer um token mestre sobre o Consul a todos. Isso terminará mal.

Custo.Eu escrevi o código por 400 horas sozinho. Apoiar minha equipe de 4 pessoas passa 10 horas por mês. Comparado ao preço de qualquer firewall de nova geração, é grátis.

Planos. O plano de longo prazo é a busca de transporte alternativo em troca ou além do Consul. Talvez seja Kafka ou algo assim. Mas nos próximos anos viveremos no Consul.

Planos imediatos: integração com o Fail2ban, com monitoramento, com nftables, possivelmente com outras distribuições, métricas, monitoramento avançado, otimização. O suporte ao Kubernetes também está em algum lugar nos planos, porque agora temos vários grupos e desejo.

Outro dos planos:

procure anomalias de tráfego;
gerenciamento de mapa de rede;
Suporte ao Kubernetes;
montagem de pacotes para todos os sistemas;
UI da Web

Estamos constantemente trabalhando para expandir a configuração, aumentando as métricas e otimizando.

Participe do projeto. O projeto acabou sendo legal, mas, infelizmente, ainda é um projeto de uma pessoa. Venha ao GitHub e tente fazer algo: comprometa, teste, ofereça algo, faça sua avaliação.

Enquanto isso, estamos nos preparando para o Saint HighLoad ++ , que será realizado nos dias 6 e 7 de abril em São Petersburgo, e convidamos os desenvolvedores de sistemas de alta carga a solicitar um relatório . Oradores experientes já sabem o que fazer, e recomendamos que os novatos nos discursos, pelo menos, tentem . Participar da conferência como palestrante tem várias vantagens. Você pode ler, por exemplo, no final deste artigo .

Consul + iptables =: 3