Tengo un problema con los paquetes que caen a un centro de datos de terceros en Florida, EE. UU. El problema solo ocurre en máquinas virtuales de Azure, sin importar en qué centro de datos se encuentre la máquina virtual. He realizado las mismas pruebas simultáneamente desde otras redes que no son de Azure y no hay pérdida de paquetes. Las máquinas virtuales de Azure eran "básicas"/listas para usar, sin software cargado ni otras personalizaciones/cambios.
Ya hablé con los administradores de red en el centro de datos y los únicos paquetes que ven son los que no vencen el tiempo de espera; los paquetes cuyo tiempo de espera nunca llega a su firewall, por lo que suena como algo del lado de Azure (especialmente porque los paquetes caen o se agotan constantemente desde múltiples centros/regiones de datos de Azure). ¿Alguien sabe cómo podría solucionar esto?
La prueba que estaba ejecutando era un ping TCP continuo (usandotcping.exe) al puerto 80 (ya que ICMP está bloqueado en Azure):
tcping -t 216.155.111.149 80
tcping -t 216.155.111.151 80
tcping -t 216.155.111.146 80
Otra evidencia que respalda el hecho de que no es el centro de datos de un tercero es que puedo ejecutar el mismo ping TCP continuo desde la computadora de mi casa o del trabajo y no descartar ningún paquete. También configuro un túnel VPN desde la máquina virtual de Azure a una máquina virtual en un centro de datos que no es de Azure y no se descarta ningún paquete. El único momento en que se descartan los paquetes es cuando el tráfico sale a Internet/WAN directamente a través de Azure.
Sé que el siguiente paso serían algunas pruebas de ruta de seguimiento, pero como Azure bloquea ICMP, tuve que usarnmap para ejecutar una ruta de seguimiento TCP; A continuación se pegan las capturas de pantalla de esas pruebas.
nmap -sS -p 80 -Pn --traceroute 216.155.111.149
Respuesta1
Como mencioné en mi comentario, efectivamente estás llegando a un escenario similar al descrito enEste artículo.
Podría reproducir fácilmente tu comportamiento:
Y podría solucionar fácilmente el problema agregando unIP pública a nivel de instanciaa la máquina virtual:
Es difícil decir qué está pasando exactamente, ya que no tenemos capturas simultáneas, pero tengo entendido que el dispositivo de borde (potencialmente un firewall) en el sitio remoto (www.oandp.com) mantiene conexiones cerradas en su conexión. table durante más tiempo que Azure, por lo que cuando Azure usa uno de los puertos liberados (es decir, ya usados) y el lado remoto todavía piensa que la conexión no está completamente cerrada, nuestros paquetes SYN se descartan.
El ILPIP aplica una NAT estática o una "NAT uno a uno", por lo que no hay traducción ni reutilización de puertos (a menos que su sistema operativo lo haga), evitando así el problema.