Регистрация Войти
Рейтинг:1
avatar Server

Тайм-ауты в Cloud SQL и других внешних службах при использовании NAT + IP Masquerade в GKE

флаг it
rsan

Мне нужно настроить статический IP-адрес в одном из моих POD, поскольку для удаленной службы (за пределами моего кластера) требуется белый список доверенных IP-адресов.

Я следовал документации, предоставленной Google:

https://cloud.google.com/nat/docs/overview?hl=es-419

https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent

Но при попытке настроить исходящий трафик с помощью облачной службы Google NAT в моем кластере GKE плюс маскировка с использованием ip-masq-агент Я начинаю получать тайм-ауты и проблемы при доступе к удаленным службам за пределами кластера.

Мой кластер находится в версии 1.19.10-гкэ.1600.

Я пробовал эти файлы конфигурации со следующими результатами:

интервал повторной синхронизации: 60 сек.

Результат:

Сеть IP-MASQ (2 ссылки)
целевая защита выбор источника назначения         
RETURN all -- везде 10.0.0.0/8 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 172.16.0.0/12 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 192.168.0.0/16 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
MASQUERADE all -- везде где угодно /* ip-masq-agent: исходящий трафик является суб
объект для MASQUERADE (должен быть последним в цепочке) */

Службы продолжают использовать неправильный IP.

интервал повторной синхронизации: 60 сек.
masqLinkLocal: правда

Сеть IP-MASQ (2 ссылки)
целевая защита выбор источника назначения         
RETURN all -- везде 169.254.0.0/16 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 10.0.0.0/8 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 172.16.0.0/12 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 192.168.0.0/16 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
MASQUERADE all -- везде где угодно /* ip-masq-agent: исходящий трафик является суб
объект для MASQUERADE (должен быть последним в цепочке) */

Тот же эффект, мои внешние службы получают неправильный IP.

nonMasqueradeCIDR:
  - 0.0.0.0/0
интервал повторной синхронизации: 60 сек.
masqLinkLocal: правда

Сеть IP-MASQ (2 ссылки)
целевая защита выбор источника назначения         
RETURN all -- везде где угодно /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
MASQUERADE all -- везде где угодно /* ip-masq-agent: исходящий трафик является суб
объект для MASQUERADE (должен быть последним в цепочке) */

Похоже, это работает лучше, потому что внешние службы получают правильный IP-адрес, но у меня возникают проблемы с подключением и тайм-ауты.

Это моя конфигурация NAT:

сопоставление NAT
- Высокая доступность: Да
- Исходные подсети и диапазоны IP-адресов: первичные и вторичные диапазоны IP-адресов всех подсетей.
- IP-адреса NAT: статический-исходящий-ip XXX.XXX.XXX.XXX

У меня нет идей, может кто-нибудь дать мне совет?

После получения ответа я обновил свой файл конфигурации, чтобы добавить ips в соответствии с документацией Google Cloud, файл выглядит следующим образом:

nonMasqueradeCIDR:
  - 10.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
  - 100.64.0.0/10
  - 192.0.0.0/24
  - 192.0.2.0/24
  - 192.88.99.0/24
  - 198.18.0.0/15
  - 198.51.100.0/24
  - 203.0.113.0/24
  - 240.0.0.0/4
интервал повторной синхронизации: 60 сек.
masqLinkLocal: правда

Результат этого в iptables:

Сеть IP-MASQ (2 ссылки)
целевая защита выбор источника назначения         
RETURN all -- везде 10.0.0.0/8 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 172.16.0.0/12 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 192.168.0.0/16 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 100.64.0.0/10 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 192.0.0.0/24 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 192.0.2.0/24 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 192.88.99.0/24 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 198.18.0.0/15 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 198.51.100.0/24 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 203.0.113.0/24 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
RETURN all -- везде 240.0.0.0/4 /* ip-masq-agent: локальный трафик не суб
объект на МАСКАРАД */
MASQUERADE all -- везде где угодно /* ip-masq-agent: исходящий трафик является суб
объект для MASQUERADE (должен быть последним в цепочке) */

Но если я запускаю завиток checkip.amazonaws.com чтобы увидеть, какой IP-адрес используется узлом, я получаю IP-адрес, отличный от того, который определен в моей конфигурации NAT Cloud, и внешние службы отклоняют запрос как недоверенный из моего кластера.

312
2 + 0
Рейтинг:1
Anbu Thirugnana Sekar avatar Server
флаг gh
Anbu Thirugnana Sekar

Кажется, вы установили nonMasqueradeCIDR: как 0.0.0.0/0, тем самым предотвращая маскировку всего трафика CIDR, поэтому, чтобы решить эту проблему, в файле конфигурации обновите ключ nonMasqueradeCIDRs: с IP-адресами, упомянутыми в параграфе [1] назначения по умолчанию, не предназначенном для маскарада, как указано ниже.

nonMasqueradeCIDR:

  • 172.16.0.0/12
  • 192.168.0.0/16
  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4
  • 10.0.0.0/8

Также обратите внимание, что IP-адреса, указанные на снимке экрана, не были неправильными IP-адресами, но это диапазоны, зарезервированные RFC 1918/link-local, т. е. IP-адреса 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 зарезервированы для RFC. 1918, а диапазон IP-адресов 169.254.0.0/16 зарезервирован для локальной ссылки, и они не поддаются маскированию, поэтому эти IP-адреса отображаются с описанием «ip-masq-agent: локальный трафик не подлежит маскировке». [2].

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent#default-non-masq-dests

[2] https://kubernetes.io/docs/tasks/administer-cluster/ip-masq-agent/#ip-masquerade-agent-user-guide

С уважением, Анбу.

0 + 1
флаг it
rsan
Привет @Anbu, большое спасибо за помощь. Я следовал вашим инструкциям и вместо использования 0.0.0.0/0 в качестве маски я указал диапазоны, определенные в документации. Вы можете увидеть изменения, внесенные в мой вопрос, чтобы увидеть вывод команд, но у меня все еще есть проблема, заключающаяся в том, что мои узлы и модули вызывают внешние службы, используя IP-адрес, который я не контролирую. Фиксированный IP-адрес NAT, который я настроил в GOOGLE CLOUD NAT, игнорируется. Я тестирую это с помощью завитка непосредственно с узла ssh или вызываю мои внешние службы, которые возвращают IP-адрес, не разрешенный. Любые идеи?
0
Ответить
Рейтинг:0
avatar Server
флаг it
rsan

Наконец мы смогли диагностировать проблему. Наш кластер был создан некоторое время назад, когда GCP не поддерживал частные кластеры, поэтому наш кластер является общедоступным.

Каждый узел имеет общедоступный эфемерный IP-адрес, поэтому правила NAT игнорируются.

Решение заключалось в том, чтобы установить узел со статическим IP-адресом, а не эфемерным, и настроить рабочую нагрузку, которая требует, чтобы доверенная аутентификация всегда развертывалась на этом конкретном узле. Это не идеальное решение, но это то, что мы можем сделать быстро, чтобы решить проблему.

Реальным решением будет миграция в частный кластер и настройка NAT, но, к сожалению, GCP не поддерживает миграцию из общедоступного кластера в частный. Единственным вариантом будет создание нового кластера и перенос рабочих нагрузок в новый кластер, процесс, который нам нужно будет выполнить в краткосрочной перспективе.

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

0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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