Политичко рутирање во OpenWrt: синџирот што го фаќа локалниот DNS

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

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

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

Вториот тек никогаш не пристигнува од никаде. Рутерот го создава, затоа нема влезен пакет ниту чекор на проследување за совпаѓање.

И двата можат да ја целат истата адреса на резолвер, и токму затоа разликата лесно се пропушта. Иста дестинација, различно потекло, различен синџир. Штом го видите потеклото, остатокот од дијагнозата следи.

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

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

Локално создадениот сообраќај го создава процес на рутерот и влегува во излезната патека. Го рутира сопствената одлука на рутерот и се среќава со политиката само ако политиката го покрива тој синџир. Нема влезен интерфејс за совпаѓање ниту одлука за проследување за набљудување.

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

Изберете го излезниот синџир, потоа стеснете го совпаѓањето

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

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

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

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

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

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

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

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

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

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

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