Ваш клиент подключается и показывает пару адресов или один адрес с маской 255.255.255.255, и первая реакция — что сервер выдал что-то сломанное. Ничего не сломано: туннельный интерфейс — это соединение «точка-точка», и маска описывает дальний конец этого одного соединения, а не диапазон соседей. Чтение пары как локального адреса и партнёра объясняет странную маску, маршрут к одному узлу рядом с ней и отсутствующую таблицу соседей. Чего то же чтение не оправдывает — плана адресов, который пересекается с офисной сетью.

Почему маска на туннельном соединении выглядит неправильно

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

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

Две топологии, две формы адреса

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

TopologyClient address shapePeerRoute to expect
Point-to-point block per clientTwo neighbouring addresses inside a small blockThe far address of that blockA single host route on the tunnel device
Shared poolOne address carrying the pool maskThe server's tunnel addressA single host route on the tunnel device

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

Когда пул и офисная сеть претендуют на одни и те же биты

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

Префиксы, которые лишь выглядят похоже, — другой случай, и сравнение октетов на глаз не является сравнением префиксов. Выпишите оба и посчитайте замаскированные биты: 192.168.4.0/24 против 192.168.6.0/24 совпадают до бита 22 и расходятся на бите 23, потому что третий октет читается как 00000100 против 00000110, так что эти две сети действительно различны. Поставьте 10.8.0.0/24 рядом с другим 10.8.0.0/24 и все 24 замаскированных бита совпадут, а значит, один маршрут не может выразить оба места. Длина маски определяет, где сравнение останавливается, и сеть, установленная второй, проигрывает.

Что не может доставить маршрутизируемое соединение

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

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

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

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

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

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

Похожие статьи