Відповідь виходить через LAN, а не через тунель: чому і як

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

Що насправді визначає вихідний пакет

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

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

Чому перемагає локальна підмережа

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

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

Покриття пірів не те саме, що встановлені маршрути

На боці тунелю дозволені діапазони партнера описують, що можна надсилати в тунель і які джерела з нього приймаються. Вони нічого не кажуть про те, куди локальна таблиця маршрутизації надішле пакет.

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

Виберіть таблицю за адресою джерела

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

Спочатку підтвердьте шлях, потім службу

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Вивід має називати тунель. Потім перевірте джерело, якого ви не торкалися, і підтвердьте, що воно досі використовує локальний зв'язок, тож зміна залишилася в межах однієї адреси. Ширший селектор нічого не довів би щодо початкової скарги.

Чого це не виправляє

Залиште пересилання, правила брандмауера й поведінку ICMPv6 на шлюзі такими, якими вони були, бо маршрут за джерелом не замінює нічого з цього. Відсутнє повідомлення Packet Too Big і далі ламає великі відповіді, яка б таблиця не виграла пошук. Виправте це до додавання правил маршрутизації, інакше симптом переживе зміну.

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

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