Почему VPN с полным туннелем скрывает маршрутизируемые локальные VLAN

Переключатель «разрешить локальную сеть» в VPN-клиенте звучит так, будто охватывает всё в здании. На практике он обычно добавляет несколько исключений для частных адресов к маршруту по умолчанию туннеля и на этом останавливается. Ваш VLAN хранения остаётся доступным только если маршрут для этого конкретного префикса переживёт появление туннеля, а у многих клиентов он не переживает.

Это вопрос маршрутизации, а не настройка VPN, и это хорошая новость: у него есть конкретный ответ.

Что на самом деле охватывает разрешение локальной сети

Клиенты реализуют этот параметр по-разному. Некоторые добавляют маршруты к подсети, к которой подключена машина, некоторые добавляют диапазоны RFC 1918, а немногие исключают только шлюз по умолчанию. Ни один из них не знает, что офисный маршрутизатор обслуживает ещё и VLAN хранения, лабораторный сегмент или подсеть принтеров, потому что этих префиксов нет в сети, которую видит клиент. Читайте документацию самого клиента, чтобы узнать точное поведение, вместо того чтобы предполагать, что ярлык описывает вашу топологию.

Эта разница важнее всего в схеме с полным туннелем, где клиент намеренно заменяет маршрут по умолчанию, чтобы весь трафик шёл через VPN. В этом весь смысл схемы, и именно поэтому локальные маршрутизируемые сети исчезают. У них никогда не было собственного маршрута; они ехали на маршруте по умолчанию, который только что заменили. Клиент не может маршрутизировать то, о существовании чего не знает, и он узнаёт только префиксы, привязанные к его собственному интерфейсу. Всё остальное должен описать тот, кто знает топологию.

Подключённые маршруты заканчиваются на первом маршрутизаторе

Рабочая станция с адресом 192.168.10.20/24 и шлюзом 192.168.10.1 автоматически получает подключённый маршрут для 192.168.10.0/24. VLAN хранения в 192.168.20.0/24 — это другой префикс, доступный только через этот шлюз, и у станции нет для него маршрута, кроме маршрута по умолчанию. Пока туннель не поднят, обычный маршрут по умолчанию отправляет трафик хранения на 192.168.10.1, и всё работает.

Когда VPN устанавливает маршрут по умолчанию для полного туннеля, пакеты к 192.168.20.1 следуют за новым маршрутом по умолчанию в туннель. Удалённый шлюз понятия не имеет, где живёт этот префикс, поэтому он их отбрасывает или пересылает куда-то бесполезно. На VLAN хранения ничего не было настроено неправильно; его путь был взятым взаймы, и заём востребовали обратно.

Соблазн — взять широкое исключение, например пару маршрутов /1 или второй маршрут по умолчанию. Сопротивляйтесь. Чем уже исключение, тем проще его объяснить, проверить и удалить при изменении сети.

Поместите исключение в таблицу, которая побеждает

Внутри одной таблицы маршрутизации /24 побеждает /0 или /1 по совпадению самого длинного префикса, поэтому конкретного маршрута к VLAN хранения через локальный шлюз достаточно, при условии, что таблица вообще просматривается. В Linux обычная форма коротка:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Маршрутизация по политике усложняет эту гарантию. Более раннее правило может отправить трафик в таблицу, чей собственный маршрут по умолчанию ведёт в туннель, и тогда основная таблица с вашим /24 никогда не будет достигнута. Проверяйте правила, прежде чем считать маршрут авторитетным, потому что корректная на вид запись в неправильной таблице объясняет сбой, который выглядит как сломанный маршрут.

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

Имена и политика не следуют за маршрутами

Исправление маршрута возвращает пакеты, но не имена. Если локальные устройства разрешаются через навязанный резолвер, который о них ничего не знает, монтирование всё равно не удаётся, хотя адрес доступен. Локальным именам нужна локальная или разделённая схема DNS, и это отдельное решение от исключения маршрута.

Политика снова отдельно. Фильтр локального доступа VPN-клиента может намеренно запрещать трафик к частным диапазонам, и маршрут не отменяет это правило. В недоверенной сети частный адрес также не доказывает, что пункт назначения — ваш сервер хранения, поэтому исключение должно быть таким же конкретным, как и маршрут.

Контракт, который можно передать

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

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

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