Домашня лабораторія та розділений тунель: маршрутизуйте потрібне, а не все

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

Міф: розділений тунель — це компроміс

Міф живе, бо повний тунель легше налаштувати один раз і важче зневаджувати потім. Цей обмін розумний для ноутбука в публічному Wi-Fi і хибний для стійки в підвалі.

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

Опишіть ресурси перед маршрутами

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

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

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

Шлюзу потрібен зворотний шлях

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

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

Виправляйте план, а не симптоми, коли два діапазони стикаються.

Ролі керування та інтернету розділені

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

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

Саме їх розділення робить режими відмов розрізнюваними пізніше.

Тестуйте ззовні, а не з LAN

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

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

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

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