Conexão Pendente

Este tópico abrange um dos problemas mais comuns observados entre a sua rede na nuvem e a rede local: uma conexão pendente, embora você possa acessar hosts da conexão por ping.

Resumo de Problemas e Soluções

Sintoma: Sua VCN (rede virtual na nuvem) se conecta à sua rede on-premises existente usando uma VPN Site a Site ou o Oracle Cloud Infrastructure FastConnect. Os hosts de um lado da conexão podem executar ping nos hosts do outro lado, mas o tráfego normal que usa a conexão é interrompido. Por exemplo:

  • Você consegue usar SSH para acessar um host na conexão. No entanto, após você fazer log-in no host, a conexão se mostra pendente.
  • Você consegue iniciar uma conexão VNC (Virtual Network Computing), mas a sessão é se mostra pendente.
  • Você consegue iniciar um download SFTP, mas o download é desligado.

Problema geral: o mecanismo PMTUD (Path Maximum Transmission Unit Discovery) provavelmente não está funcionando em um ou em ambos os lados da conexão. Ele deve estar funcionando nos dois lados da conexão para que ambos possam identificar se estão tentando enviar pacotes muito grandes para a conexão e fazer os ajustes necessários. Para obter uma breve visão geral do parâmetro MTU (Maximum Transmission Unit) e do mecanismo PMTUD, consulte Visão Geral do parâmetro MTU e Visão Geral do Mecanismo PMTUD.

Soluções para corrigir o mecanismo PMTUD:

O diagrama a seguir mostra um exemplo de cenário com a rede on-premises conectada à sua VCN pela VPN Site a Site e tem callouts que representam cada parte da solução.

Esta imagem mostra as diversas partes da solução utilizada para corrigir a conexão pendente
  1. Certifique-se de que os seus hosts estejam usando o mecanismo PMTUD: Se os hosts da sua rede on-premises não usarem o mecanismo PMTUD (ou seja, caso eles não tenham o flag Não Fragmentar definido nos pacotes), eles não poderão descobrir se estão enviando pacotes muito grandes para a conexão. Por padrão, as suas instâncias no lado Oracle da conexão utilizam o mecanismo PMTUD. Não altere essa configuração nas instâncias. Além disso, verifique se os servidores têm uma regra de firewall para permitir ICMP do tipo 3 código 4.
  2. Verifique se as listas de segurança da VCN e os firewalls da instância permitem mensagens ICMP do tipo 3 código 4: Quando o mecanismo PMTUD estiver em uso, os hosts de envio receberão uma mensagem ICMP especial se enviarem pacotes muito grandes para a conexão. Após o recebimento da mensagem, o host poderá atualizar dinamicamente o tamanho dos pacotes para que se ajustem à conexão. No entanto, para que suas instâncias recebam essas mensagens ICMP importantes, você deve configurar as listas de segurança da sub-rede na VCN e os firewalls da instância para aceitá-las.

    Dica

    Se você estiver usando regras de lista de segurança com monitoramento de estado (para tráfego TCP, UDP ou ICMP), não precisará garantir que sua lista de segurança tenha uma regra explícita para permitir mensagens ICMP tipo 3 código 4 porque o serviço Networking rastreia as conexões e permite automaticamente essas mensagens. As regras sem monitoramento de estado requerem uma regra explícita na lista de segurança de entrada para mensagens ICMP do tipo 3 código 4. Confirme se os firewalls da instância foram configurados corretamente.

    Para verificar se um host está recebendo as mensagens, consulte Localizando Onde o Mecanismo PMTUD Está Interrompido.

  3. Certifique-se de que seu roteador on-premises reconheça o flag Não Fragmentar: Se o roteador não reconhecer o flag e, portanto, ignorar o uso do mecanismo PMTUD, ele enviará pacotes fragmentados para as instâncias na VCN. Isso não é o que você deseja ver (consulte Por que Evitar a Fragmentação?). Muito provavelmente, as listas de segurança da VCN estão configuradas de forma a reconhecer somente o fragmento inicial e eliminar os demais fragmentos, fazendo com que a conexão seja interrompida. Em vez disso, o seu roteador deve usar o mecanismo PMTUD e respeitar o flag Não Fragmentar para determinar o tamanho correto dos pacotes não fragmentados a serem enviados pela conexão.

