У нас будет настройка с компанией, в которой они подключат свою сеть (A) к нашему облачному VPC Google (B), содержащему кластер kubernetes, используя VPN. Они будут направлять весь трафик в нашу сеть через этот туннель.
Чтобы проверить это, мы соединили две сети Google VPC (одна имитация (A), одна (B)) с помощью Google VPN. Соединение работает, и виртуальные машины могут пинговать друг друга, используя внутренние IP-адреса. BGP A объявляет 0.0.0.0/0, а B - свою подсеть. У обоих есть правила брандмауэра, которые разрешают входящий трафик для подсетей друг друга.
Локальная сеть использует общедоступный DNS и преобразует IP-адреса в общедоступные IP-адреса.
Я ищу способ сделать две вещи на нашей стороне:
Я просмотрел несколько сервисов Google (шлюзы NAT, внутренние балансировщики нагрузки, маршрутизаторы, ...), но (из-за отсутствия опыта) не могу найти подходящего решения для этих проблем. Возможно ли это даже с облачными решениями Google?
После некоторого обращения в службу поддержки Google они предоставили мне рабочее решение. На самом деле невозможно использовать только собственные инструменты Google Cloud, но можно заставить его работать.
Итак, первая часть - это подключение к интернету через VPN-туннель:
В проекте нужно настроить собственный NAT-шлюз, отвечающий за интернет-трафик. Инструкции по этому поводу предоставляет Google. Вот, это может быть даже HA, есть модуль terraform и множество примеров при условии.
После этого вам нужно добавить несколько маршрутов:
Добавьте маршруты, которые отправляют весь трафик, указанный в 0.0.0.0/0, на виртуальные машины NAT-шлюза.
Добавьте маршрут с более низким приоритетом, который применяется только к виртуальной машине с NAT-шлюзом (используйте теги экземпляра), и сделайте следующий переход интернет-шлюзом по умолчанию.
Если вы рекламируете 0.0.0.0/0 в локальной сети, теперь он будет отправлять весь трафик через вашу облачную сеть в Интернет. Я хочу упомянуть здесь, что больше невозможно подключиться к локальной сети напрямую, так как он использует NAT-шлюз для всего трафика (можно обойти, добавив маршрут к локальной сети, нацеленный на исходящую IP).
Вторая часть этого перенаправление трафика, предназначенного для внешнего IP, на внутренний IP (например, кластер кубернетов в моем вопросе выше):
Прежде всего вам нужно добавить внутренний балансировщик нагрузки в свой кластер.
Поскольку весь трафик маршрутизируется через виртуальные машины NAT-шлюза, вы можете вручную добавить правило PREROUTING в iptable на виртуальных машинах:
sudo iptables -t nat -A PREROUTING -d $EXTERNAL_LOAD_BALANCER_IP -j DNAT --to-destination $INTERNAL_LOAD_BALANCER_IP
Если вы установите $ORIGINAL_DESTINATION к IP-адресу внешнего балансировщика нагрузки ваших кластеров и $INTERNAL_LOAD_BALANCER_IP на ваш внутренний IP-адрес балансировщика нагрузки, весь трафик, который должен быть нацелен на внешний балансировщик нагрузки, теперь будет попадать на ваш внутренний балансировщик нагрузки. Это также означает, что нет необходимости добавлять собственный DNS.
Обратите внимание, что в настоящий момент такие соединения не поддерживаются. Это ограничение внутреннего кластера из-за способа его подключения к мастеру GKE. Узлы и мастера общаются друг с другом конфиденциально, используя пиринг VPC [1]; однако одноранговые сети VPC остаются административно разделенными, а маршруты, межсетевые экраны, VPN и другие инструменты управления трафиком администрируются и применяются отдельно в каждой из сетей VPC [2]. Таким образом, соединения, сделанные через VPN, не могут достичь мастера, подключенного через пиринг.
Кроме того, внешний IP-адрес нельзя маршрутизировать через VPN-туннель, и в настоящее время Google Cloud VPN поддерживает маршрутизацию пакетов только с использованием внутреннего IP-адреса.
У нас есть существующий запрос функции для этого, который уже был направлен нашей инженерной группе, и вы можете отслеживать его, перейдя в этот пост [3] в Public Issue Tracker.
[1] https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#overview [2] https://cloud.google.com/vpc/docs/vpc-peering#key_properties [3] https://issuetracker.google.com/69449519