Какой источник IPv6 выбирает запрос VPN и почему это важно

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

Два поиска, а не один

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

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

Читайте правила как упорядоченное состязание

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

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

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

Привязка приложения меняет вопрос

Приложение может запросить конкретный адрес-источник, и корректный явный выбор переносит вопрос с «какой адрес предпочёл бы узел» на «может ли этот адрес достичь назначения и вернуться». Инструменты, которые привязываются к источнику или запрашивают дополнительные данные о выбранном адресе, показывают это напрямую, и они — самый быстрый способ доказать, какой адрес соединение действительно использовало. Этот эксперимент лучше третьего чтения таблицы маршрутизации, потому что сообщает, что решило ядро, а не то, что вы настроили. Повторите его после изменения и сравните два ответа.

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

Проверьте, что дальняя сторона принимает этот источник

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

Держите адрес внешней конечной точки отдельно и в своих рассуждениях. Он обозначает транспорт между участниками VPN и не является источником пакета приложения внутри.

Решайте по четырём наблюдениям

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

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