Облачный 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
[2] https://cloud.google.com/load-balancing/docs/network/setting-up-network
[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