Explorando os serviços de conectividade no Azure – parte I

Introdução

Nessa primeira parte faremos uma breve revisão dos conceitos básicos de redes e comunicação e como alguns deles se apresentam nos serviços de conectividade do Azure como IaaS.

Redes no Azure

Conceitualmente, uma rede de computadores pode ser definida como um conjunto de módulos processadores capazes de trocar informações e compartilhar recursos, interligados por um sistema de comunicação (meios de transmissão e protocolos). Uma rede de computadores baseia-se nos princípios de uma rede de informações, que, por meio de hardware e software, torna-a mais dinâmica para atender suas necessidades de comunicação.

No contexto de rede na nuvem, os serviços do Azure fornecem diversos recursos que podem ser usados combinados ou separadamente. Eles estão resumidos no diagrama abaixo:

Fundamentos gerais de redes de dados

Nessa seção, vamos abordar alguns conceitos importantes relacionados aos serviços de conectividade:

• Modelos de camada de rede;
• Conceitos sobre protocolos;
• Protocolo TCP e suas portas;
• Protocolo DNS;
• Protocolo IP.

1. Modelos de camada de rede e principais protocolos

1.1 Conceitos e funções dos protocolos

Os protocolos podem ser considerados como acordos ou regras que regem os processos de comunicação de dados. Eles normalmente são criados em um contexto descrito por um modelo ou padrão, não operando de maneira isolada, mas totalmente interligados, formando uma pilha de protocolos.

De forma resumida, os protocolos realizam as seguintes funções:

• Sincronizam a “conversa” entre duas pontas, para a criar a conexão;
• Detectam erros no canal de comunicação, além de retransmiti-los;
• Controlam o fluxo de informações.
• Atuam na recuperação de erros, executando endereçamento e retransmissões;

Em suma, citando SOUZA:

O protocolo é um programa carregado no computador e agregado às suas
interfaces de comunicação, com o objetivo básico de garantir que um dado
qualquer chegue a outro ponto da mesma forma que foi transmitido. A
integridade dos dados é mantida, independente do meio utilizado na
transmissão, já que o controle é feito
nas pontas. O protocolo coloca caracteres de controle no início e no final de
cada bloco de dados transmitido. Esses controles são conferidos ao chegarem
à outra ponta, pelo protocolo receptor. Se na transmissão ocorre algum
erro, o protocolo deve enviá-los novamente até que cheguem corretamente. (…)

O conceito de protocolo está vinculado diretamente aos conceitos de camada, serviço e interface.

Uma camada basicamente:

• Comunica-se somente com as camadas adjacentes;
• Usa serviços da camada inferior;
• Provê serviços à camada superior.

Já um serviço é um conjunto de operações que uma camada oferece à camada situada acima dela. Além disso, um serviço:

• Não informa nada sobre como essas operações são implementadas;
• Relaciona-se a uma interface entre duas camadas (camada inferior chamada de fornecedor e camada superior denominada de usuário do serviço).

Por sua vez a interface:

• Informa como os processos acima dela podem acessá-la;
• Especifica os parâmetros e os retornos esperados;
• Não trata sobre o funcionamento interno da camada.

1.2 Modelo de referência OSI

Para o entendimento do contexto dos conceitos supracitados, faz-se necessário o uso de modelos, como o modelo de referência OSI representado na figura abaixo:

O Modelo de Referência OSI (Open Systems Interconnection) é um conjunto de padrões ISO relativo à comunicação de dados.

Ele é a principal referência teórica ainda que não seja uma arquitetura de redes (não especifica os serviços e protocolos exatos que devem ser usados em cada camada; apenas informa o que cada camada deve fazer).

Resumidamente, as camadas do modelo OSI possuem as seguintes atribuições:

• Camada 7 (aplicação): comunicação do usuário por meio de aplicativos;
• Camada 6 (apresentação): formatação dos dados, compressão, a tradução e a criptografia da informação;
• Camada 5 (sessão): estabelecimento, gerenciamento e encerramento de sessões;
• Camada 4 (transporte): transporte das informações;
• Camada 3 (rede): endereçamento lógico e roteamento;
• Camada 2 (enlace): endereçamento físico e comutação;
• Camada 1 (física): padrões físicos.

