Облачный VPN с TCP Load Balancer

Question

Я пытаюсь настроить Cloud VPN в сети GCP с 5 виртуальными машинами, одна из которых находится в группе экземпляров за балансировщиком нагрузки TCP, перенаправляя порты групп экземпляров в Интернет и сам VPN-туннель работает хорошо, потому что он установлен, и я могу пропинговать эти виртуальные машины из моей локальной сети.

Но после того, как я настроил VPN-туннель, я больше не могу получить доступ к IP-адресу внешнего балансировщика нагрузки!

Я проверил правила брандмауэра, и все в порядке. Если я удаляю VPN-туннели и маршруты, я могу нормально обращаться к IP. Такое поведение ожидается? Я действительно не могу получить доступ к IP Балансировщика нагрузки, если у меня есть Cloud VPN в той же сети?

Кстати, все виртуальные машины не имеют внешнего IP, только внутренний. Один из них, как я уже говорил, находится за LB, чтобы получить доступ к Интернету.

Я ожидаю подключения к виртуальным машинам в группе экземпляров за балансировщиком нагрузки TCP из моей локальной сети, в которой установлен облачный VPN. Я могу получить доступ только к внутренним IP-адресам, но не к внешнему LB.

Answer 1

Позвольте мне подвести итог,

Важные моменты:

- Балансировщик нагрузки TCP (LB) - Региональная сеть LB
- VPN-туннель от предварительной установки до GCP
- 5 экземпляров виртуальных машин, 1 экземпляр в группу экземпляров для использования LB, все виртуальные машины имеют только внутренние IP-адреса.
- Потеря доступа с использованием IP-интерфейса балансировщика нагрузки после настройки VPN-туннеля
- Правила брандмауэра вроде бы в порядке
- Если вы удаляете VPN-туннель и «маршруты», вы восстанавливаете доступ, используя IP-интерфейс

Отвечая на ваш прямой вопрос:
-Это поведение ожидается?

Ответ:
-Нет, такое поведение не ожидается, вы можете использовать TCP Load Balancer для доступа к вашим экземплярам виртуальной машины и VPN-туннелю, чтобы получить доступ к тем же экземплярам виртуальной машины из другой (локальной) сети одновременно.


Что касается TCP LB (External - региональный) без прокси, вам нужно рассмотреть варианты и выбрать лучший для ваших нужд [1], я хотел бы знать, какой сервис вы используете (на бэкэнде) и какой порт делать вам нужно, так как TCP Load Balancer выполняет сквозную передачу, поэтому запрос достигает целого бэкэнда от Frontend (внешний IP) до бэкэнда (экземпляр VM), сохраняя тот же порт для доступа к вашим сервисам. Однако не ясно, используете ли вы TCP LB или TCP-прокси LB. Как вы тестируете IP-интерфейс Frontend? (ping, nmap и т. д.)

Какие правила брандмауэра вы проверяете и настраиваете? поскольку для LB и Cloud VPN требуются определенные правила брандмауэра [2] [3].
Обращает мое внимание на то, что вам необходимо удалить маршруты. Не могли бы вы подробнее рассказать об этих маршрутах [4], они созданы GCP или вами, какова цель этих маршрутов?

Где ваши балансировщик нагрузки и VPN созданы? (Zone-Region), учитывая, что оба используемых вами ресурса являются региональными [5] [6]

По ссылкам вы найдете информацию, которая будет полезна для поиска возможной точки отказа.


[1] https://cloud.google.com/load-balancing/docs/choosing-load-balancer#deciding_on_a_load_balancer
[2] https://cloud.google.com/load-balancing/docs/network/setting-up-network#create_a_firewall_rule_to_allow_external_traffic_to_these_vm_instances
[3] https://cloud.google.com/vpn/docs/how-to/configuring-firewall-rules
[4] https://cloud.google.com/vpc/docs/routes
[5] https://cloud.google.com/load-balancing/docs/network/
[6] https://cloud.google.com/vpn/docs/concepts/overview#ha-vpn