Политичко рутирање у OpenWrt-у: ланац који хвата локални DNS

Клијенти на LAN-у решавају кроз тунел, а сопствене претраге рутера то тихо не чине. Ажурирања пакета, синхронизација времена и динамички DNS излазе редовним uplink-ом, док сваки прослеђени захтев узима VPN, и ништа у интерфејсу не указује да постоје два различита пута. Објашњење није грешка у политици већ питање која кука види пакет. Два тока, једна адреса резолвера, и само један од њих прелази рутер. Њихово раздвајање је цела поправка.

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

Први ток је онај који људи замишљају. Клијент пита резолвер рутера, резолвер прослеђује нагоре, и тај прослеђени пакет пролази кроз рутер на излазу. Тај пакет је видљив свему што посматра прослеђени саобраћај.

Други ток никада не пристиже ниоткуда. Рутер га ствара, па нема ни улазног пакета ни корака прослеђивања за подударање.

Оба могу циљати исту адресу резолвера, и управо зато је разлику лако пропустити. Иста дестинација, друго порекло, други ланац. Када угледате порекло, остатак дијагнозе следи.

Прослеђени и локално створени пакети улазе другачије

Прослеђени саобраћај се процењује када стигне са другог интерфејса. Пакети политичког рутирања то излажу као prerouting ланац, а правило постављено тамо види сваки пакет који прелази рутер. Зато се захтеви клијената понашају тачно како политика описује, и зато их рутер игнорише. Правило није погрешно, само је прикачено на куку до које рутер никада не стиже. Преместите га, и исто подударање почиње да ради.

Локално створени саобраћај ствара процес на рутеру и улази у излазну путању. Усмерава га сопствена одлука рутера и сусреће политику само ако политика покрива тај ланац. Нема улазног интерфејса за подударање ни одлуке о прослеђивању за посматрање.

То је својство места где се пакети рађају, а не било ког конкретног пакета. Правило написано за један ланац једноставно нема мишљење о другом. Никакво подешавање правила то не мења.

Изаберите излазни ланац, затим сузите подударање

Поправка је да исту намеру прикачите и на излазни ланац, или да преместите правило тамо када су вам важни сопствени захтеви рутера. У OpenWrt поставци изграђеној на пакету политичког рутирања, то значи да у подешавању ланца правила изаберете output уместо prerouting. Задржите оба правила ако обе популације требају покривеност.

Затим сузите на шта се правило подудара. Одредишне адресе резолвера на порту који резолвер заиста користи много су мања одлука од слања свега што рутер ствара у тунел.

Држите два правила експлицитним уместо да покушавате да напишете једно које покрива оба ланца. Одвојена правила су лакша за читање, и омогућавају вам да искључите путању рутера без ометања клијентског саобраћаја док отклањате грешке. Она такође чине бројаче смисленим један по један.

Држите сопствени транспорт тунела ван правила

Спољну везу тунела такође ствара рутер. Правило које шаље сав локално створени саобраћај у тунел усмераваће тунел кроз самог себе, и он се уопште неће подићи.

Приступ за управљање је друга жртва. Административне сесије настале на рутеру, или одговори на њих, могу бити увучене у тунел прешироким локалним правилом и постати недоступне са LAN-а.

Искључите крајњу тачку тунела из подударања, и држите правило ограничено на адресе резолвера. То је довољно за DNS захтев и довољно мало да се о томе размишља.

Тестирајте обе популације, не једну

Посматрајте како рутер прави сопствени захтев и забележите који интерфејс га је носио. Поновите претрагу са LAN домаћина и забележите којим је путем кренула. Бројачи на правилима политике чине оба одговора видљивим без нагађања.

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

Проверите и порт: правило које се подудара са одредишним портом 53 пропушта резолвер доступан преко DNS over TLS на 853 или HTTPS крајње тачке. Подударите транспорт који конфигурисани upstream заиста користи, и цурење се затвара из правог разлога.