Começar
A popularidade das soluções UTM modernas está principalmente associada à sua multifuncionalidade. A capacidade de resolver rapidamente todas as tarefas de TI de uma empresa, e até mesmo de uma interface da web, atrai muitos administradores de sistema.
Nossa solução, Internet Control Server , também pertence à classe de produtos UTM, combinando as funções de proteção de rede, gerenciamento de conexão à Internet, filtragem de conteúdo e muitas outras.
Apesar das vantagens óbvias, há uma desvantagem em usar essas soluções - muitas vezes são monolíticas, o que não permite responder às mudanças do mercado de uma forma mais flexível.
Deste ponto de vista, um produto mais interessante é o gateway UTM, que pode ser construído pelo próprio usuário, com base nas tarefas reais da empresa.
Nesse caso, o administrador do sistema constrói seu gateway a partir dos “blocos de construção” dos componentes, instalando apenas os módulos de que precisa. Todas as ferramentas estão na nuvem do desenvolvedor, e o usuário baixa e instala os pacotes necessários. Este princípio tornou-se fundamental para nossos desenvolvimentos futuros.
O ecossistema histórico do FreeBSD era bom e bem compreendido. Escolhemos o instalador de pacote tradicional do FreeBSD, pkg, como o método mais apropriado para distribuição de pacotes. Um repositório é coletado em nossa nuvem e o acesso a ele é prescrito no cliente na configuração tradicional do pkg.
O que planejamos fazer
O sistema deve ser um construtor na forma de um núcleo no qual os componentes são amarrados. O usuário recebe um kit de distribuição que inclui apenas os plugins mínimos necessários (roteador, fierwall, etc.). O resto é instalado conforme necessário.
Para o sistema funcionar, precisamos implementar os seguintes componentes:
- sistema - kernel do FreeBSD modificado
- core - um pacote especial com configurações do produto, que é a dependência pai de todos os plug-ins
- plugins - cada um deles é um pacote compilado que é instalado de forma regular usando o utilitário pkg
Estrutura do plugin
Conforme declarado, um plugin é um pacote regular. Ele pode ser instalado com o utilitário pkg.
Para manter a compatibilidade com versões anteriores, foi decidido que a nova versão principal do plugin seria um pacote separado, não relacionado à versão principal anterior. Por exemplo, plugin-v1 e plugin-v2 . A razão é que eles podem ter dependências completamente diferentes, talvez até contradizendo-se.
A versão secundária simplesmente muda o número da versão do pacote, tudo é como de costume aqui.
Trabalhando com plugins
Para que o sistema funcione como precisamos, um utilitário adicional foi criado em cima do pacote.
As principais ferramentas de trabalho serão os comandos pkg query e pkg rquery .
O primeiro coleta informações sobre os plug-ins instalados no sistema, o segundo acessa o repositório.
Para que o utilitário controle a execução correta dos comandos no sistema, a execução de cada comando é verificada por um código de retorno. Se um código de retorno de 0 for recebido, o comando foi executado; se houver outra coisa, então ocorreu um erro. Assim, você pode rastrear, por exemplo, problemas de conexão de rede.
Uma nuance interessante surgiu aqui. Por exemplo
, se você pesquisar todos os pacotes por padrão: então, se nenhum pacote instalado corresponder à condição padrão, o erro 69 será retornado sem uma mensagem de erro. Os desenvolvedores do utilitário consideraram que se a pesquisa não retornou nada, então este é um comportamento anormal. Bem ok. Eu tive que lidar com esse caso de uma maneira especial.
Problemas de atualização
Então, os problemas com o controle de versão começam ao atualizar os plug-ins.
Em primeiro lugar, o utilitário pkg, ao executar o comando pkg upgrade <pkg_name>, também atualiza TODAS as dependências diretas do pacote, este comportamento é projetado pelos desenvolvedores. Mas, em nosso caso, isso inclui a atualização e o núcleo, se uma versão secundária tiver sido lançada para ele, o que é indesejável, pois o núcleo altera os parâmetros do sistema e também requer a reinicialização do sistema após a atualização.
Ou seja, se já instalamos o SP2 - pkg-1 e pkg-2 , e dependendo do pkg-1 Defina o pkg-2 , se executarmos o comando pkg upgrade pkg-1 , então o pkg-2 também é atualizado .
Vamos por outro caminho.
Vamos construir a árvore de dependências do pacote para cima e para baixo.
Encontre os nomes de todos os pacotes dos quais nosso pacote depende:
pkg rquery% rn <pkg_name>
Agora todos os pacotes que dependem do nosso pacote:
pkg rquery% dn <pkg_name>
Vamos remover todas as entidades que dependem do pacote. A seguir, começaremos a excluir as entidades das quais nosso pacote depende na árvore até que nos encontremos no núcleo (não iremos excluí-lo, é claro). Agora você pode restaurar a árvore instalando as versões secundárias mais recentes de todos os pacotes nela.
Por exemplo, na imagem acima, podemos ver que o pacote ics-plugin-a-v1 depende do plugin ics-plugin-b-v1 . Se precisarmos atualizar o pacote para a versão ics-plugin-v2 , isso também implicará a atualização do pacote ics-plugin-b-v1 , para o qual existem 2 versões principais - ics-plugin-b-v2 e ics-plugin -b-v3 . No entanto, nenhum deles oferece suporte ao plugin ics-plugin-c-v1 . Ou seja, a atualização instalará primeiro o pacote ics-plugin-b-v2 ou -v3 e , em seguida, ics-plugin-a-v1e ics-plugin-c serão desinstalados e não instalados.
Além disso, o núcleo pode ter uma versão principal, caso em que todo o conjunto de plug-ins deve ser atualizado para corresponder.
Para instalar o pacote ics-plugin-a , que depende do ics-core-v2, você precisa atualizar o ics-core, após o qual apenas os pacotes principais que dependem do ics-core-v2 serão instalados .
Backup de banco de dados
Ao trabalhar com o repositório, é possível uma situação em que durante a atualização a conexão será perdida (ocorre o código de erro de sistema 70 ou 3). Além disso, para desinstalar corretamente o plugin, o sistema precisa de um pacote válido no sistema. Ao executar o comando pkg update , se não houver conexão, a base reporta um erro e mesmo localmente não executa suas funções até que a atualização seja concluída corretamente.
Para evitar tais situações, usaremos o utilitário pkg backup . Antes de qualquer operação, durante a qual existe a possibilidade de não obter o resultado desejado, salve o banco de dados:
pkg backup -d <backup_dir>
Se a operação não foi concluída corretamente, retorne o banco de dados ao seu lugar:
pkg backup -r <backup_dir>
Testemunho
Até agora, tudo é bastante simples. Se houver uma atualização para o kernel, então:
- baixe a nova imagem do kernel no arquivo
- crie um novo conjunto de dados em zfs
- montar o conjunto de dados no sistema
- descompacte a imagem
- instale um pacote especial com as opções de kernel necessárias para operação normal
- registre a nova imagem como inicializável
- ???
Lucro?
Ainda não.
Precisamos restaurar os plug-ins do sistema instalados anteriormente pelo usuário (se eles forem suportados pelo novo kernel, é claro). Da mesma forma, você precisa criar um repositório de plug-ins separado para cada versão do kernel.
Mas (como sempre) há uma nuance.
Ainda não instalamos o kernel da versão futura e não podemos instalar o plugin para outra versão. Se inicializarmos o sistema a partir de uma nova imagem, não poderemos acessar o repositório (por razões históricas e técnicas, o roteamento também é um plugin).
O que fazer?
Aumentamos o servidor com api, que fornecerá o arquivo com o repositório de plug-ins para a versão de kernel especificada.
Então, nosso utilitário irá gerar um arquivo de configuração do repositório com o caminho para a pasta com o arquivo descompactado.
Para o FreeBSD, este será o arquivo <repo_name> .conf em / usr / local / etc / repos ou / etc / repos . É importante notar aqui que o caminho é escrito da seguinte forma: url: “file: /// path_to_repo” ( 3 barras! )
Salve os dados sobre os plug-ins instalados e verifique sua compatibilidade com a versão futura do kernel (se houver algum incompatível , informaremos o usuário sobre isso).
Agora você pode reiniciar.
Última coisa
O pacote requer inicialização (bootstrap) após a atualização do sistema. Portanto, se você executar qualquer comando, ele será solicitado. Em nosso caso, o utilitário de vinculação não entenderá que o deseja e considerará que a operação foi realizada incorretamente.
Para fazer isso, criamos um manipulador de erro de inicialização, felizmente, ele tem um código de operação do sistema separado 1. Portanto, se o utilitário encontrar tal código, ele simplesmente executa
pkg -y O
Pkg faz um bootstrap e então você pode trabalhar normalmente.
Total
É assim que construímos nosso repositório. Embora este seja um protótipo, e no futuro ele provavelmente mudará e se tornará mais complexo, mas a base do design foi estabelecida e permanecerá inalterada.
A tecnologia descrita será aplicada em novos desenvolvimentos de Internet Control Server, tornando-o ainda mais conveniente para uso em redes corporativas de empresas. Você pode baixar e testar a versão mais atual do ICS no link .
Período de teste, versão gratuita para 9 usuários, demonstração online e suporte técnico responsivo.
Acompanhe as novidades e fique conosco!