Em suma, essas camadas definem o modo pelo qual as informações “descem” até os dispositivos de hardware e “sobem” até os aplicativos. Cada camada é independente da outra em suas funções e responsabilidades. As camadas permitem que o OSI seja um modelo modular, facilitando o projeto e o desenvolvimento das redes.

No modelo OSI podemos destacar os seguintes protocolos na camada de sessão:

• Telnet: aplicação de acesso remoto desenvolvida em 1969. O seu nome é derivado das palavras telephone network. Em 1977, foi liberada para uso público, tornando-se padrão mundial para acesso remoto;
• FTP/TFTP (File Transfer Protocol/ Trivial File Transfer Protocol): protocolos de transferência de arquivos, criados em 1980. O FTP é mais confiável e mais lento. O TFTP é um pouco menos confiável e mais rápido;
• SMTP (Simple Mail Transfer Protocol): protocolo padrão para envio de e-mails através da Internet;
• Criado nos anos de 1980, tem uma operação relativamente simples;
• POP3 (Post Office Protocol): protocolo utilizado no acesso remoto a uma caixa de correio eletrônico;
• HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure): protocolo criado nos anos de 1990, com a finalidade de comunicar dados pela Internet;
• DNS (Domain Name System): criado em 1984, o serviço DNS baseia-se na arquitetura cliente-servidor e tem a função primordial de traduzir nomes para endereços lógicos de rede;
• DHCP (Dynamic Host Configuration Protocol): criado em 1993, o serviço permite a configuração dinâmica de elementos conectados a uma rede.

E nas demais camadas temos os seguintes protocolos:

• TCP (Transmission Control Protocol): presente na camada de transporte. Atua no chamado transporte orientado a conexão, afirma-se que a transmissão é confiável porque a segmentação/reagrupamento ocorre de modo organizado. Além disso, estão presentes os mecanismos de janelamento, correção de erro, confirmação e controle de fluxo. Por esse motivo, ele é mais lento;
• UDP (User Datagram Protocol): também presente na camada de transporte. Atua no chamado transporte não orientado a conexão onde não existe a confiabilidade do anterior (ele efetua a segmentação/reagrupamento, mas não de modo organizado). Não há mecanismos de janelamento, correção de erro, confirmação e controle de fluxo (por isso é mais rápido);
• TCP/IP: presente na camada de rede. O protocolo em si origina outro modelo de referência, o Modelo TCP/IP.

1.3 Modelo de referência TCP/IP

O Modelo TCP/IP recebe o nome dos principais protocolos considerados no modelo de referência. Os protocolos são abertos e independentes de hardware ou software. Assim como o Modelo OSI, ele é dividido em camadas, onde cada camada é responsável por um grupo de tarefas. É um modelo mais simples que o modelo OSI, por ter menos camadas conforme ilustrado na figura abaixo:

A figura do Modelo TCP/ IP nos apresenta primeiramente a camada de aplicação (também conhecida como camada de processo). Ela lida com aplicativos e dispositivos de origem e destino, sendo a camada mais próxima do usuário.

Na camada de transporte (também conhecida como camada de host a host), temos o controle do fluxo de informações entre dispositivos, gerenciando o tipo de transmissão (orientada ou não orientada a conexão).

Na camada de internet (também conhecida como camada de rede) é executado o processo de roteamento de pacotes. O mais popular protocolo das redes de computadores, o protocolo IP, também integra essa camada.

A última camada é a camada de acesso responsável por gerenciar a transmissão da informação no meio físico. Ela reúne as funções das camadas de enlace e física do modelo OSI.

Sob o aspecto teórico, o modelo OSI é o mais citado e o mais didático para o aprendizado das redes de computadores. Não obstante, o modelo TCP/IP se aproxima mais da realidade e do funcionamento das redes.

Ainda, comparando-se os dois modelos de referência camada a camada, temos:

• No modelo TCP/IP as funcionalidades das camadas de aplicação, apresentação e sessão do OSI são agrupadas em apenas uma camada, denominada camada de aplicação do TCP/IP;
• As camadas de enlace e física do Modelo OSI são reunidas em apenas uma camada no modelo TCP/IP,  a camada de acesso;
• As camadas de transporte dos dois modelos são praticamente equivalentes, e a camada de rede do modelo OSI corresponde à camada de Internet do modelo TCP/IP.

