У меня есть работающий кластер в Kubernetes с GCP и некоторые сервисы, работающие в App Engine, и я пытаюсь общаться между ними, не имея доступа к App Engine извне.
Я создал частный кластер Kubernetes с определенной подсетью, я связал эту подсеть с Cloud NAT, чтобы иметь уникальный исходящий IP-адрес, который я могу занести в белый список, и разрешил этот IP-адрес в правилах брандмауэра App Engine.
Однако когда я запрашиваю свои механизмы приложений из кластера, я получаю ответ 403, потому что он не проходит через брандмауэр. Но если я подключаюсь к своему модулю Kubernetes и пытаюсь запросить у сайта информацию о моем IP-адресе, я получаю IP-адрес, установленный в Cloud NAT.
Я обнаружил в документации Cloud NAT, что перевод на внутренние IP-адреса осуществляется до применения правил межсетевого экрана (https://cloud.google.com/nat/docs/overview#firewall_rules).
Когда я подключаюсь к движкам приложений, я вижу, что запросы, сделанные через шлюз NAT, поступают с IP 0.0.0.0. Однако, когда мы добавляем в белый список только этот IP-адрес, запросы проходят только 1 раз из 3, что кажется действительно странным.
Вы бы знали, как это понять и исправить?
Cloud Nat позволяет Частный доступ к Google для виртуальных машин, которые взаимодействуют с API и службами Google с помощью частных IP-адресов.
Пакеты, отправляемые в API Google, не обрабатываются NAT и не содержат IP-адресов NAT. При выполнении запроса к API или службе Google мы не используем общедоступный Интернет; вместо этого мы выбираем определенный путь, который достигает API Google, и облачный NAT не несет ответственности за эту связь.
Частный доступ к Google поддерживает доступ к приложениям движка приложений.
В соответствии с документация вы упомянули, когда Cloud NAT настроен, он автоматически включает Частный доступ к Google для этой подсети. Однако, хотя Private Google Access разрешает доступ к Cloud и API для разработчиков, а также к большинству сервисов GCP, есть некоторые исключения и кажется, что App Engine не поддерживается.