sexta-feira, 3 de março de 2017

NSX - Controller

O controlador NSX é uma VM que é implantada pelo NSX Manager. É um dos componentes centrais do NSX. Ele fornece um plano de controle para distribuir informações de rede para hosts. Para alcançar um alto nível de resiliência, o controlador NSX é agrupado para escala e HA.

O controlador NSX contém três tabelas primárias. 

Tabela de endereço MAC, tabela ARP e uma tabela VTEP. Essas tabelas agrupam informações de VM e host em conjunto para cada três tabelas e replicam isso em todo o domínio NSX. O benefício de tal ação é habilitar multi-cast free VXLAN no underlay. As versões anteriores do vCNS e outras soluções habilitadas para VXLAN exigiam o VXLAN ativado na parte superior dos switches de rack ou em todo o tecido físico. Isso proporcionou uma sobrecarga administrativa significativa e remover isso alivia muito a complexidade.

Mantendo estas tabelas um benefício adicional é a supressão de ARP. A supressão de ARP permitirá a redução das solicitações ARP em todo o ambiente. Isto é importante quando os segmentos da camada dois se estendem através de vários domínios L3. Se um segmento solicitar o IP de um endereço MAC que não esteja em um segmento local, o host terá as informações replicadas em suas tabelas empurradas para ele pelo controlador.


O NSX Controller tem cinco funções:


  • API Provider:  Mantém os  API de Web-service que são consumidos pelo NSX Manager;
  • Persistence Server:  Garante a proteção e preservação dos dados entre os hosts;
  • Logical Manager: Lida com a política e a topologia de rede.
  • Switch Manager:  Gerencia os hypervisors e envia a configuração relevante para o host.
  • Directory server: Se concentra na VXLAN e no diretório de informações de roteamento lógico distribuído;

Embora cada função precise de um "master" diferente, cada função pode ser eleita para se aplicar no mesmo ou em um host diferente. Se ocorrer uma falha de um host e não houver um master para uma função eleita, um novo host será promovido para master após o processo de eleição.

A maioria dos cenários de implementação vê três, cinco ou sete controladores implantados. Isto é devido ao controlador ser executado Zoo Keeper.
Um cluster Zoo Keeper, conhecido como um conjunto, requer uma maioria para funcionar e isso é melhor configurado através de um número ímpar de máquinas. Esse cenário de desempate é usado em muitos casos e condições de HA durante o NSX para operações vSphere.

Slicing/Fatiamento:

Em um ambiente dinâmico que pode ter várias mudanças por segundo, é necesário distribui r dinamicamente a carga de trabalho entre os clusters disponíveis, que  reorganiza as cargas de trabalho quando novos membros do cluster são adicionados e mantém sem impacto enquanto isso ocorre internaemente.

Uma role é feita para criar um número de fatias de si mesmo. Um aplicativo agrupa suas fatias e atribuirá o objeto a uma fatia. Isso garante que nenhum nó individual possa causar uma falha da função do NSX Controller;

Quando uma falha de um host do NSX controller ocorre as fatias que o controlador é responsável será replicado e reproduzido através dos outros controladores existentes. Isso garante ainformações de rede consistente e continuo.

Comandos:

# show controller-cluster status
# show controller-cluster startup-nodes
# show controller-cluster role
# show controller-cluster connections


quinta-feira, 2 de março de 2017

NSX - Distributed Firewall (DFW)


As soluções de segurança tradicionais não são otimizadas para SDDC (Software Defined Data Center), resultando em um impacto negativo na agilidade e nos custos.

Os Firewalls tadicionais de perimetro e os sistemas de detecção e prevenção de intrusos não são suficientes para proteger o o datacenter inteiro.

o NSX DFW (Distributed Firewall) fornece serviços de firewall stateful, para qualquer carga do ambiente NSX sendo executado diretamente no kernel;

O DFW é ativado assim que o processo de preparação do host estiver concluído;

Se uma VM não requer serviço DFW, ela pode ser adicionada em uma lista de exclusão.

Por padrão, os gateways NSX Manager, NSX Controllers e Edge são automaticamente excluídos da função DFW.

Uma instância DFW é criada por VM vNIC:

Por exemplo, se uma nova VM com 3(três) VNICs for criado, as 3 instâncias de DFW serão alocadas a esta VM. A configuração destas instâncias DFW podem ser idênticas ou diferentes com base no "aplicar a" configuração. Quando uma regra DFW é criada, o usuário pode selecionar um ponto de aplicação (PEP) para esta regra, com opções que variam de Chave Lógica para vNIC. 