Continue lendo para obter uma breve visão geral do parâmetro MTU e do mecanismo PMTUD e saber como verificar se o mecanismo PMTUD está funcionando em ambos os lados da conexão de rede.

Por que Evitar a Fragmentação?

Talvez você esteja se perguntando por que deve evitar a fragmentação. Primeiro porque a fragmentação afeta negativamente o desempenho do aplicativo. A fragmentação requer remontagem dos fragmentos e retransmissão dos fragmentos perdidos. A remontagem e a retransmissão requerem tempo e recursos da CPU.

Segundo porque somente o primeiro fragmento contém informações sobre as portas de origem e de destino. Isso significa que os firewalls ou as listas de segurança da sua VCN eliminam os outros pacotes, porque geralmente eles são configurados para avaliar as informações da porta. Para que a fragmentação funcione com os seus firewalls e as suas listas de segurança, você deverá configurá-los para serem mais permissivos do que o normal, o que não é desejável.

Visão Geral do Parâmetro MTU

As comunicações entre dois hosts em uma rede IP (Internet Protocol) usam pacotes. Cada pacote tem endereços IP de origem e de destino e um payload de dados. Cada segmento de rede entre os dois hosts tem um parâmetro MTU (Maximum Transmission Unit) que representa o número de bytes que um único pacote pode transportar.

O tamanho padrão do parâmetro MTU da Internet é 1500 bytes. Isso também vale para a maioria das redes domésticas e para muitas redes corporativas (e suas respectivas redes Wi-Fi). Alguns data centers, incluindo os do Oracle Cloud Infrastructure, têm um parâmetro MTU maior. Por padrão, todas as instâncias de computação do OCI usam uma MTU de 9000. Em um host do Oracle Linux 8, você pode usar o comando ip address show para exibir a MTU da conexão de rede desse host (ou usar ip link no Red Hat Linux). Como exemplo, veja a saída de uma instância do Oracle Linux 8 (o MTU é destacado em itálico vermelho):

ip address show <interface-x>
<interface-x>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:10 brd ff:ff:ff:ff:ff:ff
    ... 

Para comparação, esta é a saída de um host do Oracle Linux 8 conectado a uma rede corporativa:

ip address show <interface-y>
<interface-y>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:20 brd ff:ff:ff:ff:ff:ff
    ...

Observe que o seu parâmetro MTU é 1500 bytes, o mais comum.

Se o host for conectado por meio de uma VPN corporativa, o parâmetro MTU será ainda menor, pois o túnel da VPN deverá encapsular o tráfego dentro de um pacote IPSec e enviá-lo pela rede local. Por exemplo:

ip address show <interface-z>
<interface-z>: flags=81d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,MULTICAST> mtu 1300 
... 

Como os dois hosts identificam o tamanho máximo que um pacote pode ter para poder ser enviado entre eles? Para muitos tipos de tráfego de rede, como HTTP, SSH e FTP, os hosts usam o TCP para estabelecer novas conexões. Durante o handshake inicial de três vias entre dois hosts, cada um envia o parâmetro MSS (Maximum Segment Size) para identificar o tamanho máximo que seus respectivos payloads podem ter. Esse parâmetro é menor que o parâmetro MTU. (O TCP é executado dentro do IP (Internet Protocol) e por isso é chamado de TCP/IP. Os segmentos representam para o TCP o que os pacotes representam para o IP.)

Usando o aplicativo tcpdump, você pode ver o valor do parâmetro MSS compartilhado durante o handshake. Este é um exemplo de tcpdump (com o parâmetro MSS destacado em vermelho itálico):