2. Protocolo TCP e identificação das aplicações

Como a camada transporte identifica as diferentes aplicações?

Números de portas são usados para identificação de comunicações pelas diversas aplicações do usuário (autenticação em um marketplace, envio de um e-mail, consulta a um banco de dados, etc.).

Quando o dispositivo inicia uma comunicação, ele atribui um número de porta de origem e outro número de porta para o destino. Essa porta de origem identifica a comunicação na sua origem enquanto a porta do destino vai identificar a aplicação que vai receber a informação ao seu destino. No retorno da sua comunicação, esses números são trocados sistematicamente.

Abaixo a figura ilustra os intervalos de portas com suas respectivas atribuições:

A primeira faixa, de 0 a 1023, identifica as portas conhecidas, ou seja, números de portas para aplicações previamente estabelecidas.

A segunda faixa de números de portas, de 1024 a 49151, identifica as portas registradas. Estas identificam processos ou aplicações do usuário, ou seja, aplicações individuais do usuário final. As portas registradas também podem ser usadas dinamicamente, como uma porta de origem do dispositivo que inicia a comunicação.

A terceira faixa de números de portas, de 49152 até 65535, identifica as portas privadas ou dinâmicas. Esses números de portas são geralmente usados dinamicamente por aplicações do dispositivo que inicia a transmissão, apesar de que geralmente esses dispositivos podem usar portas registradas.

Para o protocolo TCP temos as seguintes portas:

• FTP: 20 e 21;
• SSH: 22;
• Telnet: 23;
• DNS: 53;
• TFTP: 69;
• SMTP: 25;
• HTTP: 80;
• HTTPS: 443;
• POP3: 110;
• IMAP: 143.

3. O DNS

Partindo de uma analogia da identificação utilizada por pessoas, pode-se dizer que existem várias maneiras de identificar as pessoas, através do nome, números de CPF etc. Cada uma dessas maneiras se enquadra em um contexto apropriado.

Da mesma maneira que pessoas podem ser identificadas os hosts conectados pela internet também podem. Nomes como www.contoso.com, www.tfteccloudeamaiorplatormadobrasil.com, etc. são fáceis de serem lembrados e, por isso, são bem aceitos por usuários de qualquer nível de habilidade com tecnologia. Porém, esse tipo de identificação fornece poucas informações sobre a localização desses hosts. Como os caracteres utilizados nos nomes são variáveis, torna-se complexo o processamento pelos roteadores, e, por essas razões, os hosts também são identificados por endereços IP.

Para que ocorra uma forma fluida de solução de endereço IP e identificação através dos nomes com caracteres, é necessário um serviço de diretório que execute a tradução dos nomes para os endereços IP. Essa é a função do DNS (Domain Name System – Sistema de Nome de Domínios).

O DNS pode ser visto como um grande banco de dados distribuído e integrado através de uma hierarquização de servidores de nomes, chamados de servidores DNS. Tem a assistência de um protocolo da camada de aplicação que permite que hosts consultem o banco de dados de informações.

As entidades, serviços e protocolos da camada de aplicação que utilizam o DNS são: HTTP, SMTP, FTP etc. Elas fazem uso do DNS para traduzir nomes de hosts, fornecidos por usuários, para o endereço IP.

Por exemplo, quando você digita no navegador de seu computador a URL www.contoso.com acontecem os seguintes passos:

• Passo 1: sua máquina executa o lado cliente da aplicação DNS;
• Passo 2: o navegador passa o nome do host www.contoso.com para o lado cliente da aplicação;
• Passo 3: o cliente DNS envia uma consulta para o servidor DNS contendo o endereço www.contoso.com;
• Passo 4: o servidor DNS envia uma resposta para o cliente contendo o IP do host desejado;
• Passo 5: depois de receber o endereço, o navegador abre uma conexão TCP com um processo HTTP localizado naquele endereço IP resolvido.

Pelos cinco passos supracitados pode-se observar que acontece uma troca de mensagens entre o servidor e o cliente DNS. Não obstante, existe algum atraso para as aplicações de internet que utilizam os serviços de DNS. Para mitigar esse problema, os endereços IP que são procurados com frequência são armazenados no cache de servidores de DNS mais próximos com intuito de diminuir o tráfego e o atraso.

