Зошто сопствениот DNS на рутерот го заобиколува VPN тунелот?

Барањата на клиентите го следат тунелот, додека сопствените барања на рутерот излегуваат преку WAN, а правилото на огнениот ѕид што управува со едното нема никакво влијание врз другото. Причината не е грешка: проследеното барање и барањето што рутерот сам го создава се два одделни текови и секое се споредува со различен дел од конфигурацијата. Фаќањето само на клиентската половина дава уверен одговор за пат што втората половина никогаш не го користи. Поправката е намерно да се насочи решавачот на рутерот, потоа двата пата да се тестираат одделно.

На кој тек всушност припаѓа фаќањето пакети

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

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

Практичната проверка е да се набљудуваат двете страни истовремено. На рутерот наведи го сокетот на решавачот, прашај го локално и фати го WAN интерфејсот:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Ако списокот на сокети покажува слушател врзан за адресата loopback или LAN, рутерот одговара локално наместо да проследи кон друг домаќин. Тогаш фаќањето покажува дали добиеното барање кон горе излегува преку интерфејсот на тунелот или преку WAN, и тоа е одговорот што правилото за политичко насочување никогаш не би го дало.

Зошто политичкото насочување никогаш не го гледа второто барање

Правилата на огнениот ѕид се пишуваат за интерфејс, извор, дестинација и порта и се оценуваат за пакети што минуваат низ уредот. Барањето што рутерот го создава не минува низ ништо, бидејќи локален процес го предава директно на табелата за насочување. Политичко насочување и NAT затоа важат само за проследениот пат, и токму затоа збир правила може да изгледа целосен, а сепак да го остави DNS на рутерот надвор од тунелот.

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

Каде решавачот на pfSense го одредува сопствениот пат кон горе

pfSense ја прави поделбата видлива. Сообраќајот на клиентите може да се насочува по политика низ VPN порта, додека сопствениот сообраќај на огнениот ѕид го следи излезното поставување на решавачот наместо LAN правилата. Во веб-интерфејсот тоа поставување е под Services > DNS Resolver > Outgoing Network Interfaces, а неговата вредност е списокот интерфејси што решавачот смее да ги користи за барања кон горе.

Наведувањето на интерфејсот на тунелот таму, и само тој интерфејс, е она што ги тера сопствените барања на рутерот да го следат тунелот. Ако се остави на стандардното, решавачот избира излез од табелата за насочување, што на домаќин со два WAN или VPN често е WAN.

Други фирмвери ја изложуваат истата одлука под друго име: список сервери кон горе врзан за адреса на извор, режим само на проследување или документирана политика на насочување. Поставувањето што треба да се бара е секогаш она што избира излез или извор за локално создадени барања. Референца за конфигурацијата на решавачот ја документира таа опција за pfSense и вреди да се прочита пред промената.

Избери го однесувањето при дефект пред поставувањето

Кога тунелот паѓа, две однесувања се браниви: да се запрат барањата кон горе за ништо да не истече, или да се врати на одобрен решавач на познат пат. И двете се политики и ниту едно не е она што се добива стандардно. Одлучи кое му треба на мрежата пред да го допреш списокот интерфејси.

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

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

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

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

Од LAN клиент, побарај од рутерот јавно име, а потоа приватно што само твојата внатрешна зона треба да го одговори. Неуспех само на второто барање укажува на проследување имиња, а не на тунелот:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Потоа спушти го тунелот и повтори ги двете барања. Одбиените одговори значат дека решавачот се затвора при дефект; успешен одговор укажува на резервен решавач и патот што го користел. Спореди го тоа со белешката што ја напиша и со фаќање на WAN интерфејсот направено во истата минута.

Држи ги набљудувањата одделно во записот: размената на клиентот со рутерот, размената на рутерот со серверот кон горе и конфигурацијата што ја одредила втората. Подоцнежна промена на насочувањето ќе ја искористи таа втора размена без предупредување. Одговор што пристигнува од друго место, а не од крајната точка на VPN, сам по себе не е истекување; станува истекување само кога конфигурацијата го избрала тој пат случајно.