12:11:58.846890 IP 192.168.0.25.22 > 10.197.176.19.58824: Flags [S.], seq
2799552952, ack 2580095593, win 26844, options [mss 1260,sackOK,TS val
44858491 ecr 1321638674,nop,wscale 7], length 0

O pacote anterior é proveniente de uma conexão SSH com uma instância em um laptop conectado com uma VPN corporativa. A rede local que o laptop usa para a conexão com a internet tem uma MTU de 1.500 bytes. O túnel da VPN impõe um parâmetro MTU de 1300 bytes. Em seguida, ao tentar a conexão SSH, o TCP (em execução dentro da conexão IP) informa à instância do Oracle Cloud Infrastructure que suporta segmentos TCP menores ou iguais a 1.260 bytes. Usando uma conexão VPN corporativa, o laptop conectado com a VPN geralmente tem os menores parâmetros MTU e MSS em comparação com todos os elementos com que está se comunicando pela internet.

Um caso mais complexo é quando os dois hosts têm um parâmetro MTU maior que um link de rede intermediário entre eles que não está diretamente conectado com um deles. O diagrama a seguir ilustra um exemplo.

Esta imagem mostra os diferentes níveis de MTU em diferentes pontos na conexão de rede geral

O exemplo mostra dois servidores, cada um conectado diretamente à sua própria rede roteada que suporta um parâmetro MTU de 9000 bytes. Os servidores estão em diferentes data centers. Cada data center é conectado com a internet, que suporta um parâmetro MTU de 1.500 bytes. Um túnel IPSec da VPN Site a Site conecta os dois data centers. Esse túnel cruza a internet; portanto, a parte interna do túnel tem um parâmetro MTU menor que a internet. Nesse diagrama, o parâmetro MTU é1380 bytes.

Se tentarem se comunicar (com SSH, por exemplo), durante o handshake de três vias, os dois servidores concordarão com um parâmetro MSS de aproximadamente 8960. A conexão SSH inicial poderá ser bem-sucedida porque os tamanhos máximos dos pacotes durante a configuração da conexão SSH inicial geralmente são menores que 1380 bytes. Quando um lado tenta enviar um pacote maior que o menor link entre dois pontos finais, o mecanismo PMTUD (Path MTU Discovery) torna-se crítico.

Visão Geral do Mecanismo PMTUD

O parâmetro MTU (Path MTU Discovery) é definido na RFC 1191 e na RFC 8899. Esse parâmetro funciona exigindo que os dois hosts que estão se comunicando definam um flag Não Fragmentar nos pacotes que cada um envia. Se um pacote de um desses hosts chegar a um roteador em que a interface de saída (ou de envio) tem um parâmetro MTU menor que o tamanho do pacote, o roteador eliminará esse pacote. O roteador também retorna uma mensagem ICMP do tipo 3 código 4 ao host. Essa mensagem diz especificamente "Destino Inacessível, Fragmentação Necessária e Opção Não Fragmentar Definida" (verifique a RFC 792). Efetivamente, o roteador informa ao host: "Você me disse para não fragmentar pacotes muito grandes, e este é muito grande. Não vou enviá-lo." O roteador também informa ao host os pacotes de tamanho máximo permitidos por essa interface de saída. O host de envio ajusta o tamanho de seus pacotes de saída para que sejam menores que o valor fornecido pelo roteador na mensagem.

Este exemplo mostra o resultado quando uma instância tenta executar ping de um host (203.0.113.2) pela internet com um pacote de 8.000 bytes e o flag Não Fragmentar definido (ou seja, com o parâmetro PMTUD em uso). A mensagem ICMP retornada é destacada em vermelho itálico:

ping 203.0.113.2 -M do -s 8000

PING 203.0.113.2 (203.0.113.2) 8000(8028) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1500)

A resposta é exatamente o que você deve esperar. O host de destino está na internet, que tem um parâmetro MTU de 1500 bytes. Mesmo que a conexão de rede local do host de envio tenha um parâmetro MTU de 9000 bytes, o host não poderá acessar o host de destino com o pacote de 8000 bytes e receberá uma mensagem ICMP correspondente. O parâmetro PMTUD está funcionando corretamente.

