Политическа маршрутизация в OpenWrt: веригата, която хваща локалния DNS

Клиентите в LAN резолват през тунела, а собствените търсения на рутера тихо не го правят. Актуализациите на пакети, синхронизацията на времето и динамичният DNS излизат по обикновения канал, докато всяка препратена заявка поема през VPN, и нищо в интерфейса не подсказва, че съществуват два различни пътя. Обяснението не е грешка в политиката, а въпрос на коя кука вижда пакета. Два потока, един адрес на резолвер и само един от тях пресича рутера. Разделянето им е цялата поправка.

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

Първият поток е този, който хората си представят. Клиент пита резолвера на рутера, резолверът препраща нагоре и този препратен пакет преминава през рутера по пътя си навън. Този пакет е видим за всичко, което наблюдава препратения трафик.

Вторият поток никога не пристига отникъде. Рутерът го създава, затова няма входящ пакет и няма стъпка на препращане за съпоставяне.

И двата може да са насочени към един и същ адрес на резолвер, поради което разликата лесно се пропуска. Същата дестинация, различен произход, различна верига. Щом видите произхода, останалата част от диагнозата следва.

Препратените и локално генерираните пакети влизат различно

Препратеният трафик се оценява, когато пристигне от друг интерфейс. Пакетите за политическа маршрутизация го представят като верига prerouting и правило, поставено там, вижда всеки пакет, пресичащ рутера. Затова заявките на клиентите се държат точно както описва политиката и затова рутерът я игнорира. Правилото не е грешно, то просто е прикачено към кука, до която рутерът никога не достига. Преместете го и същото съвпадение започва да работи.

Локално генерираният трафик се създава от процес на рутера и вместо това влиза в изходния път. Той се маршрутизира от собственото решение на рутера и среща политика само ако политиката покрива тази верига. Няма входящ интерфейс за съпоставяне и няма решение за препращане за наблюдение.

Това е свойство на мястото, където се раждат пакетите, а не на който и да е конкретен пакет. Правило, написано за една верига, просто няма мнение за другата. Никакво количество настройка на правилата не променя това.

Изберете изходната верига, после стеснете съвпадението

Поправката е да прикачите същото намерение и към изходната верига, или да преместите правилото там, когато собствените заявки на рутера са това, което ви интересува. В настройка на OpenWrt, изградена върху пакет за политическа маршрутизация, това означава да изберете output вместо prerouting в настройката за верига на правилото. Задръжте и двете правила, ако и двете популации се нуждаят от покритие.

След това стеснете какво съвпада правилото. Адресите на резолвера по дестинация на порта, който резолверът действително използва, е много по-малко решение от изпращането на всичко, което рутерът създава, в тунела.

Дръжте двете правила явни, вместо да се опитвате да напишете едно, което покрива и двете вериги. Отделните правила се четат по-лесно и ви позволяват да изключите пътя на рутера, без да смущавате клиентския трафик, докато отстранявате проблеми. Те също правят броячите смислени един по един.

Дръжте собствения транспорт на тунела извън правилото

Външната връзка на тунела също се създава от рутера. Правило, което изпраща целия локално генериран трафик в тунела, ще маршрутизира тунела през себе си и той изобщо няма да се вдигне.

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

Изключете крайната точка на тунела от съвпадението и задръжте правилото ограничено до адресите на резолвера. Това е достатъчно за изискването за DNS и достатъчно малко, за да се обмисли.

Тествайте и двете популации, не една

Наблюдавайте рутера да прави собствената си заявка и отбележете кой интерфейс я е понесъл. Повторете търсенето от LAN хост и отбележете пътя, който е поел. Броячите на правилата за политика правят и двата отговора видими без гадаене.

Третирайте резултатите като две находки. Клиент, който резолва през тунела, не казва нищо за рутера, а рутер, който резолва правилно, не казва нищо за клиент на друг слушател. Запишете ги като отделни редове в записа за промяната.

Проверете и порта: правило, съвпадащо дестинационен порт 53, пропуска резолвер, достигнат през DNS over TLS на 853 или HTTPS крайна точка. Съпоставете транспорта, който конфигурираният upstream действително използва, и изтичането се затваря по правилната причина.