Da mesma forma, como os protocolos HTTP, FTP e SMTP, o DNS também é um protocolo da camada de aplicação, só que seu papel é diferente dos demais: ele não é uma aplicação com a qual os usuários atuam diretamente. Em vez disso, ele fornece uma ação interna da internet, que é a tradução de nome-para-número IP.

Existem outros serviços pelos quais o DNS é o responsável:

• Apelidos dos hosts: por vezes, os hosts possuem algum nome complexo ou complicado, ou, ainda, mais de um nome. Um nome como zonaX.setor-Y.empresa.com.br pode ainda possuir dois ou mais apelidos, como www.empresa.com.br e empresa.com.br. Os apelidos são bem mais fáceis de serem lembrados, com isso, o DNS pode ser chamado para obter o nome real do host a partir de seu apelido;
• Apelido do servidor de correio: da mesma forma que no apelido dos hosts, o importante é que o nome de um e-mail seja simples de ser memorizado;
• Distribuição de cargas: o serviço DNS é requisitado para distribuir cargas em sites que são muito utilizados, como os motores de busca, por exemplo. Esse balanceamento é feito com o uso de vários servidores que usam IPs diferentes. Todo o conjunto de IPs desses servidores é associado ao nome real do site e armazenado na base de dados do DNS. Quando a máquina cliente do DNS solicita o endereço do site, o servidor de DNS oferece um conjunto de endereços IP a este associado, só que ele efetua um balanceamento na ordem dos endereços a cada solicitação. Esse balanceamento força a distribuição de tráfego pelos vários servidores replicados ao serviço.

4. IPv4

4.1 Características

O grande mérito desse protocolo é sua utilização ser permitida em qualquer tipo de rede física com interoperabilidade no nível da perfeição, entre as diversas tecnologias de rede existentes. Cada pacote criado pelo protocolo IPv4 em uma comunicação tem tratamento isolado durante toda a sua vida ao longo do percurso na rede. Esse é o motivo pelo qual o IPv4 é um protocolo em que inexiste conexão, em que os pacotes são tratados e avaliados a cada nó, ou seja, a cada equipamento por onde eles trafegam.

