Canary Deployment em Kubernetes #1: Gitlab CI

Canary Deployment em Kubernetes #1: Gitlab CI

Continuamos nosso ciclo de artigos sobre NGFW para pequenas empresas; lembro que estamos analisando a nova linha de modelos da série 1500. No 1ª parte do ciclo, mencionei uma das opções mais úteis ao comprar um dispositivo SMB — fornecimento de gateways com licenças integradas de Acesso Móvel (de 100 a 200 usuários, dependendo do modelo). Neste artigo, iremos explorar a configuração de VPN para os gateways da série 1500, que vêm com Gaia 80.20 Embedded pré-instalado. Aqui está um resumo:

  1. Recursos de VPN para SMB.
  2. Organização de Acesso Remoto para pequenos escritórios.
  3. Clientes disponíveis para conexão.

1. Recursos de VPN para SMB

Para preparar o material de hoje, foi utilizado o guia oficial do administrador da versão R80.20.05 (no momento da publicação do artigo — atual). Portanto, no que diz respeito à VPN com a Gaia 80.20 Embedded, há suporte para:

  1. Site-To-Site. Criação de túneis VPN entre seus escritórios, onde os usuários poderão trabalhar como se estivessem em uma única rede “local”.

    Canary Deployment em Kubernetes #1: Gitlab CI

  2. Acesso Remoto. Conexão remota aos recursos do seu escritório usando dispositivos finais dos usuários (PCs, telefones móveis, etc.). Além disso, há o SSL Network Extender, que permite publicar aplicativos individuais e executá-los com Java Applet, conectando-se via SSL. Nota: não confundir com o Mobile Access Portal (suporte na Gaia Embedded não está disponível).

    Canary Deployment em Kubernetes #1: Gitlab CI

Além disso recomendo fortemente o curso do TS Solution — Check Point Remote Access VPN ele revela as tecnologias da Check Point em relação à VPN, aborda questões de licenciamento e contém instruções detalhadas de configuração.

2. Acesso Remoto para pequenos escritórios

