У меня проблема с пакетами, падающими в сторонний центр обработки данных во Флориде, США. Проблема возникает только на виртуальных машинах Azure, независимо от того, в каком центре обработки данных находится виртуальная машина. Я провел те же тесты одновременно из других сетей, не относящихся к Azure, и потери пакетов не наблюдалось. Виртуальные машины Azure были «ванильными» / из коробки без загруженного программного обеспечения или других настроек / изменений.
Я уже говорил с администраторами сети в центре обработки данных, и единственные пакеты, которые они видят, это те, которые не имеют тайм-аута; пакеты, которые имеют тайм-аут, никогда не достигают их брандмауэра, так что это похоже на что-то на стороне Azure (тем более, что пакеты постоянно теряются/истекают тайм-аут из нескольких центров обработки данных Azure/регионов). Кто-нибудь знает, как я могу решить эту проблему?
Тест, который я проводил, представлял собой непрерывный TCP-пинг (с использованиемtcping.exe) на порт 80 (так как ICMP заблокирован в Azure):
tcping -t 216.155.111.149 80
tcping -t 216.155.111.151 80
tcping -t 216.155.111.146 80
Другим доказательством того, что это не сторонний центр обработки данных, является то, что я могу запустить тот же непрерывный TCP-пинг с моего домашнего компьютера / рабочего компьютера и не потерять ни одного пакета. Я также настроил туннельный VPN от виртуальной машины Azure к виртуальной машине в центре обработки данных не Azure, и ни одного пакета не теряется. Единственный раз, когда пакеты теряются, это когда трафик выходит в Интернет / WAN напрямую через Azure.
Я знаю, что следующим шагом будут некоторые тесты трассировки маршрута, но поскольку Azure блокирует ICMP, мне пришлось использоватьnmap для запуска маршрута трассировки TCP; ниже приведены скриншоты этих тестов.
nmap -sS -p 80 -Pn --traceroute 216.155.111.149
решение1
Как я уже упоминал в своем комментарии, вы фактически сталкиваетесь с ситуацией, аналогичной описанной вЭта статья.
Я мог бы легко воспроизвести ваше поведение:
И я мог бы легко обойти эту проблему, добавивПубличный IP-адрес уровня экземплярак виртуальной машине:
Трудно сказать, что именно происходит, поскольку у нас нет одновременных захватов, но, насколько я понимаю, периферийное устройство (потенциально брандмауэр) на удаленном сайте (www.oandp.com) сохраняет закрытые соединения в своей таблице соединений дольше, чем Azure, поэтому, когда Azure использует один из освобожденных (т. е. уже используемых) портов, а удаленная сторона все еще считает, что соединение не полностью закрыто, наши SYN-пакеты теряются.
ILPIP применяет статическую NAT или «один к одному NAT», поэтому не происходит трансляции портов или повторного использования портов (если только ваша ОС этого не делает), что позволяет избежать этой проблемы.