Esse protocolo foi especificado e alterado nas RFCs (Request for Comments) 791, 950, 919, 922, 1349 e 2474 (as RFCs podem ser conferidas em https://www.rfc-editor.org/).

Uma das características dos datagramas IPv4 podem ser entregues a seu destino não obedecendo a ordem de saída. O grande mérito dessa característica é graças às camadas superiores, como a de transporte, que podem reagrupar esses datagramas em sua ordem original e entregá‑las às camadas superiores em ordem cronológica adequada.

4.2. Endereçamento e cálculos

4.2.1 Endereçamento

Sobre o endereçamento, devemos considerar algumas premissas que são fundamentais como:

• Cada host é único em relação a seu endereço na rede, não podem existir dois endereços iguais no mesmo segmento;
• As redes podem ser divididas em sub‑redes para garantir um gerenciamento eficiente de sua interligação com redes diferentes;
• Possibilidade de envio de informações para diversos hosts a partir de um único pacote.

Uma característica não menos importante no endereçamento do IPv4 é o fato de ele ser hierárquico, ou seja, em uma rede, é possível identificar cada host de uma maneira única, e, com isso, ao juntarmos as redes, estas conseguem se identificar em parte ou em sua totalidade a cada equipamento nó conectado, a partir dos gateways e roteadores, e ainda entregar os pacotes ao seu destino corretamente.

Conforme ilustrado no esquema abaixo, o endereçamento IPv4 é classificado da seguinte forma:

4.2.2 Cálculo do endereçamento IPv4

Para o cálculo do protocolo IPv4 o endereço é representado por uma palavra de 32 bits divididos em quatro octetos.

Por exemplo, podemos ter:

1 1 0 0 0 0 0 0 . 1 0 1 0 1 0 0 0 . 0 1 1 0 0 1 0 0 . 0 0 0 0 0 0 0 1

Esses bits podem ser representados em seu formato binário (notação binária) ou em formato decimal (separados por pontos).

Sabendo que cada octeto possui 1 byte de tamanho e 1 byte possui 8 bits, a conversão decimal binária pode ser calculada pelo valor/referência da seguinte forma:

• Primeiro bit da esquerda para direita tem o valor decimal = 128.
• Segundo bit da esquerda para direita tem o valor decimal = 64.
• Terceiro bit da esquerda para direita tem o valor decimal = 32.
• Quarto bit da esquerda para direita tem o valor decimal = 16.
• Quinto bit da esquerda para direita tem o valor decimal = 8.
• Sexto bit da esquerda para direita tem o valor decimal = 4.
• Sétimo bit da esquerda para direita tem o valor decimal = 2.
• Oitavo bit da esquerda para direita tem o valor decimal = 1.

O primeiro octeto do exemplo tem o valor binário 11000000 e, somando os valores decimais dos bits ligados (com sinalização = 1) e desprezando os bits desligados (com sinalização = 0), temos o resultado da conta: 128 + 64 = 192, correspondente ao valor decimal desse octeto.

O segundo octeto tem o valor binário 10101000 e, somando os valores decimais dos bits ligados (com sinalização = 1) e desprezando os bits desligados (com sinalização = 0), temos o resultado da conta: 128 + 32 + 8 = 168, correspondente ao valor decimal desse octeto.

O terceiro octeto tem o valor binário 01100100 e, somando os valores decimais dos bits ligados (com sinalização = 1) e desprezando os bits desligados (com sinalização = 0), temos o resultado da conta: 64 + 32 + 4 = 100, correspondente ao valor decimal desse octeto.

O quarto octeto do exemplo tem o valor binário 00000001 e, somando os valores decimais dos bits ligados (com sinalização = 1) e desprezando os bits desligados (com sinalização = 0), temos o resultado da conta: 1, correspondente ao valor decimal desse octeto.

A figura abaixo resume o cálculo de conversão realizado:

4.2.3 Cálculo da máscara de rede

O endereço não estará completo se não for calculada a ocorrência de sua máscara de rede, que é a inserção de uma máscara de correspondência binária/decimal para a alocação do segmento lógico da rede, quantidade de hosts possíveis no segmento e identificação do endereço broadcast.

Voltando ao exemplo dado, agora com uma máscara classe C associada, temos:

192.168.100.1/24

A representação do número 24 após uma barra indica que este endereço faz parte de uma classe C.
Nessa classe os 24 bits mais relevantes (24 bits ligados; número 1) correspondem diretamente ao endereçamento da rede e os bits restantes (preenchidos com zeros) representam os hosts pertencentes a esta rede.

Assim teremos uma máscara em notação binária:

1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 0 0 0 0 0 0 0 0

Usando a conversão binária/decimal teremos a notação decimal:

255.255.255.0

4.2.4 Endereço de rede

Estabelecidas as notações binárias/decimais do endereço, podemos executar o cálculo para descobrir o endereço de rede (que não pode ser usado para hosts e nomina diretamente a qual rede pertence o host) e o endereço broadcast (que o endereço máximo desta classe, por onde acontece o broadcast desta rede e não pode ser usado para nominar hosts).

Antes do cálculo do endereço de rede precisamos relembrar da operação booleana AND entre dois binários como é exibido abaixo:

Vamos considerar dois números binários de 4 bits:

A = 1010
B = 1100

A operação AND booleana entre A e B é realizada bit a bit. Se ambos os bits forem 1, o resultado será 1. Caso contrário, o resultado será 0.
Portanto, a operação AND entre A e B seria:

A = 1010
B = 1100
AND = 1000
Neste caso, o primeiro bit de A e B é 1, então o primeiro bit do resultado é 1. Para os outros três bits, como pelo menos um dos bits é 0, o resultado é 0.

Agora sim podemos calcular o endereço de rede seguindo os seguintes passos:

1º) Para calcular o endereço da rede faça o AND BOOLEANO entre a máscara e o endereço IP do exemplo:

2°) Represente os 32 bits do IP proposto no exemplo:

3°) Execute o AND BOOLEANO entre o endereço e a máscara (até o limite de 24 bits do exemplo).

4°) Após atingir o limite da máscara, preencha os demais octetos com zeros;

5°) Representação decimal do endereo da rede:

1 9 2 . 1 6 8 . 1 0 0 . 0

