Cloud VPN к ВМ в GCP: используйте внутренний IP, а не NAT-IP

Когда локальная сеть достигает VPC через Cloud VPN, пунктом назначения для службы Compute Engine обычно является внутренний адрес ВМ. Внешний IPv4-адрес — это не второй адрес, который можно подставить в тот же частный маршрут. Большая часть путаницы здесь возникает из-за того, что три адреса с тремя задачами считаются взаимозаменяемыми, поэтому начните с того, чтобы назвать, какой из них использует конкретный пакет.

Три адреса, три задачи

Назовите все три, прежде чем отлаживать любой из них, потому что ответ меняет объект, который вы будете проверять дальше.

Первый принадлежит туннелю. Второй принадлежит схеме маршрута и межсетевого экрана. Третий принадлежит входящему доступу из интернета и отображается, а не привязывается. Схема, которая работает для одного из них, ничего не говорит о двух других.

Почему внешний адрес — не второй интерфейс

Руководство по адресации — это источник истины о том, чем отличаются внутренняя и внешняя доступность в Compute Engine. Внешний IPv4-адрес в Compute Engine — это отображение «один к одному» на единственный внутренний NIC экземпляра, поэтому гостевая система никогда не видит второй интерфейс или второй адрес на этом NIC. То, что ВМ сообщает изнутри, по-прежнему один основной внутренний адрес.

Именно поэтому частный клиент, направляющий трафик через туннель к 10.24.1.7, и клиент, нацеленный на внешний адрес ВМ, находятся на разных путях. Открытие правила межсетевого экрана для публичного адреса ничего не меняет в маршруте VPC, который должен нести трафик туннеля, а редактирование маршрута в гостевой системе не сдвигает отображение платформы. Выберите адрес, который называет ваш маршрут, и затем проверяйте только те объекты, которые им управляют. Эта дисциплина убирает большую часть догадок из этого пути поиска неисправностей.

Пройдите путь с gcloud

Начните с экземпляра и прочитайте оба адреса из одного и того же объекта, чтобы знать, о каком из них говорит ваша документация:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Затем подтвердите маршрутизацию и разрешение, от которых путь действительно зависит:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

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

Затем проверьте гостевую систему: слушает ли служба внутренний адрес и проходит ли её обратный путь снова через VPC? Слушатель, привязанный только к публичному адресу, не пройдёт эту проверку даже при правильных объектах на стороне облака.

Публичный префикс — это другой вопрос

Ничто из перечисленного не означает, что каждый адрес внутри VPN обязан быть RFC1918. Удалённую сеть можно законно нумеровать из публичного пространства, если платформа поддерживает маршрутизацию, а оператор обладает правами на адрес. Это обычный проектный выбор.

Это не то же самое, что относиться к обычному внешнему NAT-адресу как к ещё одному внутреннему адресу подсети. Один — это префикс, который вы маршрутизируете; другой — отображение, которое платформа применяет к входящему доступу.

Внешний IPv6 и специально спроектированные схемы адресации имеют свою семантику. Если ваш план зависит от одной из них, читайте документацию платформы по этой функции, а не обобщайте случай IPv4. Отображение IPv4 — обычный случай, но не единственный, и у каждого исключения свои правила.

Перекрывающиеся диапазоны — это другая проблема

Перекрывающиеся частные диапазоны — реальная причина, по которой люди хватаются за публичный адрес, и это неверный рычаг. Смена назначения на NAT-адрес ВМ не решает перекрытие; она меняет адрес, для которого пакет заявляет себя, не определяя, как работает обратный путь.

Решите перекрытие осознанно: перенумеруйте, используйте поддерживаемую схему трансляции или маршрутизируйте через сеть, где префиксы не конфликтуют. Каждый из этих вариантов — схема с ответственным. NAT-адрес — не схема.

Документируйте два поля отдельно

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

Проверьте реальным клиентом на другой стороне: разрешите имя, убедитесь, что оно возвращает внутренний адрес, подключитесь и проверьте обратный трафик. документация Compute Engine по IP-адресам — это справочник по различению внутреннего и внешнего, использованному выше.