Політична маршрутизація в OpenWrt: ланцюг, який ловить локальний DNS

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

Два потоки, одна адреса резолвера

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

Другий потік ніколи нізвідки не надходить. Його створює маршрутизатор, тому немає ні вхідного пакета, ні кроку пересилання для зіставлення.

Обидва можуть цілитися в ту саму адресу резолвера, і саме тому різницю легко проґавити. Та сама мета, інше походження, інший ланцюг. Щойно видно походження, решта діагностики випливає.

Переслані та локально створені пакети входять по-різному

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

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

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

Виберіть ланцюг виходу, потім звузьте зіставлення

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

Потім звузьте те, чому відповідає правило. Адреси резолвера призначення на порту, який резолвер справді використовує, — значно менше рішення, ніж надсилати в тунель усе, що створює маршрутизатор.

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

Тримайте власний транспорт тунелю поза правилом

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

Доступ для керування — друга жертва. Адміністративні сесії, що походять від маршрутизатора, або відповіді на них, можуть бути втягнуті в тунель надто широким локальним правилом і стати недосяжними з LAN.

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

Перевіряйте обидві групи, а не одну

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

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

Перевірте й порт: правило, що збігається з портом призначення 53, пропускає резолвер, доступний через DNS over TLS на 853 або кінцеву точку HTTPS. Зіставте транспорт, який налаштований upstream справді використовує, і витік закриється з правильної причини.