4.2.5. Cálculo do broadcast

1°) Represente os 32 bits do endereço IP proposto no exemplo;

2°) Execute o AND BOOLEANO entre o endereço e a máscara (até o limite de 24 bits do exemplo);

3°) Após atingir o limite da máscara, preencha os demais octetos com um;

4°) Representação do broadcast decimal:

1 9 2 . 1 6 8 . 1 0 0 . 255

Já calculamos os endereços de rede e broadcast deste exemplo, agora vamos calcular a quantidade de hosts possíveis, para isto vamos usar a seguinte fórmula:

2ⁿ – 2 = hosts (onde n é a quantidade de zeros da máscara)

Aplicando a fórmula:

2⁸ – 2 = 254 hosts

Então podemos afirmar que neste exemplo é possível distribuir 254 endereços de hosts que são do endereço 192.168.100.1 até o endereço 192.168.100.254, lembrando sempre de excluir desta distribuição o endereço de rede, 192.168.100.0, e o endereço broadcast, 192.168.100.255.

Para os alunos TFTEC Prime o Raphael Andrade deu uma aula incrível sobre os conceitos básicos e é claro, partindo para o hands on na sequência:

5. Protocolo IPv5

O IPv6 foi projetado para ser o sucessor do IPv4. Ele tem maior espaço de endereços, que desta vez possuem 128 bits, fornecendo 340 undecilhões de endereços. Esse valor é escrito com o número 340 seguido de 36 zeros. Entretanto o IPv6 é muito mais do que números em quantidades maiores.

Quando o comitê IETF (Internet Engineering Task Force) iniciou seu desenvolvimento, aproveitou para corrigir muitas das limitações do IPv4 e ainda incluir novos aprimoramentos. Um bom exemplo é o ICMP versão 6, que inclui a resolução de endereço com uma configuração automática, que não é encontrada nos ICMP da versão 4.

Maiores detalhes podem ser conferidos no documento RFC de especificação do IPv6 (disponível em https://datatracker.ietf.org/doc/html/rfc2460#page-3).

Os cálculos aqui expostos têm fins didáticos. Na prática, em caso de necessidade de cálculos de endereçamentos, pode-se utilizar uma calculadora virtual como sugerido na figura abaixo:

Serviços de Conectividade Azure

Nessa seção vamos abordar conceitos presentes nos serviços de conectividade do Azure.

1. Rede Virtual do Azure

Uma rede virtual do Azure (Vnet, Virtual Network) é semelhante a uma rede tradicional on primeses onde é possível estabelecer:

• Comunicação dos recursos do Azure com a Internet;
• Comunicação entre os recursos do Azure;
• Comunicação com os recursos locais;
• Filtragem do tráfego de rede;
• Roteamento do tráfego de rede;
• Integração com serviços do Azure.

1.1 Espaço de endereço

Ao criar uma rede virtual, você deve especificar um espaço de endereço de IP privado e personalizado usando endereços públicos e privados (RFC 1918).

O Azure atribui um endereço IP particular aos recursos em uma rede virtual do espaço de endereço que você atribuiu.

Por exemplo, se você implantar uma VM em uma rede virtual com o espaço de endereço 10.0.0.0/16, é atribuído à VM um IP privado como 10.0.0.4:

Uma rede virtual tem escopo para uma única região/localização. No entanto, várias redes virtuais de regiões diferentes podem ser conectadas através do Emparelhamento de Rede Virtual.

Durante a criação de uma VNet, recomendamos que você use os intervalos de endereço enumerados no RFC 1918, que foram destinados pela IETF para espaços de endereço não roteáveis e privados:

• 10.0.0.0 – 10.255.255.255 (prefixo 10/8);
• 172.16.0.0 – 172.31.255.255 (prefixo 172.16/12);
• 192.168.0.0 – 192.168.255.255 (prefixo 192.168/16);

Adicionalmente, não é possível adicionar os seguintes intervalos de endereços:

• 224.0.0.0/4 (Multicast);
• 255.255.255.255/32 (Broadcast);
• 127.0.0.0/8 (Loopback);
• 169.254.0.0/16 (Link-local);
• 168.63.129.16/32 (DNS interno).

1.2 Custos, limites

Há certos limites com relação ao número de recursos do Azure que você pode implantar. A maioria dos limites de rede estão com recursos disponibilizados na magnitude máxima.

Alguns exemplos de limites:

• Redes virtuais: 1.000;
• Sub-redes por rede virtual: 3.000;
• Emparelhamentos de rede virtual por rede virtual: 500;
• Servidores DNS por rede virtual: 20;
• Grupos de segurança de aplicativo referenciados como origem/destino por regra NSG: 10.

Não há nenhum custo para usar a Rede Virtual do Azure. É gratuito. A Microsoft declara que encargos padrão são cobrados pelo uso de recursos como as VMs e outros produtos associados a infraestrura da VNet.

Os preços para outros recursos de redes podem ser obtidos pela calculdora online conforme ilustrado na figura abaixo:

Pode-se verificar o uso de recursos em relação aos limites (cotas) utilizando-se o PowerShell.

Abaixo os comandos para se obter o uso de recursos quando ao menos um recurso está implantado na região respectiva (no exemplo , região East US):

Get-AzNetworkUsage -Location eastus | Where-Object {$_.CurrentValue -gt 0} | Format-Table ResourceType, CurrentValue, Limit

A saída para o código encontra-se abaixo:

Caso seja realizado o mesmo comando utilizando-se uma região onde não exista recurso implantado, obtemos a mensagem de erro conforme abaixo:

A mesma consulta pode ser feita a partir do Portal Azure seguindo-se os passos descritos abaixo:

1°) Na tela inicial com usuário (a demonstração foi feita a partir de um usuário owner da subscription), selecione o menu Assinaturas:

