Два VPN на одній машині Linux: перевіряйте кожен окремо, не змішуючи результати

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

Дві зелені лампочки — не порівняння

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

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

Закріпіть очікування до першого запуску

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

Обв'язка розв'язувача заслуговує окремого рядка в цьому записі, бо саме це поле найчастіше бреше. Файли, прив'язані до простору імен, як-от /etc/netns/vpn-a/resolv.conf з'являються на своїх звичних шляхах, коли команда виконується всередині простору імен, як описує довідка iproute2 про простори імен, але налаштування перемикання служби імен і будь-який локальний розв'язувач, який вона запускає, усе ще можуть потягнути запит назад на хост.

Один тунель за раз, інший відключений

Підключіть A через його наявного власника, поки B залишається вимкненим, потім з адміністративного контексту перегляньте політику, маршрути й обраний шлях. Три з наведених нижче команд читають стан; лише остання звертається до служби імен, і жодна з них не надсилає запит програми.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

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

Обидва ввімкнені, потім по одному вимикаємо

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

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

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

Що цей запис може й чого не може стверджувати

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

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

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