VPN у гостьовій системі та VPN на хості: який маршрут справді перемагає

Два клієнти працюють одночасно, кожен переконаний, що володіє маршрутом за замовчуванням, і симптом проявляється як щось дивне: один застосунок гостьової системи працює, інший розв'язується не туди. VPN усередині гостьової системи та VPN на хості можуть співіснувати, але лише коли зовнішній шлях і внутрішня політика погоджуються щодо того, хто що несе. Запуск обох сам по собі не створює ланцюга. Спершу запишіть підключення, потім змінюйте одну річ за раз.

Спершу запишіть підключення гостьової системи

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

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

Простежте кінцеву точку гостьової системи назовні

VPN гостьової системи потребує придатного шляху до свого сервера, перш ніж щось інше запрацює. Коли тунель хоста піднятий, а гостьова система сидить за NAT, рукостискання гостьової системи виходить через тунель хоста, що є або задумом, або аварією, яку ніхто не задокументував. Коли тунель хоста падає, а гостьова система залежала від нього, вона втрачає зв'язність без жодної зміни на своєму боці. Прослідковування кінцевої точки назовні показує, який із цих двох випадків у вас насправді.

Широкий маршрут у будь-якому з контекстів перехоплює трафік, якого очікував інший клієнт. Маршрут 0.0.0.0/0 усередині гостьової системи та клієнт хоста з повним тунелем обидва претендують на все, і перемагає той, що застосовується останнім. Перетини між віртуальними мережами гостьової системи, локальною LAN і віддаленими мережами дають той самий ефект для приватних префіксів, а збої нагадують проблеми автентифікації; поведінка трансляції адрес та сама, що описана для мереж контейнерів.

Порівняйте запис до і після

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

Тримайте володіння ясним між перезапусками

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

Вирішіть, яка сторона володіє маршрутом за замовчуванням, і запишіть це в посібник з експлуатації. Перезапуск гостьової системи або зміна мережі на хості, яка тихо перевертає володіння, породжує звіт про помилку щодо VPN, який ніколи не був винним. Устрій має пережити перезавантаження так, щоб ніхто не пам'ятав, чому він працював.