Отбрасывание исходящих пакетов / тайм-ауты - только с Azure
У меня проблема с отбрасыванием пакетов в сторонний центр обработки данных во Флориде, США. Проблема возникает только на виртуальных машинах 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
Как я уже упоминал в своем комментарии, вы фактически попадаете в аналогичный сценарий, описанный в Эта статья.
Я мог бы легко воспроизвести ваше поведение:
И я мог бы легко обойти проблему, добавив Общедоступный IP-адрес уровня экземпляра к ВМ:
Трудно сказать, что именно происходит, поскольку у нас нет одновременных захватов, но я понимаю, что пограничное устройство (потенциально брандмауэр) на удаленном сайте (www.oandp.com) поддерживает закрытые соединения на своем соединении. table дольше, чем это делает Azure, поэтому, когда Azure использует один из освобожденных (т. е. уже используемых) портов, а удаленная сторона все еще считает, что соединение закрыто не полностью, наши SYN-пакеты отбрасываются.
ILPIP применяет статический NAT или NAT «один в один», поэтому нет ни трансляции портов, ни повторного использования портов (если это не делает ваша ОС), что позволяет избежать проблемы.