tl; dr У нас возникли проблемы, связанные с тем, что службы, стоящие за внутренним балансировщиком нагрузки Google Cloud Load Balancer, не могут ответить, если ответ превышает определенный размер. После некоторого tcpdump'ing и wirehark'ing, похоже, что наш экземпляр IPsec VPN типа «сеть-сеть» не может отправить ICMP-пакет «требуется фрагментация» обратно в GCLB, что приводит к зависанию ответа в цикле повторной передачи TCP.
подробности
У нас есть настройка туннеля IPSec между сайтами для GCP VPC и нашего локального шлюза. У нас есть несколько экземпляров виртуальной машины в этом VPC, и мы создали внутренний GCLB (Google Cloud Load Balancer) для поддержки этих сервисов. Однако мы заметили, что, когда ответ службы превышает определенный размер, curl запрос к GCLB (из нашей внутренней сети) зависает и, в конечном итоге, истекает.
Я выполнил tcpdump в нашем экземпляре VPN (экземпляр, который запускает ipsec) в GCP и записал трассировку, когда ответ "большой". Оказывается, VPN пытается отправить пакет, необходимый для фрагментации ICMP, обратно во внутренний GCLB, но «не получил маршрута к хосту». Я подтвердил, что существует маршрут к GCLB от экземпляра VPN, и я даже могу скрутить экземпляр GCLB в экземпляре VPN. Это заставило меня подозревать, что брандмауэр блокирует пакет ICMP.
Видеть скриншот здесь
Однако, играя с правилами брандмауэра GCP, я не смог применить правила брандмауэра к GCLB в сети. Кажется, что все правила брандмауэра применяются к экземплярам виртуальных машин.
Может ли кто-нибудь пролить свет на то, как это обойти?
Из темы кажется, что ваш вопрос: «Могут ли правила брандмауэра применяться к внутреннему GCLB?» ответ - нет. Правила брандмауэра применяются непосредственно к виртуальным машинам, а не к балансировщикам нагрузки. Внутренний балансировщик нагрузки - это балансировщик сквозной нагрузки. Для управления трафиком вы можете применять правила брандмауэра к самим виртуальным машинам, но вы не можете применять их «к балансировщику нагрузки». Вы можете проверить это документация для дополнительной информации.
После ознакомления с вашими данными кажется, что вы могли настроить виртуальную машину для запуска программного обеспечения IPSec, как вы упомянули: «Я сделал tcpdump в нашем экземпляре VPN (экземпляре, который запускает ipsec) в GCP». Я бы порекомендовал вместо этого использовать Cloud VPN, чтобы вы могли убедиться, что такие параметры, как MTU, установлены правильно. Существует так много мест, где в экземпляре могут быть неправильно настроены такие вещи, как MTU.
Обратите внимание, что максимальный MTU в GCP составляет 1460 байтов, но что MTU для трафика VPN должно быть меньше, чем с учетом инкапсуляции пакетов. Вы могли посмотреть на рекомендации для локальных шлюзов при использовании Cloud VPN.
Другое, что им следует сделать, - это предварительно фрагментировать трафик перед его отправкой по туннелю. Перед инкапсулированием трафик необходимо предварительно фрагментировать. Это конфигурация, которая требуется для однорангового устройства, подключенного к Cloud VPN. Вот документация ссылка на сайт для этого. Похоже, вы используете VPN на основе виртуальной машины, поэтому вам необходимо выполнить предварительную фрагментацию на их виртуальной машине и на их одноранговом шлюзе.
Я хотел бы упомянуть здесь, что Cloud VPN выполняет предварительную фрагментацию за вас, поэтому единственное, что нужно учитывать, - это одноранговое устройство.