Por padrão,"Apply to" não é selecionada, portanto, as regras DFW são propagadas para todos os ESXi Hosts que fazem parte do domínio NSX que foram preparados para ser aplicada a todas as máquinas virtuais conectadas.

Visão das funcionalidades do NSX:

O firewall lógico pertence ao Data Plane:



Recursos do DFW:
  • Firewall no nível da vNIC;
  • Tratamento de sessão com estado(stateful);
  • Os estados de conexão migram durante o vMotion;
  • Firewall distribuído - escala bem com os datacenters sempre em expansão;
  • Micro visibilidade e controle de nível de fluxo;
  • Capacidade de ativar os fluxos em tempo real para depuração;
  • Regras baseadas em conteiners;
  • Regras de firewall segmentadas por NIC virtual;
  • Nenhuma cópia de pacote está envolvida, como no caso de firewalls baseados em máquinas virtuais;
  • Suporte ALG (Application Level Gateway); 
  • Regras criadas automaticamente para portas dinâmicas;
  • O processamento de regras distribuídas evita a duplicação de regras nas NICs virtuais;
  • Suporte autoritário de Spoof Guard;
  • As regras de política do DFW podem ser escritas de 2 maneiras, usando regras L2 (Ethernet) ou L3 / L4;
  • O Firewall Lógico Distribuído aplica regras de firewall diretamente na placa de interface de rede virtual da máquina virtual (vNIC).
  • MAC Set não é uma opção de destino válido para uma regra de fiewall geral.
  • Regras de firewall lógico aplicadas a máquinas virtuais afetadas são aplicadas pelo NSX Manager para os hosts ESXi executando as máquinas virtuais de origem e / ou destino.
  • Uma Máquina Virtual conectada a um switch lógico rodando em um host ESXi 5.1.
  •  não pode ser protegido pelo Firewall Distribuído.
  • Os Logs dos firewalls lógicos são salvos no host ESXi;
  • Firewall Distribuído não gera log durante a criação das regras;

Benefícios:
  • Distribuído no nível do hipervisor;
  • Configuração dinâmica baseada em API;
  • Nome da VM, objetos do VMware vCenter, regras baseadas na identidade;
  • Line rate  ~ 20 Gbps por host;
  • Visibilidade total do tráfego encapsulado;
Nível de atuação do DFW dentro da camada OSI:

O firewall NSX DFW oferece recursos de proteção até a camada 4 do modelo OSI e para as demais camadas de 5 a 7 é necessário um firewall de parceiros como por exemplo a Palo Alto.

Considera-se que apenas entre 10 e 20% do tráfego do Datacenter necessita de serviços L5 - L7;


Diferenças entre Firewall Virtual e Físico:

Firewall baseado em hardware são elaborados para entregar alta performance, alta capacidade de throughpout, tipicamente possuem um range de 2 e 30 Gbps, com alguns chassis excedendo 100Gbps.

Firewalls Virtuais possuem efetivamente uma operação no mesmo ponto de vista de um firewall físico, no entanto reduz os conjuntos de recursos e entregam bem menos capacidade de throughput com um range ntre 1 e 3 Gbps;

Firewall distribuidos são instalados diretamente no hypervisor do kernel e entregam 30Gbps per hypervisor. Sendo assim quanto mais hosts hypervisors tiver no ambiente, maior capacidade de firewall leste-oeste o ambinte possuíra;


Informações sobre Regras:

• As regras L2 são mapeadas para L2 no modelo OSI; Somente endereços MAC podem ser utilizados nos campos de origem e de destino e apenas os protocolos L2 usado nos campos de serviço (por exemplo, ARP).
• As regras L3 / L4 são mapeadas para L3 / L4 no modelo OSI; Regras de política podem ser escritos usando endereços IP e portas TCP / UDP.

  • É importante lembrar que as regras L2 sempre são aplicadas antes das regras L3 / L4.
  • Se a regra de política predefinida L2 for modificada para 'bloco', e então todo o tráfego L3 / L4 será bloqueado por DFW (por exemplo, pings falhariam).
  • O DFW é um componente NSX projetado para proteger a carga de trabalho para a do tráfego de rede virtual-para-virtual ou virtual-para-físico (isto é, o tráfego leste-oeste)

Uma vez que a aplicação da política é aplicada as vNICs das VMs, também poderia ser utilizado para impedir a comunicação entre as máquinas virtuais e a infraestrutura de rede. O DFW é totalmente complementar aos serviços NSX Edge Gateway que fornece capacidade de firewall centralizado. O ESG é tipicamente usado para proteger o tráfego norte-sul e, como tal, é o primeiro ponto de entrada para o SDDC;