2°) Na sequência selecione a assinatura desejada:

3°) Dentro da assinatura selecione a opção Uso + Cotas:

4°) E então selecione os filtros para obter os limites de uso:

5°) Após a seleção obtemos o seguinte resultado equivalente ao utlizado anteriormente através do PowerShell:

1.3 Zonas de disponibilidade

As redes virtuais e sub-redes abrangem todas as zonas de disponibilidade de uma região. Não é obrigatório dividi-las por zonas de disponibilidade para acomodar recursos zonais. Por exemplo, se você configurar uma VM zonal, não precisará levar em consideração a rede virtual ao selecionar a zona de disponibilidade para a VM. O mesmo é verdadeiro para outros recursos de zona.

1.4 Comunicação com recursos locais

Você pode conectar suas redes e computadores locais a uma rede virtual usando qualquer uma das seguintes opções:

• VPN (rede virtual privada) ponto a site: estabelecida entre uma rede virtual e um único computador em sua rede. Cada computador que deseja estabelecer conectividade com uma rede virtual precisa configurar suas conexões. Esse tipo de conexão é ótimo se você estiver começando a usar o Azure, ou para os desenvolvedores, pois exige pouca ou nenhuma alteração em uma rede existente. A comunicação entre seu computador e uma rede virtual é enviada via Internet, por um túnel criptografado;
• VPN site a site: estabelecida entre o dispositivo VPN local e um Gateway de VPN do Azure implantado em uma rede virtual. Esse tipo de conexão permite que qualquer recurso local que você autorizou acesse uma rede virtual. A comunicação entre o dispositivo VPN local e um gateway de VPN do Azure é enviada via Internet, por um túnel criptografado ;
• Azure ExpressRoute: estabelecida entre sua rede e o Azure por meio de um parceiro do ExpressRoute. Essa conexão é privada. O tráfego não passa pela Internet ;

1.5 Recomendações gerais

• Certifique-se de não sobrepor os espaços de endereço. Certifique-se de que seu espaço de endereço de sua rede virtual (bloco CIDR) não se sobrepõe aos outros intervalos de rede da sua organização;
• Suas sub-redes não devem abranger todo o espaço de endereço da rede virtual. Planeje com antecedência e reserve algum espaço de endereço para o futuro;
• Recomenda-se que você tenha uma quantidade pequena de redes virtuais grandes em vez de várias redes virtuais pequenas para evitar a sobrecarga de gerenciamento;
• Proteja suas redes virtuais atribuindo Grupos de Segurança de Rede (NSGs) às sub-redes delas.