Para comparação, este é o mesmo ping, mas o host de destino está em um túnel IPSec da VPN Site a Site:

ping 192.168.6.130 -M do -s 8000
PING 192.168.0.130 (192.168.0.130) 8000(8028) bytes of data.
From 192.0.2.2 icmp_seq=1 Frag needed and DF set 

(mtu = 1358)

Nesse caso, o roteador da VPN percebe que para enviar esse pacote ao destino, a interface de saída é um túnel de VPN. Esse túnel percorre a internet; portanto, deve caber no link MTU de 1500 bytes da internet. Como resultado, a parte interna do túnel só permite pacotes de até 1.360 bytes (que o roteador diminuiu para 1.358, o que pode causar problemas).

Localizando Onde o Mecanismo PMTUD Está Interrompido

Se o parâmetro PMTUD não estiver funcionando em algum lugar ao longo da conexão, será necessário descobrir por que e onde isso está acontecendo. Normalmente, é porque o pacote ICMP do tipo 3 código 4 (proveniente do roteador com o link restrito que não se ajusta ao pacote) nunca retorna ao host de envio. Isso pode acontecer se algo bloquear esse tipo de tráfego entre o host e o roteador e em qualquer um dos lados do túnel da VPN (ou outro link MTU restrito).

Tentar Executar Ping em Cada Lado da Conexão

Para diagnosticar e solucionar problemas no mecanismo PMTUD interrompido, você deverá determinar se o mecanismo PMTUD está funcionado em cada lado da conexão. Nesse cenário, vamos assumir que a conexão usa a VPN Site a Site.

Como fazer solicitações de ping: assim como em Visão Geral de PMTUD, faça uma solicitação de ping para um host do outro lado da conexão com um pacote que você sabe que é muito grande para caber no túnel de VPN (por exemplo, 1500 bytes ou maior). Dependendo de qual sistema operacional o host de envio utiliza, talvez seja necessário formatar o comando de ping de maneira um pouco diferente para determinar se o flag Não Fragmentar está definido. Para o Ubuntu e o Oracle Linux, use o flag -M com o comando de ping.

Aqui estão as informações de ajuda incorporadas sobre o flag -M:

-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do
(prohibit fragmentation, even local one), want (do PMTU discovery, fragment
locally when packet size is large), or dont (do not set DF flag).

Um exemplo de ping (com o flag -M e a mensagem ICMP resultante destacada em vermelho itálico)

ping -M do

 -s 1500 192.168.6.130
PING 192.168.0.130 (192.168.0.130) 1500(1528) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1358)

Bom: o PMTUD Funciona

Se o resultado incluir a linha "From x.x.x.x icmp_seq=1 Frag necessária e o conjunto DF (mtu = xxxx)", isso significa que o PMTUD está funcionando no lado do túnel em questão. Observe que o endereço de origem da mensagem ICMP é o endereço IP público do túnel de onde o tráfego está tentando sair (como 203.0.113.13 no exemplo anterior para Ubuntu).

Além disso, execute ping do outro lado da conexão para confirmar se o mecanismo PMTUD está funcionando nesse lado. Ambos os lados da conexão devem reconhecer quando um túnel entre eles não consegue se ajustar a pacotes grandes.

Negativo: se você estiver testando o seu lado da conexão e o ping for bem-sucedido

Se você estiver enviando o ping de um host na sua rede on-premises e o ping for bem-sucedido, isso provavelmente significa que o roteador de borda não está reconhecendo o flag Não Fragmentar. Em vez disso, o roteador está fragmentando o pacote grande. O primeiro fragmento chega ao host de destino. Isso demonstra que o ping foi bem-sucedido, mas é falso. Se você tentar fazer mais do que apenas executar ping, os fragmentos após a primeira eliminação e a conexão serão suspensos.

