Ця адреса тунелю — партнер, а не підмережа для перегляду

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

Чому маска на тунельному з’єднанні виглядає неправильно

На інтерфейсі Ethernet адреса й маска стверджують дві речі: цей вузол володіє адресою, і все всередині префікса є прямим сусідом. Ядро виводить із цих двох фактів маршрут на з’єднанні, а потім розв’язує адреси з’єднання для сусідів, які, на його думку, присутні. Інтерфейс «точка-точка» зберігає володіння й відкидає сусідів, тому друга адреса в рядку клієнта — це дальній кінець, а не інший вузол у спільному сегменті. Немає апаратної адресації, трафіку розв’язування й широкомовного домену, до якого можна приєднатися, тому інтерфейс поводиться як труба рівно з одним призначенням.

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

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

Старіша топологія «точка-точка» дає кожному клієнту невеликий блок і використовує дві середні адреси, тому маска виглядає як фрагмент мережі, а не як пул. Топологія підмережі видає адресу з пулу з маскою пулу й називає тунельну адресу сервера партнером. Обидві дають робоче з’єднання, і різняться вони лише тим, які адреси з’являються в профілі та яку маску користувач, найімовірніше, поставить під сумнів.

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

Коли пул і офісна мережа претендують на ті самі біти

Оскільки з’єднання маршрутизується, пулу потрібен префікс, якого немає в жодній із мереж, доступних серверу. Поділіть один — і клієнт тримає єдиний маршрут для діапазону, що означає два місця, а яке місце переможе, вирішує маршрут, встановлений останнім. Збій проявляється на клієнті, хоча рішення за ним належить плану адрес. Користувачі повідомляють, що локальний маршрутизатор зникає, коли тунель піднімається, або що відповідають лише деякі офісні вузли.

Префікси, які лише виглядають схоже, — інший випадок, і порівняння октетів на око не є порівнянням префіксів. Випишіть обидва й порахуйте замасковані біти: 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

Якщо ці три збігаються, профіль робить те, для чого його налаштовано, а решта проблеми — в іншому місці. Змінюйте топологію лише з причини, що називає відсутню можливість, адже незнайома маска такою не є.