Todos os recursos do Microsoft Azure são criados na região do Azure e assinatura. Um recurso só poderá ser criado a uma rede virtual que existir na mesma região e assinatura em que o recurso está. No entanto, é possível se conectar a redes virtuais que existem em diferentes assinaturas e regiões. É importante considerar as regiões do Azure ao projetar sua rede do Azure em relação à infraestrutura, aos dados, aos aplicativos e aos usuários finais.

2. NSG (Network Security Groups)

É possível usar um Grupo de Segurança de Rede (NSG) para filtrar o tráfego de rede entre os recursos de uma rede virtual.

Um grupo de segurança de rede contém regras de segurança que permitem ou negam o tráfego de rede de entrada ou de saída em relação a vários tipos de recursos do Azure. Para cada regra, você pode especificar origem e destino, porta e protocolo. Abaixo é ilustrada um NSG provisionado:

2.1 Tráfego de entrada

Em relação ao tráfego de entrada, o Azure processa as regras em um grupo de segurança de rede associado a uma sub-rede em primeiro lugar, se houver uma, e, em seguida, as regras em um grupo de segurança de rede associado ao adaptador de rede, se houver um. Esse processo também inclui o tráfego intra-sub-rede.

2.2 Tráfego de saída

Em relação ao tráfego de saída, o Azure processa as regras em um grupo de segurança de rede associado a um adaptador de rede em primeiro lugar, se houver um, e, em seguida, as regras em um grupo de segurança de rede associado à sub-rede, se houver uma. Esse processo também inclui o tráfego intra-sub-rede.

2.3 Tráfego entre sub-redes

É importante observar que as regras de segurança em um NSG associado a uma sub-rede podem afetar a conectividade entre as VMs dentro dela. Por padrão, as máquinas virtuais na mesma sub-rede podem se comunicar com base em uma regra NSG padrão que permite o tráfego entre sub-redes. Se você adicionar uma regra ao NSG1 que nega todo o tráfego de entrada e saída, a VM1 e a VM2 não poderão se comunicar.

A menos que você tenha um motivo específico, recomendamos que você associe um grupo de segurança de rede a uma sub-rede (subnet, como indicado na figura) ou a uma interface de rede (cenário menos ideal), mas não a ambos. Como as regras em um grupo de segurança de rede associado a uma sub-rede podem entrar em conflito com as regras em um grupo de segurança de rede associado a um adaptador de rede, você pode ter problemas de comunicação inesperados que exigem a solução de problemas.

2.4 Regras de segurança

As regras de segurança são avaliadas e aplicadas com base nas informações de cinco tuplas (origem, porta de origem, destino, porta de destino e protocolo). Você não pode criar duas regras de segurança com a mesma prioridade e direção. Um registro de fluxo é criado para as conexões existentes.

Comunicação é permitida ou negada com base no estado de conexão do registro de fluxo. O registro de fluxo permite que um grupo de segurança de rede seja com estado. Se você especificar uma regra de segurança de saída para algum endereço pela porta 80, por exemplo, não será necessário especificar uma regra de segurança de entrada para a resposta ao tráfego de saída. Você precisa especificar uma regra de segurança de entrada se a comunicação for iniciada externamente. 

O oposto também é verdadeiro: se o tráfego de entrada é permitido por uma porta, não é necessário especificar uma regra de segurança de saída para responder ao tráfego pela porta.

As conexões existentes podem não ser interrompidas quando você remove uma regra de segurança que habilitou o fluxo. A modificação das regras do grupo de segurança de rede afetará apenas as novas conexões. Quando uma regra é criada ou uma regra existente é atualizada em um grupo de segurança de rede, ela só se aplica a novas conexões. As conexões existentes não são atualizadas com as novas regras.

Considerações finais

No próximo artigo abordaremos a segunda parte desse assunto contemplando conceitos como IP público, IP privado e alguns cenários envolvendo hands on dos assuntos abordados.

Referências

COMER, D. E.Internetworking with TCP/IP. 4. ed. New Jersey: Prentice Hall, 2000.v. 1

Microsoft. Treinamento | Microsoft Learn.

RFC Editor disponível em » RFC Editor (rfc-editor.org)

SOUZA, L. B. Redes de computadores: guia total. São Paulo: Érica, 2011.

TORRES, G. Redes de computadores. 2. ed. Rio de Janeiro: Novaterra, 2016.