O  DFW opera no nível da vNIC; Portanto, uma VM está sempre protegida independentemente da topologia. As VMs podem ser conectadas a um grupo de portas VDS VLAN ou a um Switch Lógico (isto é, grupo de portas com suporte VXLAN). O ESG Firewall pode também ser usado para proteger cargas de trabalho  em servidores físicos e appliances (Por exemplo, NAS).

A arquitetura do sistema DFW é baseada em 3 entidades distintas, cada uma com um papel definido:

• vCenter Server:

vCenter Server é o plano de gerenciamento da solução. As regras de diretiva DFW são criadas no cliente Web vSphere. Qualquer contêiner vCenter pode ser usado no campo de origem / destino da diretiva Regra: cluster, VDS grupo de portas, Switch lógico, VM, vNIC, pool de recursos, Etc

• NSX Manager:

NSX manager é o plano de controle da solução. isto é, recebe regras do vCenter Server e as armazena a base de dados. NSX manager, em seguida, aplica as regras DFW regras para todos os ESXi hosts que foram preparadas para execução. Uma cópia de segurança da política de segurança DFW de regras é executada sempre que a tabela é modificada e publicada. NSX Manager também pode receber regras DFW diretamente de chamadas REST API em implantações onde um sistema de gerenciamento de nuvem é usado para segurança de automação.

• ESXi Host: 

ESXi host é o plano de dados da solução. As regras do DFW são recebidas do NSX Manager e traduzido para o espaço do kernel para tempo real de execução. O tráfego de rede VM é inspecionado e aplicado por ESXi. Como exemplo, VM1 está localizado no host ESXi 1 e envia pacotes para VM2 que está localizado no host ESXi 2. A execução da política é feita no ESXi
Host 1 para saída de tráfego quando os pacotes deixam VM1 e, em seguida, no ESXi host 2
para tráfego de entrada destinado a VM2.

Quando os containers vCenter são usados nas regras de diretiva DFW, VMtools deve ser instalado nas VMs guest. VMtools tem visibilidade do endereço IP do VM - dinamicamente fornecido através de DHCP ou configurado estaticamente na VM pelo administrador - e fornece estas informações para o motor DFW que opera com base nos campos de porta MAC, IP e TCP / UDP.
Se as regras de diretiva DFW usarem apenas informações de IP (por exemplo, IP do host, IP de sub-rede ou conjuntos IP), então a presença de VMtools na VM guest não é necessária.


A função DFW é ativada quando um host está preparado para execução. Durante esta operação, um VIB do kernel é carregado no hypervisor. Este VIB é conhecido como O VMware Internetworking Service Insertion Platform (VSIP). VSIP é responsável por toda a proteção de tráfego de plano de dados.

Uma instância DFW é criada por VM vNIC. Esta instância está localizada entre o VM e o Virtual Switch (ou seja, VDS port-group VLAN-backed ou Logical Switch).

DVfilter slot 2 é alocado para a instância DFW. Todos os pacotes de entrada e saída para e a partir desta VM tem de passar através do DFW.

Um conjunto de daemons chamado vsfwd é executado permanentemente no host ESXi e executa as seguintes tarefas:

• Interagir com o NSX Manager para recuperar regras de diretiva DFW.
• Reunir as informações estatísticas de DFW e enviá-las para o gerente NSX.
• Enviar informações de logs de auditoria para o gerenciador NSX.

O caminho de comunicação entre o vCenter Server e o host ESXi, o processo vpxa no host ESXi. Isto é usado apenas para vSphere relacionado, incluindo criação de VM, modificação de armazenamento e gerenciamento de IP do NSX e distribuição de endereços. Esta comunicação não é utilizada para o funcionamento geral DFW.


O módulo do kernel VSIP não melhora simplesmente a funcionalidade do DFW, esta plataforma de inserção de serviços adiciona serviços complementares como SpoofGuard e redirecionamento de tráfego de terceiros parceiros, incluindo a Palo Alto Networks, CheckPoint, Fortinet, Security Intel, Symantec, RAPID7 e Tend Micro).

SpoofGuard protege contra spoofing IP mantendo uma tabela de referência de VM, nome e endereço IP, preenchendo-o com informações recuperadas do VMtools durante a inicialização inicial da VM. O SpoofGuard está inativo por padrão e deve ser explicitamente habilitado por Switch Lógico ou VDS ou grupo de portas. Quando um endereço IP de VM  identifica um alteração detectada, o tráfego de / para esta VM pode ser bloqueado pelo DFW até o administrador NSX aprovar este novo endereço IP.



