Віртуальна машина 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 накопичують правила, які потім ніхто не може пояснити.

Якщо віртуальна машина має пересилати трафік інших машин, сплануйте цю роль маршрутизатора явно, включно з налаштуванням хмари, що дозволяє пересилання, і відповідними фільтрами гостьової системи.