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

Совет, что домашней лаборатории нужен полный туннель, обычно приходит из руководства, где он был, а не из требования. Раздельное туннелирование — не компромиссная версия правильного VPN; это версия, таблицу маршрутов которой вы можете объяснить. Лаборатории с пятью сервисами и интерфейсом управления не нужно, чтобы каждый пакет, покидающий дом, шёл через туннель. Ей нужны опись и маршрут для каждого пункта этой описи.

Миф: раздельное туннелирование — это компромисс

Миф живёт потому, что полный туннель проще настроить один раз и сложнее отлаживать потом. Этот обмен разумен для ноутбука в публичном Wi-Fi и неверен для стойки в подвале.

Он скрывает и второе допущение: адресация лаборатории не имеет ничего общего с сетью, из которой вы подключаетесь.

Составьте опись ресурсов до маршрутов

Запишите каждую подсеть лаборатории, сервис, который там живёт, имя, по которому вы её разрешаете, и кому разрешено к ней подключаться; заметки о пересылке для вашего шлюза описывают обратный путь, под который вы планируете. Добавьте диапазоны контейнеров и диапазоны LAN, которые удалённый клиент, возможно, уже использует, потому что пересечение — это отказ, который предотвращает эта опись. Маршрут, покрывающий каждый частный адрес, рано или поздно столкнётся с домашней сетью. Опись — это ещё и план тестирования, поэтому её стоит делать до настройки, а не после.

Назначьте каждому ресурсу путь: через туннель, напрямую или запрещённый. Ресурс без назначенного пути — тот, что позже порождает запутанный вопрос в поддержку.

Пять строк и столбец решений лучше таблицы маршрутов, которую никто не может прочитать.

Шлюзу нужен обратный путь

Пересылка на шлюзе — это только половина. Лаборатории нужен маршрут обратно к пулу клиентов или поддерживаемая схема трансляции, которая делает возврат возможным. Если ответы не находят клиента, туннель выглядит подключённым, а каждый запрос завершается по тайм-ауту; это симптом маршрутизации, а не отказ VPN. Проверяйте обратный путь как часть проекта, а не как шаг поиска неисправностей.

Пул клиентов, пересекающийся с собственной адресацией лаборатории, — это вторая половина проблемы, и он отказывает точно так же.

Исправляйте план, а не симптомы, когда два диапазона сталкиваются.

Роли управления и интернета разделены

Решите, использует ли туннель только трафик лаборатории или он становится ещё и выходом в интернет. Не добавляйте маршрут по умолчанию только потому, что руководство использовало такой, ведь это решение меняет, куда идут каждый DNS-запрос и каждая проверка обновлений. Сохраните внешний путь к самой конечной точке VPN, иначе туннель попытается нести собственное внешнее соединение. Держите доступ управления узким и достижимым через одобренный метод восстановления.

Частный DNS можно выбрать для имён лаборатории, не предполагая, что каждый публичный запрос требует того же резолвера. Это решение резолвера, а не решение маршрута.

Именно их разделение делает режимы отказа различимыми позже.

Тестируйте снаружи, а не из LAN

Используйте внешнее разрешённое соединение вместо теста из той же LAN, потому что тест из той же LAN может полностью скрыть отсутствующий обратный маршрут. Проверьте адрес лаборатории, её частное имя хоста, предполагаемый прямой пункт назначения и требуемое поведение при отказе. Случай отказа так же важен, как и случай успеха: ресурс, до которого не должно быть доступа, должен действительно быть недоступен. Запишите все четыре результата, прежде чем назвать проект завершённым.

Затем сохраните конфигурацию маршрутов и DNS рядом с описью, с указанным владельцем. Когда у лаборатории появится ещё одна подсеть, обновите обе и проверьте снова.

Необъяснённый маршрут, пересекающийся с существующей домашней сетью, — это результат по умолчанию от пропуска этого шага.

Готовый проект мал, задокументирован и скучен, и именно этого лаборатория хочет от своей сети. Интересная версия — та, что ломается, пока вы не дома.