Почему один route-nopull оставляет файловый сервер недоступным
Игнорирование протолкнутых маршрутов — лишь половина раздельного туннеля. Выберите владельца маршрута, добавьте офисный префикс вручную и проверьте три потока, прежде чем считать это исправленным.
Файловый сервер открывается нормально, а видеозвонок в соседнем окне начинает подтормаживать. Ничего не медленно и ни один MTU не ошибочен: ваш клиент принял список маршрутов, который дал сервер, поэтому каждый пакет теперь уходит через офисный брандмауэр. Исправление — не ещё один флаг настройки, а решение о том, кому принадлежит таблица маршрутов клиента. Это решение относится к одному месту, и приведённые ниже режимы отказа подскажут, какое место вы выбрали на самом деле.
Решите, кому принадлежит таблица маршрутов
Возможны три владельца. Сервер может проталкивать маршруты и шлюз по умолчанию, и тогда клиент устанавливает всё, что ему скажут, и становится полным туннелем. Профиль клиента может взять владение, отбрасывая проталкивания и неся свои строки маршрутов. Менеджер подключений рабочего стола тоже может владеть решением через свои свойства маршрута и маршрута по умолчанию.
Каждый выбор отказывает по-своему, поэтому таблицу стоит прочитать до правки профиля. Строка, совпадающая с вашим симптомом, — это владелец, который у вас действительно есть.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Выберите один и запишите. Смешение двух оставляет хост, чей путь по умолчанию противоречит его собственной документации, и следующий инженер не сможет сказать, какой уровень победил. Удалите проигравшего явно.
route-nopull фильтрует проталкивания, он не добавляет маршруты
route-nopull относится к профилю клиента, и его порядок в этом файле не важен, потому что он лишь отбрасывает значения, приходящие от сервера. Он отбрасывает протолкнутые маршруты, включая протолкнутый маршрут по умолчанию, а туннель всё равно поднимается нормально.
Последствие, которое люди упускают, — протолкнутые параметры DHCP уходят вместе с ними. Отправленные сервером настройки DNS тоже отбрасываются, поэтому внутренние имена перестают разрешаться, хотя туннель здоров и сервер доступен по адресу.
Это оставляет туннель без пути к офисному префиксу, если вы сами не добавите его: route-nopull, за которым следует route 10.30.0.0 255.255.0.0 в том же профиле. Эта строка несёт адрес и маску; она не называет следующий хоп.
Альтернативная форма добавляет токен шлюза, route 10.30.0.0 255.255.0.0 vpn_gateway, который указывает запись на туннель по имени. Импортёры различаются тем, переводят ли они этот вариант, поэтому проверьте сохранённое подключение, если запись отсутствует в таблице ядра.
Проверяйте поиском маршрутов, а не ping
ping сообщает, что что-то ответило. Поиск маршрута сообщает, какой интерфейс выбрало бы ядро, и это и есть заданный вами вопрос. Четыре короткие команды отделяют отсутствующий маршрут от маршрута, указывающего на неверное устройство.
Прочитайте, что установил туннель, с помощью ip route show dev tun0. Полное отсутствие вывода означает ноль маршрутов, что не является работающим раздельным туннелем, и это обычный результат добавления фильтра без явной строки.
Затем проверьте один офисный адрес с помощью ip route get 10.30.5.7 и один обычный интернет-адрес с помощью ip route get 1.1.1.1. Второй должен назвать физический интерфейс; если он называет туннель, проталкивание вообще не фильтровалось.
Наконец прочитайте ip rule, потому что правило политики, оставленное предыдущей попыткой, может перекрыть только что исправленную таблицу. Правильный профиль с устаревшим правилом сверху выглядит точно как сломанный профиль. Удалите правило, добавленное в прошлый раз, прежде чем добавлять ещё одно.
Перекрывающиеся подсети выглядят как сломанный туннель
Два частных диапазона могут быть одинаковыми с точки зрения клиента, и именно там раздельный туннель обвиняют в том, чего он не вызвал. Если офис выдаёт тот же префикс, который использует ваш домашний маршрутизатор, маршрут туннеля покрывает маршрутизатор, и домашняя сеть будто исчезает.
Сравните адрес на своём интерфейсе с маршрутом, который устанавливает профиль, используя обычный список адресов, прежде чем что-либо менять. Перекрытие реально, и ни одна опция профиля его не решает. Что вы можете исправить — это именование, чтобы следующий человек видел два диапазона вместо одного.
Честные исправления — перенумеровать одну сторону или транслировать адреса в офисе. Привязка одного маршрута хоста к маршрутизатору работает, пока адрес маршрутизатора не изменится, а затем становится второй загадкой поверх первой.
Сделайте так, чтобы решение пережило переподключение
Записи, введённые вручную, не переживают переподключение, а менеджер подключений перестраивает таблицу при каждом запуске профиля. Поместите решение туда, где создаётся подключение, будь это профиль или сохранённые настройки менеджера. Затем один раз намеренно перезапустите подключение, вместо того чтобы обнаруживать поведение во время звонка. Профиль, который работает только до следующего переподключения, не завершён.
Проверьте три пути сразу: офисный хост по буквальному адресу, тот же хост по имени и обычный публичный сайт. Средний зависит от службы имён, которую вы настроили после отказа от протолкнутых параметров DNS, и именно он тихо отказывает.