Полное туннелирование проще длинного списка раздельного туннелирования?

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

Начните с подсчёта правил, которые вы поддерживаете

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

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

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

Проверьте, выдержит ли шлюз значение по умолчанию

Полное туннелирование переводит каждый пакет на одно устройство, что одновременно меняет нагрузку на CPU этого устройства, таблицу conntrack, трансляцию адресов и требования к исходящей полосе. Шлюз, который спокойно обслуживал несколько внутренних подсетей, мог не рассчитываться на весь просмотр одного пользователя. Смотрите на наибольшее ожидаемое число одновременных сеансов, а не на среднее, потому что пик ломается первым.

ip -s link show dev tun0
conntrack -C
ss -s

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

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

Убедитесь, что локальные службы и частный DNS всё ещё работают

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

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

Запишите локальные исключения в профиль, которому они принадлежат. Исключение, хранящееся только в чьей-то памяти, — первое, что теряет следующий перенос.

Перенесите один профиль и проверьте границы

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

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

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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