O redirecionamento de tráfego para fornecedores terceirizados fornece a capacidade do tipo de tráfego para um VM de serviços de parceiro selecionado. Por exemplo, o tráfego
Internet para um conjunto de servidores Apache ou Tomcat pode ser redirecionado para um L4-L7 Deep Firewall de inspeção de pacotes para proteção avançada.

O redirecionamento de tráfego é definido no Service Composer / Security Policy for NSX Versão 6.0 ou na guia Serviços de segurança do parceiro do menu DFW no NSX Versão 6.1. A guia Serviços de Segurança de Parceiros fornece um recurso poderoso e fácil de usar.

Interface para definir que tipo de tráfego precisa ser redirecionado para qual parceiro Serviços. Segue a mesma construção de definição de política que o DFW, mesmas opções para campo de origem, campo de destino e campo de serviços. A única diferença está no campo de ação; Em vez de Bloquear / Permitir / Rejeitar, um usuário pode selecionar entre redirecionamento / sem redirecionamento seguido por uma lista de parceiros. Qualquer parceiro que tenha sido registrado com o NSX pode ser implantado com sucesso na plataforma. Além disso, as opções de log podem ser ativadas para esta regra de redirecionamento de tráfego.

A instância DFW em um host ESXi contém 2 tabelas separadas. A tabela de regras é usada para armazenar todas as regras de política, enquanto a tabela de rastreador de conexão armazena em cache o fluxo entradas para regras com ações de permissão. Uma instância DFW é permitida por VM VNIC.
Um fluxo específico é identificado pela informação de 5-tuplas que consiste em IP de origem Endereço de destino, endereço IP de destino, protocolos, porta de origem L4 e destino L4 Campos de porta. Por predefinição, o DFW não efetua uma pesquisa em porta de origem L4, mas pode ser configurado para fazê-lo definindo uma regra de política específica.

Firewall Distribuído SpoofGuard

O SpoofGuard permite que o NSX garanta que o IP associado a um endpoint esteja correto no tempo e no bloco especificados se uma alteração não autorizada for detectada. Oaplicação no nível vNIC fornece um local na rede onde a segurança adicional da conexão de rede pode ser entregue.

O SpoofGuard permitirá ao administrador reconhecer e validar uma alteração de IP em uma Máquina Virtual. Sem esse reconhecimento, a Máquina Virtual não poderá se comunicar na rede.

O NSX Manager coleta e aprende endereços IP de todas as máquinas virtuais. A associação vNIC para IP são as informações coletadas - não o endereço MAC da VM;



NSX - Transport Zone

Uma Zona de Transporte define uma coleção de hosts ESXi que podem se comunicar entre si através de uma infra-estrutura de rede física. Esta comunicação acontece através de uma ou mais interfaces definidas como VXLAN Tunnel Endpoints (VTEPs).

Uma Zona de Transporte estende-se através de um ou mais clusters ESXi e normalmente define um intervalo de chaves lógicas. A relação existente entre o Switch Lógico, VDS e Zona de Transporte é central para este conceito.

Um VDS pode possuir vários hosts ESXi e é possível adicionar ou remover dinamicamente hosts ESXi de um VDS específico. Em uma implementação prática do NSX, é muito provável que vários VDS sejam definidos em um determinado domínio NSX.

Um switch lógico pode se estender em vários VDS. Umroteador Lógico é sempre criado como parte de uma Zona de Transporte específica. Isto implica que normalmente a Zona de Transporte estende-se através de todos os clusters ESXi e define a extensão de um Comando Lógico.

Figura 01: VXLAN Transport Zone

Ao criar um DLR para fornecer serviço de roteamento, há dois pontos importantes a ser considerado com relação à Zona de Transporte:

  1. O DLR deve se conectar a (LS) que estejam na mesma Zona de Transporte;
  2. Na configuração no VDS de vários clusters, a Zona de Transporte deve cobrir todos os clusters que o VDS abrange;

O NSX não permite a conexão de VMs que estão em diferentes zonas de transporte.

Tecnicamente, não podemos conectar DLR a LSs que estão em diferentes Transport Zones (a interface do usuário não nos permite fazê-lo).

Figura 02: Trasport Zones

 A extensão de um switch lógico é limitada a uma zona de transporte, de modo que máquinas virtuais em diferentes zonas de transporte não podem estar na mesma rede de Camada 2.

Um roteador lógico distribuído não pode se conectar a switches lógicos que estão em diferentes zonas de transporte. depois de conectar o primeiro roteador lógico, a seleção de outros switches lógicos é limitada àqueles que estão na mesma zona de transporte.

