Чи використовує ваша VM VPN хоста? Перевірте зсередини гостьової системи

Ви перевіряєте публічну IP-адресу хоста, вона показує VPN, і робите висновок, що VM захищена. Цей висновок не підтверджується такою перевіркою. Гостьова система має власну таблицю маршрутизації, власний резолвер і власні інтерфейси, і адреса виходу хоста нічого про них не каже.

Перевірка має виконуватися всередині гостьової системи і має називати, що саме виміряно.

Почніть усередині гостьової системи, а не в браузері хоста

Спочатку запишіть режим мережі гіпервізора: NAT, bridged, host-only або macvtap. У режимі NAT хост маршрутизує трафік гостьової системи, тому тунель хоста може застосовуватися або ні, залежно від того, як клієнт встановлює маршрути. У режимі bridged гостьова система є рівноправним учасником фізичної LAN, а тунель хоста не має значення. Ці два режими дають протилежні відповіді за однієї й тієї самої конфігурації хоста.

Запишіть режим до того, як щось змінювати, бо саме він визначає, що може означати результат.

Зробіть один запит, пункт призначення якого вам відомий

Використайте нешкідливий запит до сервісу, який повідомляє адресу джерела, яку він побачив. Потім перевірте власне рішення гостьової системи щодо маршрутизації для цього пункту призначення: ip route get 203.0.113.5 друкує інтерфейс і шлюз, які використає гостьова система.

Якщо інтерфейс — звичайний NIC гостьової системи, трафік не йде через тунель усередині неї.

Другий адаптер, налаштування проксі або VPN-клієнт на боці гостьової системи можуть змінити відповідь для одного застосунку й не змінити для іншого. Перевіряйте застосунок, який справді важливий, а не загальний запит із оболонки.

Перевірте резолвер окремо

Змінена адреса виходу не каже, який резолвер обробив це ім'я хоста. Запитайте ім'я явно інструментом, що відповідає платформі, і занотуйте, який сервер відповів. Split DNS означає, що питання про резолвер і питання про маршрутизацію мають різні відповіді.

Ці два можуть розходитися в будь-який бік, і саме це розходження часто є справжньою помилкою.

На хості з systemd resolvectl query називає інтерфейс і DNS-сервер, що стоять за відповіддю. Старіші конфігурації показують сервер у виводі dig. У будь-якому разі суть у тому, щоб побачити, який сервер відповів, а не просто чи надійшла відповідь.

Перевіряйте політику відмови, а не лише успіх

Якщо вимога полягає в тому, щоб жоден трафік не виходив за межі тунелю, успішний запит нічого не доводить. Використайте підтримуваний клієнтом контрольований тест відмови: зупиніть тунель у підтримуваний спосіб і подивіться, чи блокується новий запит гостьової системи. Не припускайте, що kill switch клієнта хоста охоплює будь-яку схему віртуального переспрямування. Його задокументована область — єдине, на що можна покластися.

Гостьова система, яка під час падіння тунелю повертається на фізичний NIC, робить рівно те, що дозволяє режим NAT.

Запишіть режим і область

Запишіть режим гіпервізора, інтерфейс і маршрут гостьової системи, резолвер і застосунок, який ви перевіряли. Додайте дату, бо відновлення знімка або оновлення гіпервізора можуть змінити всі чотири.

Якщо IPv4 ішов через тунель, скажіть це. Не поширюйте твердження на IPv6, інший простір імен або іншу VM в іншій мережі.