Vamos começar a organizar a conexão remota com seu escritório:

  1. Para que os usuários possam construir um túnel VPN com o gateway, é necessário ter um endereço IP público. Se você já passou pela configuração inicial (2 artigos da série), geralmente — o External Link já está ativo. Você pode obter essa informação acessando o Gaia Portal: Device → Network → Internet

    Canary Deployment em Kubernetes #1: Gitlab CI

    Caso sua empresa utilize um endereço IP público dinâmico, você pode configurar o Dynamic DNS. Vá para Device → DDNS & Device Access

    Canary Deployment em Kubernetes #1: Gitlab CI

    Atualmente, há suporte de dois provedores: DynDns e no-ip.com. Para ativar a opção, é necessário inserir suas credenciais (login e senha).

  2. Em seguida, criaremos uma conta de usuário, que será útil para testar as configurações: VPN → Remote Access → Remote Access Users

    Canary Deployment em Kubernetes #1: Gitlab CI

    No grupo (exemplo: remoteaccess), criaremos um usuário seguindo as instruções na captura de tela. A configuração da conta é padrão, definimos o login e a senha, além de ativar a opção Remote Access permissions.

    Canary Deployment em Kubernetes #1: Gitlab CI

    Se você aplicou as configurações com sucesso, devem aparecer dois objetos: um usuário local e um grupo local de usuários.

    Canary Deployment em Kubernetes #1: Gitlab CI

  3. O próximo passo é ir para VPN → Remote Access → Blade Control. Certifique-se de que o blade está ativado e o tráfego de usuários remotos está permitido.

    Canary Deployment em Kubernetes #1: Gitlab CI

  4. *Acima foi apresentado o conjunto mínimo de passos para configurar o Remote Access. Mas antes de testarmos a conexão, vamos explorar as configurações adicionais acessando a aba VPN → Remote Access → Advanced

    Canary Deployment em Kubernetes #1: Gitlab CI

    Com base nas configurações atuais, vemos que usuários remotos ao se conectarem receberão um endereço IP da rede 172.16.11.0/24, graças à opção Office Mode. Isso é suficiente para usar 200 licenças concorrentes (indicado para 1590 NGFW Check Point).

    Opção «Route Internet traffic from connected clients through this gateway» é opcional e é responsável pela roteação de todo o tráfego do usuário remoto através do gateway (incluindo conexões com a Internet). Isso permite inspecionar o tráfego do usuário e proteger sua estação de trabalho contra diversas ameaças e malwares.

  5. *Trabalhando com políticas de acesso para Remote Access

    Depois que configuramos o Remote Access, uma regra de acesso automática foi criada no nível do Firewall, para visualizá-la, você precisa acessar a aba: Access Policy → Firewall → Policy

    Canary Deployment em Kubernetes #1: Gitlab CI

    Neste caso, usuários remotos que pertencem ao grupo criado anteriormente poderão acessar todos os recursos internos da empresa. Observe que a regra está na seção geral “Incoming, Internal and VPN traffic”. Para permitir o tráfego dos usuários VPN na Internet, será necessário criar uma regra separada na seção geral “Outgoing access to the Internet”.

  6. Finalmente, precisamos garantir que o usuário pode criar com sucesso um túnel VPN até o nosso gateway NGFW e acessar os recursos internos da empresa. Para isso, é necessário instalar o cliente VPN no host de teste; anexo um link link para download. Após a instalação, será necessário seguir o procedimento padrão para adicionar um novo site (o endereço IP público do seu gateway deve ser informado). Para facilitar, o processo é apresentado em formato GIF.

    Canary Deployment em Kubernetes #1: Gitlab CI

    Uma vez estabelecida a conexão, vamos verificar o endereço IP obtido na máquina host usando o comando no CMD: ipconfig

    Canary Deployment em Kubernetes #1: Gitlab CI

    Confirmamos que o adaptador de rede virtual recebeu um endereço IP do Modo Office do nosso NGFW, e os pacotes estão sendo enviados com sucesso. Para finalizar, podemos acessar o Gaia Portal: VPN → Acesso Remoto → Usuários Remotos Conectados

    Canary Deployment em Kubernetes #1: Gitlab CI

    O usuário “ntuser” aparece como conectado, vamos verificar o registro de eventos, acessando Logs & Monitoring → Logs de Segurança

    Canary Deployment em Kubernetes #1: Gitlab CI

    O registro da conexão está ocorrendo, com o seguinte endereço IP como origem: 172.16.10.1 — este é o endereço obtido pelo nosso usuário através do modo Office.

    3. Clientes suportados para Acesso Remoto

    Depois de revisar o procedimento de configuração da conexão remota ao seu escritório utilizando o NGFW Check Point da linha SMB, gostaria de abordar o suporte a clientes para diversos dispositivos:

    A variedade de sistemas operacionais e dispositivos suportados permitirá que você utilize sua licença que acompanha o NGFW ao máximo. Para configurar um dispositivo específico, existe uma opção conveniente “Como conectar”

    Canary Deployment em Kubernetes #1: Gitlab CI

    Nela, os passos são automaticamente gerados conforme suas configurações, permitindo que os administradores instalem novos clientes sem problemas.

    Conclusão: Em resumo, neste artigo, examinamos as capacidades do VPN para o NGFW Check Point da linha SMB. Em seguida, descrevemos os passos para configurar o Acesso Remoto, no caso de usuários se conectando remotamente ao escritório, e após isso, analisamos as ferramentas de monitoramento. Para concluir o artigo, falamos sobre os clientes disponíveis e as opções de conexão durante o Acesso Remoto. Assim, seu escritório filial poderá garantir a continuidade e segurança do trabalho dos colaboradores usando tecnologias VPN, apesar de várias ameaças e fatores externos.

    Uma grande seleção de materiais sobre Check Point da TS Solution. Fique de olho nas atualizações (Telegram, Facebook, VK, Blog da TS Solution, Yandex.Zen).

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster