A Rede OpenStack

Introdução a iptables, tabelas, regras e cadeias

A rede é uma parte essencial de um sistema de IaaS. Isso também vale para o OpenStack, um projeto de computação em nuvem de software livre e Infraestrutura como serviço (IaaS) realizado pela Rackspace Cloud e pela NAS. Neste artigo, o autor descreve as cadeias de iptable e regras por trás do projeto OpenStack Cloud Compute-Nova, um controlador de malha para computação em nuvem (a principal parte de um sistema IaaS) escrito em Python que usa muitas bibliotecas externas. O autor detalha o componente nova-network FlatDHCPManager, bem como outros componentes do OpenStack. O iptable é um programa de aplicativo de espaço do usuário que permite a um administrador de sistema configurar as tabelas fornecidas pelo® firewall do kernel Linux.

Yong Sheng Gong, Advisory Software Engineer, IBM

Yong Sheng Gong tem 12 anos de experiência em desenvolvimento de software e é qualificado em Linux e C/C++, Java e Python. Atualmente, trabalha em projetos do OpenStack.



16/Ago/2012

Este artigo descreve como o OpenStack trata a rede com iptables, cadeias e regras, basicamente da mesma forma que os outros sistemas. No entanto, primeiro vamos dar uma olhada nas estruturas das iptables para relembrar a tecnologia usada neste artigo.

Estrutura do iptable

Um iptable é um programa de aplicativo do espaço do usuário que permite ao administrador de sistema configurar as tabelas fornecidas pelo firewall do kernel Linux. O iptable se refere especificamente ao IPv4.

Regras são usadas para configurar um firewall Linux; cada regra especifica o que deve corresponder dentro de um pacote e o que fazer com o pacote. Cadeias são listas de regras.

A representação anterior dos iptables, os ipchains, acrescentou o conceito de cadeias de regras. Os iptables ampliaram isso para as tabelas. Portanto, a estrutura dos iptables é: iptables > tabelas > cadeias > regras.

O iptable tem quatro tabelas integradas:

  • Tabela Filter: a tabela padrão com as seguintes cadeias:
    • INPUT para pacotes que vêm para o servidor local.
    • OUTPUT para pacotes gerados localmente que saem do servidor local.
    • FORWARD para pacotes roteados por meio do servidor local.
  • Tabela NAT (conversão de endereço de rede):
    • PREROUTING: usada para a NAT de destino, altera os endereços IP dos pacotes antes do roteamento.
    • POSTROUTING: usada para a NAT de origem, altera os endereços IP dos pacotes depois do roteamento.
    • OUTPUT: a NAT para pacotes gerados localmente no firewall.
  • Tabela Mangle: para a alteração de pacotes especializados:
    • PREROUTING
    • OUTPUT
    • FORWARD
    • INPUT
    • POSTROUTING
  • Tabela Raw: para as isenções de configuração:
    • PREROUTING
    • OUTPUT

O iptable dentro do OpenStack

Dentro do OpenStack, geralmente você encontra regras e cadeias de iptable no módulo Cloud Compute-Nova, um controlador de malha para a computação em nuvem (a parte principal de um sistema de IaaS) escrito em Python que usa muitas bibliotecas externas. Este artigo detalha o componente nova-network FlatDHCPManager, bem como outros componentes do OpenStack necessários para as tarefas de rede.

Quando é iniciado, o OpenStack define algumas de suas cadeias. Essas cadeias formam uma malha de cadeias com cadeias integradas do Linux. Outra tarefa de inicialização é a definição de algumas regras para o intervalo corrigido de rede e para o serviço de metadados. Quando uma rede é criada e usada, o nova-network configura algumas regras. Quando uma instância (também conhecida como servidor e VMs) é criada, o nova-compute cria uma cadeia específica para a instância e configura regras para assegurar a conectividade da instância. Em relação aos IPs flutuantes, o OpenStack também usa algumas regras para fazê-los funcionar. Além disso, o grupo de segurança do OpenStack e suas regras são incorporadas pelas regras de iptables.


Fundamentos do OpenStack

O OpenStack — uma colaboração global de desenvolvedores e tecnólogos de computação em nuvem que produzem o sistema operacional de nuvem com padrão aberto para nuvens públicas e privadas — é um software livre e grátis liberado sob os termos da licença Apache. Os provedores de serviços de nuvem, empresas e organizações governamentais podem aproveitar o software grátis e com licença Apache para desenvolver ambientes de nuvem altamente escaláveis.

Atualmente, o OpenStack é formado por seis projetos de software principais:

  • Cloud Compute-Nova
  • Cloud Storage-Swift
  • Image Service-Glance (entrega e registro)
  • Identity Service-Keystone
  • Dashboard-Horizon
  • Network Connectivity-Quantum

Esses projetos, juntamente com um ecossistema vibrante de provedores de tecnologia e projetos futuros, proporcionam uma estrutura plugável e um sistema operacional para nuvens públicas e privadas.

Há mais de 10 binários no projeto Nova, dentre os quais três estão relacionados à conectividade de VMs:

  • O nova-api fornece o serviço de metadados para VMs.
  • O nova-compute configura o ambiente de rede para as VMs.
  • O nova-network configura o ambiente de rede para todo o ecossistema de nuvem, tarefas como alocação de IP, configurações de DHCP, etc.

O módulo Nova é formado principalmente por um conjunto de daemons de Python, mas requer vários componentes de sistemas nativos para bancos de dados, sistemas de mensagens e recursos de virtualização e se integra a eles. Usa um serviço de metadados especial para habilitar as instâncias de máquina virtual a recuperar dados específicos dela. As instâncias acessam o serviço de metadados em http://169.254.169.254.

Os metadados incluem chaves públicas de SSH (identificadas por nomes de chave/par quando um usuário solicita uma nova instância), dados do usuário (passados como o parâmetro user_data na chamada da API ou pelo sinalizador --user_data no comando de boot do Nova). O binário nova-api implementa o serviço de metadados.

O OpenStack é um conjunto complexo de componentes. Para saber mais sobre o sistema e o funcionamento de um dos outros componentes, siga os muitos recursos sobre o OpenStack na seção Recursos .

Antes de passar para as regras e cadeias no Nova, vamos dar uma olhada nos modos de endereçamento IP.


Endereçamento IP no Nova

Um endereço IP privado de cada nova-network disponível é designado automaticamente a todas as VMs. Esses endereços IP são chamados IPs corrigidos. Opcionalmente, é possível designar endereços IP públicos para as instâncias. O OpenStack usa o termo IP flutuante para fazer referência a um endereço IP (normalmente público) que pode ser incluído dinamicamente a uma instância virtual em execução.

Há várias estratégias disponíveis para implementar IPs corrigidos:

  • Modo simples
  • Modo DHCP simples
  • Modo DHCP VLAN
  • Nova-network com modo quantum

Modo simples

É o modo de rede mais simples. Cada instância recebe um IP corrigido do conjunto. Todas as instâncias são anexadas à mesma ponte (br100) por padrão. A ponte deve ser configurada manualmente. A configuração de rede é injetada na instância antes do boot. Neste modo, não há IP flutuante.

Modo DHCP simples

Como no modo simples, todas as instâncias são conectadas à mesma ponte. Nesse modo, o Nova configura um pouco mais: ele tenta fazer uma ponte para um dispositivo Ethernet (por padrão, eth0). Também executa dnsmasq como um recebimento de dhcpserver nessa ponte. As instâncias recebem seus IPs corrigidos executando um dhcpdiscover. Além disso, há o recurso de IP flutuante.

Modo DHCP VLAN

É o modo de rede padrão e suporta a maioria dos recursos. Para a instalação em várias máquinas, requer um comutador que suporte a identificação de VLANs gerenciadas pelo host. Nesse modo, o Nova cria uma VLAN e uma ponte para cada projeto (da mesma forma que um proprietário). O projeto obtém um intervalo de IPs que só podem ser acessados de dentro da VLAN. É necessário criar uma instância especial de VPN (com o nome de código "cloudpipe") para que os usuários acessem as instâncias nesse projeto. O Nova gera um certificado e uma chave para que o usuário acesse a VPN e a inicia automaticamente.

Nova-network com modo quantum

Nesse modo, também é possível lançar o servidor DHCP automaticamente, mas não há suporte para IP flutuante. Há um agente de quantum executando em cada host de cálculo para conectar instâncias virtuais à rede quantum. A topologia de rede pode ser muito sofisticada.

No Nova, um grupo de segurança é uma coleção nomeada de regras de acesso à rede, como políticas de firewall. Essas regras de acesso especificam qual tráfego recebido da rede deve ser entregue a todas as instâncias de VM do grupo; todos os outros tipos de tráfego recebido são descartados. Os usuários podem modificar as regras de um grupo a qualquer momento. As novas regras são impostas automaticamente a todas as instâncias em execução e as instâncias ativadas desse momento em diante. Pode-se pensar no grupo de segurança como se fosse um perfil ou uma função de segurança, como "webappserver".


Regras e cadeias de iptables

Conforme o descrito anteriormente, o iptable é um programa de aplicativo de espaço do usuário que permite a um administrador do sistema configurar as tabelas fornecidas pelo firewall do kernel Linux e as cadeias e regras que ele armazena.

Também já foi mencionado que é possível definir várias tabelas diferentes — Filter e NAT estão entre as tabelas usadas no OpenStack. Cada tabela contém várias cadeias integradas e também pode conter cadeias definidas pelo usuário. Cada cadeia é uma lista de regras que podem corresponder a um conjunto de pacotes. Cada regra especifica o que fazer com um pacote que corresponde — isso é conhecido como alvo, que pode ser um salto a uma cadeia definida pelo usuário na mesma tabela.

Deste ponto em diante, irei abordar as várias cadeias de chaves e regras.

Cadeias criadas quando o nova-network inicia

Figura 1. A classe NetworkManager conecta outras classes
A classe NetworkManager conecta outras classes

Como mostra a Figura 1, NetworkManager é uma classe grande que se conecta a muitas outras classes ou módulos. Entre essas classes ou módulos, há o linux_net. O linux_net contém um objeto IptablesManager , cujo método __init__() inicializa as cadeias definidas em um sistema OpenStack.

Figura 2. Inicializando as cadeias
Inicializando as cadeias

As tabelas de regras do filtro de pacotes IPv4 no kernel Linux têm algumas cadeias integradas, conforme foi mencionado anteriormente: PREROUTING, INPUT, FORWARD, OUTPUT e POSTROUTING. Em geral, um pacote que chaga ao host do Linux vai para a cadeia PREROUTING. Depois de passá-lo, o kernel toma uma decisão de roteamento. Se o pacote é para a máquina host do Linux, ele vai para a cadeia INPUT; em seguida, caso seja aceito, ele vai para o processo de destino. Se o pacote não é para a máquina host do Linux, ele vai para a cadeia FORWARD e, em seguida, para a cadeia POSTROUTING e depois sai da máquina host. Os pacotes gerados pelos processos locais vão primeiro para a cadeia OUTPUT e, em seguida, caso sejam aceitos, para a cadeia POSTROUTING.

Além dessas cadeias integradas, o sistema OpenStack cria outras cadeias ligadas ao sistema de cadeias. As cadeias do OpenStack consistem em dois tipos — desencapadas e encapadas.

Nova-filter-top e nova-postrouting-bottom são exemplos de cadeias desencapadas. A nova-filter-top é incluída no topo das cadeias FORWARD e OUTPUT. O nome dela não é encapado e, portanto, é compartilhado entre os vários trabalhadores do Nova. Destina-se a regras que devem permanecer no topo das cadeias FORWARD e OUTPUT. Está nos conjuntos de tabelas do IPv4 e do IPv6.

As cadeias de cor verde são exemplos de cadeias encapadas. O nome dessas cadeias tem o nome do processo como sufixo. Por exemplo, o nova-network cria a cadeia nova-network-PREROUTING.

No IPv4 e IPv6, as cadeias de filtros integradas INPUT, OUTPUT e FORWARD são encapadas, ou seja, a cadeia INPUT "verdadeira" tem uma regra que salta para a cadeia INPUT encapada, etc. Além disso, há uma cadeia encapada chamada local , para a qual se salta a partir de nova-filter-top.

No IPv4, as cadeias integradas de NAT PREROUTING, OUTPUT e POSTROUTING são encapadas da mesma forma que as cadeias de filtros integradas. Além disso, há a cadeia de sNAT e uma cadeia de float-sNAT, que são aplicadas depois da cadeia POSTROUTING.

Regras quando o nova-network inicia

A Figura 3 mostra parte do processo de inicialização do FlatDHCPManager. O método __init__() que constrói um objeto IptableManager para criar muitas cadeias do OpenStack já foi descrito. Portanto, vamos nos concentrar em init_host(). O método init_host() chama o método initialize() de LinuxNet3, que chama métodos de linux_net para configurar algumas regras de iptables em uma tabela de NAT.

Figura 3. Processo de inicialização de FlatDHCPManager
Processo de inicialização de FlatDHCPManager

(Uma versão maior da Figura 3.)

Vamos examinar essas regras.

Regra para o host dos metadados

Entre as regras criadas por init_host() de linux_net, uma delas é permitir que os IPs sob FLAGS.fixed_range para acessar o metadata_host (nesse caso, é 192.168.1.90).

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 192.168.1.90/32 -j ACCEPT

O ensure_metadata_ip() inclui 169.254.169.254/32 no dispositivo lo com o comando a seguir:

# ip addr add 169.254.169.254/32 scope link dev lo

Em seguida, metadata_forward() inclui uma regra de dNAT para rotear pacotes de 169.254.169.254/32 para metadata_host:

-A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 192.168.1.90:8775

Se o nova-network e o nova-api não estão executando no mesmo host, é necessário definir o metadata_host no host de nova-network para apontar para o host de nova-api.

Regra para acessar a dmz

FLAGS.dmz_cidr define uma lista de CIDRs (Classless Inter-Domain Routing) de dmz (rede de perímetro). Por padrão, é uma lista vazia. Neste caso, é 10.128.0.0/24. Portanto, a regra é:

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.128.0.0/24 -j ACCEPT

Regra para as VMs se conectarem entre si

Outra regra é garantir que as VMs com dois IPs corrigidos possam "conversar" entre si:

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -m conntrack ! --ctstate DNAT 
-j ACCEPT

Regra para o acesso fora de uma sub-rede corrigida

O método add_snat_rule() inclui uma regra de sNAT na sNAT de cadeia encapada da tabela NAT. É possível ver ip_range e FLAGS.routing_source_ip na Figura 3. O valor de ip_range é definido por FLAGS.fixed_range. Nesse caso, é 10.0.0.0/8. FLAGS.routing_source_ip é FLAGS.my_ip por padrão, que é adotado por padrão pela função flags._get_my_ip(). Nesse caso, FLAGS.my_ip é 192.168.1.90. Depois disso, você obtém uma regra como:

-A nova-network-snat -s 10.0.0.0/8 -j SNAT --to-source 192.168.1.90

Para que os IPs corrigidos acessem o exterior, é necessário criar uma rede que seja sub-rede de FLAGS.fixed_range. Dessa forma, com o gateway padrão apontado para um IP de br100 na máquina do nova-network, as VMs com os IPs dessa sub-rede podem acessar uma rede externa.

Regras para cada rede

Para configurar uma rede, o nova-network cria algumas regras na tabela de filtros. Para acionar a operação do nova-network em uma determinada rede, execute os comandos a seguir:

  1. Crie uma rede e configure o host:
    # ./bin/nova-manage network create mynet 10.10.10.0/24
  2. Faça o boot de um servidor:
    nova boot --image a3fb743d-42df-49ba-b9c4-8042ebbd344e --flavor 1 myserver

Depois de executar esses comandos, você tem estas regras:

  1. Permitir que um tráfego encaminhado passe pela ponte para que o IP em br100 possa atuar como gateway:
    -A nova-network-FORWARD -i br100 -j ACCEPT
    -A nova-network-FORWARD -o br100 -j ACCEPT
  2. Permitir que o tráfego do DHCP e do DNS vá para o processo local dnsmasq :
    -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT 
    -A nova-network-INPUT -i br100 -p tcp -m tcp --dport 67 -j ACCEPT
    -A nova-network-INPUT -i br100 -p udp -m udp --dport 53 -j ACCEPT
    -A nova-network-INPUT -i br100 -p tcp -m tcp --dport 53 -j ACCEPT

Observação: 67 é a porta de DHCP e 53 é a porta de DNS.

Regras no host do nova-compute

O módulo nova-compute também cria cadeias encapadas. Nessas cadeias, ele cria algumas regras na tabela de filtros. Vamos examiná-las.

Regras para permitir que o tráfego encaminhado passe pela ponte

Essas regras no host do nova-compute permitem que as VMs se conectem ao host do nova-network e às VMs em outros hosts de cálculo.

-A nova-compute-FORWARD -i br100 -j ACCEPT 
-A nova-compute-FORWARD -o br100 -j ACCEPT

Cadeia e regras para cada instância

Para cada instância, ele cria uma cadeia e algumas regras na tabela de filtros (Figura 4).

Figura 4. Cadeia e regras para cada instância
Cadeia e regras para cada instância

É possível ver:

  1. O nova-compute cria uma cadeia para cada instância. Na Figura 4, o nome da cadeia é nova-compute-inst-1.
  2. Todo o tráfego dirigido a essa instância — não importando se é encaminhado ou gerado a partir de um processo local — vai para a cadeia específica da instância.
  3. Todo o tráfego dos IPs da sub-rede na qual a instância reside é permitido.
  4. Todo o tráfego DHCP do servidor de DHCP especificado é permitido.
  5. Todos os outros tipos de tráfego são descartados.

nova-api

Ao iniciar, o nova-api cria uma regra na tabela de filtros para permitir que outros acessem o serviço de nova-api.

-A nova-api-INPUT -d 192.168.1.90/32 -p tcp -m tcp --dport 8775 -j ACCEPT

IPs flutuantes

Para ver como os IPs são implementados, primeiro associe um IP flutuante ao IP corrigido da instância. O IP corrigido da instância criada anteriormente é 10.10.10.2.

Crie um IP flutuante no conjunto padrão

Para criar IPs flutuantes no conjunto padrão:

# nova-manage floating create --ip_range=192.168.1.232/30

Para alocar um IP flutuante desse conjunto:

# Nova floating-ip-create

Você tem um IP de 192.168.1.233. Agora, designe-o para a instância que tem um ID de 8f773639-c04f-4885-9349-ac7d6a799843:

# nova add-floating-ip 8f773639-c04f-4885-9349-ac7d6a799843 192.168.1.233

Ligue o IP flutuante à interface pública

FLAGS.public_interface é usado para ligar IPs flutuantes. Depois de executar o comando nova add-floating-ip , é possível ver o IP flutuante a seguir sob public_interface:

# ip addr list dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 08:11:96:75:91:54 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.90/16 brd 192.168.255.255 scope global wlan0
    inet 192.168.1.233/32 scope global wlan0
    inet6 fe80::a11:96ff:fe75:9154/64 scope link 
       valid_lft forever preferred_lft forever

Regras na tabela NAT para IPs flutuantes

Depois que A instância obtém um IP flutuante no host do nova-network, estas regras se aplicam:

-A nova-network-OUTPUT -d 192.168.1.233/32 -j DNAT --to-destination 10.10.10.2
-A nova-network-PREROUTING -d 192.168.1.233/32 -j DNAT --to-destination 10.10.10.2 
-A nova-network-float-snat -s 10.10.10.2/32 -j SNAT --to-source 192.168.1.233

É possível ver que a regra de dNAT é usada para converter o IP flutuante para o IP corrigido da instância. Se um pacote chega a um host do nova-network com o IP flutuante como IP de destino, o IP de destino é convertido. Em seguida, você tem uma regra de sNAT que converte o tráfego do IP corrigido da instância para o IP flutuante. Já que o tráfego de todas as VMs para fora da rede fixa é apontado para o gateway, que é definido pelo processo dnsmasq do nova-network, com essa regra de sNAT, o tráfego que sai das VMs pode ser mascarado como se viesse do IP flutuante com êxito. Além disso, você tem uma regra de dNAT em uma cadeia OUTPUT encapada que permite que o processo local no nova-network acesse as VMs com IPs flutuantes.

Efetue ping nas VMs com IP flutuante

Para efetuar ping nas VMs com IPs flutuantes, é necessário ter mais algumas regras. Lembre-se de que, no host do nova-compute, você tem uma cadeia específica para cada instância; as regras nela só permitem o tráfego proveniente de IPs na sub-rede fixa. Se você efetuar ping em um IP flutuante, o tráfego será descartado por essas regras, já que o IP de origem do pacote de ping não está dentro da sub-rede fixa. Obviamente, é necessário incluir uma regra para permitir o tráfego de icmp.

Para incluir uma regra que permite o ping, use o conceito de regra de grupo de segurança do OpenStack:

# nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0

Depois disso, é possível ver que mais uma regra foi criada sob a cadeia específica da instância:

-A nova-compute-inst-1 -p icmp -j ACCEPT

Da mesma forma, é possível habilitar o SSH para as VMs com IP flutuante.


Conclusão

As regras de iptables são usadas amplamente pela rede do OpenStack. Seus conceitos de grupo de segurança e IPs flutuantes são apenas o início da utilização das regras de iptables. Mergulhe nos recursos a seguir para saber mais sobre o uso do ambiente de IaaS do OpenStack.

Recursos

Aprender

Obter produtos e tecnologias

  • Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na Ambiente de Simulação SOA aprendendo a implementar a Arquitetura Orientada a Serviços de forma eficiente.

Discutir

  • Participe da Comunidade do developerWorks. Entre em contato com outros usuários do developerWorks, enquanto explora blogs, fóruns, grupos e wikis orientados a desenvolvedores.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre, Cloud computing
ArticleID=830576
ArticleTitle=A Rede OpenStack
publish-date=08162012