Включение переадресации IP на существующем шлюзе GCE VPN

VM создана без переадресации IP, она уже запускает ПО VPN, и инстинкт подсказывает пересобрать её из шаблона с включённым флагом. Эта пересборка не нужна. Compute Engine предоставляет canIpForward как обновляемое свойство, и документированный путь обновления применяет его с refresh, а не с перезагрузкой. То, чем флаг действительно управляет, узко: без него платформа отбрасывает пакеты, которые приходят на инстанс, но не адресованы его собственному адресу. Шлюз, пересылающий трафик других машин, делает именно это, поэтому флаг должен быть включён. Всё после этого — конфигурация гостя и маршрутизация, которых флаг не касается.

Что флаг разрешает, а что нет

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

При включённой переадресации инстанс может выступать следующим хопом для маршрута VPC, и это та роль, которая нужна устройству VPN. Флаг ничего не говорит о межсетевых экранах, маршрутизации гостя, настройке туннеля или обратных путях, и значение true на сломанном шлюзе всё равно остаётся сломанным шлюзом.

Прочитайте текущее свойство

Проверьте настройку, прежде чем что-либо менять, с помощью describe только для чтения для нужного инстанса, проекта и зоны:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Значение false важно только в том случае, если этот VM должен быть следующим хопом. Если это так, остальную часть пути всё равно нужно проверять отдельно, потому что свойство — одна строка в более длинной цепочке.

Обновите существующий инстанс

Процедура Google по обновлению свойств инстанса экспортирует текущий ресурс, изменяет свойство и отправляет результат. Это другой рабочий процесс, чем флаг --can-ip-forward при создании, и именно он работает на запущенном VM.

Сначала экспортируйте определение в локальный файл и сохраните неизменённую копию для сравнения:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

В этом экспортированном файле задайте свойство и больше ничего не меняйте:

canIpForward: true

Сохраните весь ресурс, включая его отпечаток. Замена файла однострочным документом YAML или объединение несвязанных правок типа машины, диска или интерфейса в одной отправке — это путь, на котором изменение свойства превращается в простой.

Попросите механизм обновления проверить файл и сообщить, что потребуется, прежде чем будет разрешено любое фактическое изменение:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Этот проверочный запуск не включает переадресацию. Прочитайте ответ насчёт недопустимых свойств и действия, которое названо необходимым. Для этого изолированного изменения документированное действие — REFRESH. Если результат требует перезагрузки, файл содержит больше, чем свойство, которое вы хотели изменить, поэтому изучите его вместо того, чтобы разрешать перезагрузку.

Примените проверенный файл с ограничением refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

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

Гость всё ещё должен маршрутизировать пакет

Разрешение в облаке не делает устройство маршрутизатором. Подтвердите, что маршрут VPC выбирает этот VM следующим хопом для префикса назначения и что гость маршрутизирует между туннелем и нужным интерфейсом с включённой собственной политикой переадресации.

Политика межсетевого экрана должна разрешать как внутренний поток, так и внешний слушатель. Открытие только порта VPN описывает зашифрованный транспорт и ничего не говорит об обмене приложения внутри него.

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

На шлюзе Linux переадресация в ядре — часть конфигурации гостя. У устройства pfSense есть свой эквивалент, и копирование в него команды sysctl из Linux — не тот шаг.

Проверьте со стороны клиента, которому нужен доступ

Тестируйте с клиента VPN к одной целевой службе, а не с самого шлюза. Соединение, начатое на шлюзе, использует другой источник и никогда не задействует правила переадресации, которые вы только что включили.

Запишите свойство в том, что управляет устройством. VM, исправленная вручную, работает до следующей замены, которая тихо вернёт исходную настройку, и этот сбой будет выглядеть как регрессия в ПО VPN.

Порядок работы: прочитайте свойство, экспортируйте и отредактируйте одну строку, проверьте с NO_EFFECT, примените с REFRESH, подтвердите, что гость пересылает, затем тестируйте с клиента.