Tenho um problema com pacotes sendo enviados para um data center de terceiros na Flórida, EUA. O problema ocorre apenas em Máquinas Virtuais do Azure, independentemente do data center em que a VM está. Fiz os mesmos testes simultaneamente em outras redes não-Azure e não há perda de pacotes. As Máquinas Virtuais do Azure eram "vanilla"/prontas para uso, sem nenhum software carregado ou outras personalizações/alterações.
Já falei com os administradores de rede no data center e os únicos pacotes que eles estão vendo são aqueles que não atingem o tempo limite; os pacotes que atingem o tempo limite nunca atingem o firewall, portanto, parece algo do lado do Azure (especialmente porque os pacotes caem/tempo limite consistentemente de vários data centers/regiões do Azure). Alguém sabe como posso resolver isso?
O teste que eu estava executando era um ping TCP contínuo (usandotcping.exe) para a porta 80 (já que o ICMP está bloqueado no Azure):
tcping -t 216.155.111.149 80
tcping -t 216.155.111.151 80
tcping -t 216.155.111.146 80
Outra evidência que apóia o fato de que não é um data center de terceiros é que posso executar o mesmo ping TCP contínuo no meu computador doméstico/computador de trabalho e não descartar pacotes. Também configurei uma VPN de túnel da VM do Azure para uma VM em um data center não-Azure e nenhum pacote foi descartado. A única vez que os pacotes são descartados é quando o tráfego sai para a Internet/WAN diretamente via Azure.
Eu sei que o próximo passo seria alguns testes de rastreamento de rota, mas como o Azure bloqueia o ICMP, tive que usarnmap para executar uma rota de rastreamento TCP; coladas abaixo estão as capturas de tela desses testes.
nmap -sS -p 80 -Pn --traceroute 216.155.111.149
Responder1
Como mencionei em meu comentário, você está efetivamente enfrentando um cenário semelhante ao descrito emEste artigo.
Eu poderia facilmente reproduzir seu comportamento:
E eu poderia facilmente contornar o problema adicionando umIP público em nível de instânciapara a VM:
É difícil dizer exatamente o que está acontecendo, pois não temos capturas simultâneas, mas meu entendimento é que o dispositivo de borda (potencialmente um firewall) no site remoto (www.oandp.com) mantém conexões fechadas em sua conexão tabela por mais tempo do que o Azure, portanto, quando o Azure usa uma das portas liberadas (ou seja, já usadas) e o lado remoto ainda pensa que a conexão não está totalmente fechada, nossos pacotes SYN são descartados.
O ILPIP aplica um NAT estático ou "um para um NAT", portanto não há tradução de porta nem reutilização de porta (a menos que seu sistema operacional faça isso), evitando assim o problema.