Verifique se a configuração do roteador reconhece o flag Não Fragmentar. A configuração padrão do roteador deve reconhecer esse flag, mas alguém pode ter alterado o padrão.

Negativo: se você estiver testando o lado VCN da conexão e não vir a mensagem ICMP

Se, ao fazer o teste com base no lado VCN da conexão, você não vir a mensagem ICMP na resposta, provavelmente é porque há algo eliminando o pacote ICMP antes de ele chegar à sua instância.

Pode haver dois problemas:

  • Lista de segurança: a lista de segurança do serviço Networking talvez não tenha uma regra de entrada que permita a chegada de mensagens ICMP do tipo 3 código 4 à instância. Isso só será um problema se você estiver usando regras de lista de segurança sem monitoramento de estado. Se você estiver usando regras com monitoramento de estado, as suas conexões serão rastreadas, e a mensagem ICMP será automaticamente permitida sem a necessidade de uma regra de lista de segurança específica que possibilite isso. Se você estiver usando regras sem monitoramento de estado, certifique-se de que a sub-rede da instância tenha uma lista de segurança com uma regra de entrada permitindo o tráfego ICMP do tipo 3 código 4 da origem 0.0.0.0/0 e de qualquer porta de origem. Para obter mais informações, consulte Listas de Segurança e especificamente Atualizando Regras em uma Lista de Segurança.
  • Firewall da instância: as regras de firewall da instância (definidas no sistema operacional) talvez não tenham uma regra que permita a chegada de mensagens ICMP do tipo 3 código 4 à instância. Especificamente para uma instância do Linux, configure o iptables ou o firewalld para permitir as mensagens ICMP do tipo 3 código 4.

Evitando a Necessidade de PMTUD

A Oracle recomenda o uso do mecanismo PMTUD. No entanto, em algumas situações, é possível configurar servidores de modo que eles não precisem utilizar esse mecanismo. Considere o caso das instâncias da sua VCN que estão se comunicando por meio da VPN Site a Site com os hosts da sua rede on-premises. Você já conhece o intervalo de endereços IP da sua rede local. É possível adicionar uma rota especial às instâncias para especificar o parâmetro MTU máximo a ser usado durante a comunicação com hosts nesse intervalo de endereços. A comunicação entre instâncias dentro da VCN ainda usa um parâmetro MTU de 9000 bytes.

As informações a seguir mostram como definir essa rota em uma instância Linux.

A tabela de roteamento padrão na instância normalmente tem duas rotas: a rota padrão (para o gateway padrão) e uma rota local (para a sub-rede local). Por exemplo:

ip route show
default via 10.0.6.1 dev ens3
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Você pode adicionar outra rota apontando para o mesmo gateway padrão, com uma faixa de endereços da rede on-premises e um parâmetro MTU menor. Por exemplo, no comando a seguir, a rede on-premises é 1.0.0.0/8, o gateway padrão é 10.0.6.1, e o tamanho máximo do MTU é 1.300 para os pacotes enviados à rede on-premises.

ip route add 1.0.0.0/8 via 10.0.6.1 mtu 1300

A tabela de roteamento atualizada é semelhante a:

ip route show
default via 10.0.6.1 dev ens3
1.0.0.0/8 via 10.0.6.1 dev ens3  mtu 1300
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Na VCN, a comunicação entre as instância continua a usar um parâmetro MTU igual a 9000. No entanto, a comunicação com a rede local usa um máximo de 1300. Esse exemplo pressupõe que nenhuma parte da conexão entre a rede on-premises e a VCN use um parâmetro MTU menor que 1.300.

Importante

Os comandos anteriores não persistirão se você reinicializar a instância. Você pode tornar a rota permanente, adicionando-a a um arquivo de configuração no sistema operacional. O Oracle Linux, por exemplo, usa um arquivo específico da interface, chamado /etc/sysconfig/network-scripts/route-<interface>. Para obter mais informações, consulte a documentação da sua variante do Linux.