Da mesma forma, um gateway de serviços de borda (ESG) tem acesso a switches lógicos de apenas uma zona de transporte.

Modos de Replicaçao:

Por padrão, o Modo de Replicação do switch lógico é determinado pelo modo configurado na Zona de Transporte;

Dependendo se você possui um nó de controlador em seu ambiente ou se deseja usar endereços de multicast, selecione o modo de plano de controle.

  • Multicast: Endereços IP de multicast na rede física são usados para o plano de controle. Este modo é recomendado somente quando você está atualizando de implantações VXLAN mais antigas. Requer PIM / IGMP na rede física.
  • Unicast: O plano de controle é manipulado por um controlador NSX. Todo o tráfego unicast alavanca a replicação otimizada do cabeçalho. Não são necessários endereços IP multicast ou configuração de rede especial.
  • Híbrido: Descarrega a replicação de tráfego local para a rede física (multicast L2). Isso requer IGMP snooping no switch de primeiro salto e acesso a um querler IGMP em cada sub-rede VTEP, mas não requer PIM. O switch de primeiro salto controla a replicação de tráfego para a sub-rede.
Figura 03: Modo de Replicação

As diretrizes a seguir destinam-se a ajudá-lo a projetar suas zonas de transporte:
  • Se um cluster requer conectividade de camada 3, o cluster deve estar em uma zona de transporte que também contém um cluster de borda, ou seja, um cluster que possui dispositivos de borda de camada 3 (roteadores lógicos distribuídos e gateways de serviços de borda).
  • Para ter conectividade VXLAN entre as VMs em dois clusters, ambos os clusters devem ser incluídos na zona de transporte.
  • Todos os switches lógicos incluídos na zona de transporte estarão disponíveis e visíveis para todas as VMs dentro dos clusters incluídos na zona de transporte. Se um cluster inclui ambientes protegidos, talvez você não queira torná-lo disponível para VMs em outros clusters. Em vez disso, você pode colocar seu cluster seguro em uma zona de transporte mais isolada.
  • O span do roteador distribuído vSphere (VDS) deve corresponder à extensão de zona de transporte. Ao criar zonas de transporte em configurações VDS de vários clusters, verifique se todos os clusters no VDS selecionado estão incluídos na zona de transporte. Isso é para garantir que o DLR está disponível em todos os clusters onde VDS dvPortgroups estão disponíveis.
A zona de transporte não é capaz de restringir a extensão do switch lógico a um subconjunto dos clusters. Se esse roteador lógico for posteriormente conectado a um DLR, você deve garantir que as instâncias do roteador sejam criadas somente no cluster incluído na zona de transporte para evitar quaisquer problemas de Camada 3.


Contratar uma Zona de Transporte

Você pode remover clusters de uma zona de transporte. O tamanho das zonas de transporte existentes é reduzido para acomodar o escopo contratado.

Expandir uma Zona de Transporte

Você pode adicionar clusters a uma zona de transporte. Todas as zonas de transporte existentes ficam disponíveis nos clusters recém-adicionados.

Pré-requisitos:

Os clusters que você adicionar a uma zona de transporte têm a infra-estrutura de rede instalada e estão configurados para VXLAN

Visualizar e editar uma zona de transporte

É possível visualizar as redes lógicas em uma zona de transporte selecionada, os clusters no modo do plano de controle para essa zona de transporte.

Procedimento:
  1. Em Transport Zones, clique duas vezes em uma zona de transporte. A guia Summary exibe o nome e a descrição da zona de transporte, bem como o número de switches lógicos associados a ela. Detalhes da Zona de Transporte exibe os clusters na zona de transporte.
  2. Clique no ícone Editar Configurações na seção Detalhes da Zona de Transporte para editar o nome, descrição ou modo de plano de controle da zona de transporte. Se você alterar o modo de plano de controle de zona de transporte, selecione Migrar Switches Lógicos existentes para o novo modo de plano de controle para alterar o plano de controle mais para os switches lógicos existentes vinculados a essa zona de transporte. Se você não selecionar esta caixa de seleção, somente os switches lógicos ligados a esta zona de transporte depois que a edição for feita terá o novo modo de plano de controle.
  3. Clique em OK.

Zona de Transporte Universal

Em um ambiente cross-vCenter NSX, pode haver apenas uma zona de transporte universal.

A zona de transporte universal é criada no Manager primário e é sincronizada com Managers secundários. Clusters que precisam participar em redes lógicas universais devem ser adicionados à zona de transporte universal a partir de seus gerentes NSX.