Виртуальная машина GCP с несколькими NIC: почему ответы уходят через неправильный интерфейс

Подключение второго интерфейса к ВМ Compute Engine даёт ей ещё одно сетевое подключение, а не симметричный обратный путь. Гостевая система по-прежнему выбирает интерфейс и адрес источника из собственных маршрутов и правил. Затем Google Cloud применяет маршрутизацию VPC и политику межсетевого экрана вокруг того интерфейса, через который ушёл пакет. Когда эти два решения расходятся, запросы приходят на один NIC, а ответы уходят через другой, и филиал видит полуоткрытый разговор.

Пройдите путь за пять шагов, и расхождение проявится ещё до того, как вы напишете правило политики.

Шаг 1: сопоставьте облачные NIC с устройствами гостевой системы

Облако называет интерфейсы nic0, nic1 и так далее, а гостевая система видит имена устройств, которые не обязаны совпадать. Определите соответствие по метаданным экземпляра или по собственному адресу интерфейса раньше всего остального. Обычный маршрут по умолчанию от DHCP связан с nic0, поэтому путь к интернету так часто побеждает случайно. Написание политики под угаданное имя устройства — это способ, которым правильное правило попадает на неправильный интерфейс.

Запишите адреса, имена устройств и VPC, к которой относится каждое. Эта таблица из трёх столбцов — вход для каждого следующего шага.

Шаг 2: назовите два маршрутных решения

Первое решение принадлежит гостевой системе: какой интерфейс и какой адрес источника для этого пакета. Второе принадлежит облаку: что разрешают маршруты VPC и политика межсетевого экрана вокруг этого интерфейса.

Маршрут, видимый в VPC, обращённой к VPN, не становится маршрутом гостевой системы, выбирающим этот NIC. Облачный маршрут описывает, что сеть может доставить, а маршрут гостевой системы решает, что делает пакет.

Шаг 3: выберите политику обратного пути

Для небольшого стабильного набора префиксов филиала явные маршруты к месту назначения в гостевой системе — простейшее выражение: ответы на эти префиксы уходят через интерфейс, обращённый к VPN. Когда несколько служб намеренно используют разные локальные адреса источника, правила на основе источника, выбирающие таблицу для каждого интерфейса, удерживают каждый ответ в правильном контексте. Документация о нескольких интерфейсах описывает именование NIC и поведение маршрута по умолчанию, на которые опираются эти схемы.

Каждой таблице нужны действительные подключённые маршруты и следующие переходы, а также пункты назначения, о которых её спросят. Правило, указывающее на неполную таблицу, не является схемой обратного пути. Используйте документированный шлюз для этого NIC, вместо того чтобы придумывать Ethernet-шлюз по внешнему виду подсети.

Шаг 4: проверьте собственные фильтры гостевой системы

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

В Linux проверьте валидацию обратного пути на соответствие задуманной схеме. Глобальное отключение её первым шагом меняет ошибку маршрутизации на уязвимость к подмене адресов и скрывает асимметрию, которую вы пытались найти.

Шаг 5: проверьте один поток на каждый путь

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

Храните два теста отдельно в своих заметках, поскольку они используют разные маршруты и разные правила межсетевого экрана.

Чего второй NIC вам не даёт

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

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