Поды GKE потеряли доступ к VPN после 1.14: два способа исправить источник

После 1.14 поды приходят в VPN со своими адресами, поэтому партнёры отбрасывают ответы. Выберите контракт источника и настройте nonMasqueradeCIDRs под него.

Приходит обновление, и системы на другой стороне туннеля начинают отклонять трафик подов, который работал неделю назад. Туннель поднят, правила межсетевого экрана не тронуты, и никто не редактировал политику партнёра. То, что изменилось, не видно в журналах кластера: адрес источника, который эти системы видят теперь. Этот разрыв объясняет сбой, который выглядит как отказ сети, а ведёт себя как проблема прав.

Есть два правильных ответа, и они ведут в разные места. Выберите контракт источника, прежде чем править ConfigMap.

Правило по умолчанию, которое перестали устанавливать

Ранние выпуски GKE устанавливали правило masquerade, которое заменяло источники подов адресом узла всякий раз, когда назначение оказывалось вне 10.0.0.0/8. VPN-шлюз внутри этого диапазона видел адрес пода, а всё более далёкое выглядело как приходящее от узла. Партнёры строили списки разрешений и обратные маршруты вокруг адресов узлов, потому что именно это они наблюдали.

Более поздние выпуски перестали устанавливать это правило по умолчанию. Трафик подов теперь приходит на шлюз с адресами подов, каким бы ни было назначение. Партнёр, который маршрутизирует только адреса узлов, отбрасывает ответы, и ни одна сторона не пишет полезной записи в журнал. Запрос может даже успешно выполниться на дальнем конце, и именно это делает сбой запутанным для поиска.

Ничего не сломано в смысле мёртвого компонента. Две стороны просто не согласны, какой источник законен.

Выберите источник, который партнёр должен видеть

Сохранение адресов подов — более точный контракт. Дальняя сторона видит рабочую нагрузку, породившую трафик, журналы остаются честными, и политика для каждого пода становится возможной. Цена в том, что партнёр должен нести префикс подов.

Сохранение адресов узлов — более дешёвый контракт. Включите masquerade для этого назначения снова, и партнёр продолжит видеть адрес, которому уже доверяет.

Один вопрос решает между ними: что партнёр делает с источником? Если он пишет журнал, применяет политику по источнику или требует узкой обратной маршрутизации, адреса подов оправдывают дополнительную настройку. Если ему нужно только отправлять ответы, masquerade стоит меньше и ничего не требует от другой стороны. Любой выбор защитим, пока обе команды его запишут.

Третий вариант обычно ошибка: маскировать всё и потерять возможность приписывать трафик. Избегайте его, если только партнёр действительно не может маршрутизировать ничего, кроме адресов узлов.

Направьте nonMasqueradeCIDRs на реальные диапазоны

GKE запускает ip-masq-agent в kube-system, и его ConfigMap перечисляет назначения, которые обходят masquerade. Чтобы сохранить источники подов в сторону туннеля, диапазон подов, подсеть узлов и локальный префикс — все входят в этот список.

Замените примерные значения диапазонами из вашего собственного кластера. Не делайте список шире, чем требует необходимость, потому что каждая дополнительная запись меняет то, что видит другое назначение. Три записи ниже обозначают сеть подов, подсеть узлов и префикс за туннелем:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Запись 0.0.0.0/0 отключает masquerade для всех назначений, что меняет то, как несвязанные рабочие нагрузки выглядят для внешних сервисов, и редко бывает намеренным. Агент перечитывает конфигурацию при resyncInterval, поэтому перезапуск обычно не нужен. Проверьте, что под агента работает, затем откройте смонтированный файл внутри него. Именно чтение этого файла доказывает, что изменение дошло.

Обратный путь — вторая половина

Masquerade меняет источник запроса и ничего больше. Каким бы ни был источник, полученный партнёром, ему всё ещё нужен маршрут обратно к нему, а кластеру всё ещё нужен маршрут в сторону партнёра.

Захват на VPN-шлюзе быстро разделяет два сбоя. Пакеты, приходящие с адресами подов и никогда не получающие ответа, означают, что у партнёра нет маршрута для префикса подов. Ответ, который появляется на шлюзе, но никогда не доходит до кластера, означает, что локальный маршрут отсутствует. В любом случае запишите контракт в тикет: какой источник видит партнёр и на какой префикс он маршрутизирует ответ.

Проверяйте заново после каждого обновления

Поведение masquerade по умолчанию уже менялось однажды, а замена пула узлов может сбросить сеть кластера. Относитесь к контракту источника как к тому, что нужно проверять, а не предполагать.

После обновления отправьте один запрос из пода в локальный сервис и прочитайте источник, который записывает партнёр. Это единственное наблюдение ловит регрессию, которую страница состояния туннеля с радостью назовёт здоровой. Повтор стоит минуты и экономит следующему человеку вечер.

Похожие статьи