Bakit nilalampasan ng sariling DNS ng router ang tunnel ng VPN?

Sinusundan ng mga paghahanap ng kliyente ang tunnel, samantalang lumalabas ang sariling paghahanap ng router sa WAN, at ang tuntunin ng firewall na namamahala sa isa ay walang epekto sa isa. Hindi bug ang dahilan: ang isang ipinasa na kahilingan at ang isang kahilingang nililikha ng router mismo ay dalawang hiwalay na daloy, at ang bawat isa ay itinutugma sa ibang bahagi ng kompigurasyon. Ang pagkuha lamang sa kalahati ng kliyente ay nagbibigay ng kumpiyansang sagot tungkol sa landas na hindi ginagamit ng ikalawang kalahati. Ang lunas ay sadyang itutok ang resolver ng router, pagkatapos subukan ang dalawang landas nang hiwalay.

Aling daloy talaga ang pag-aari ng pagkuha ng packet

Ang isang paghahanap ay may dalawang palitan. Nagpapadala ang kliyente sa LAN ng query sa resolver ng router, at dumarating ito bilang ipinasang trapiko sa interface ng LAN, kaya maaaring itugma ito ng patakaran sa ruta o tuntunin ng NAT na isinulat para sa mga ipinasang packet. Pagkatapos ay sumasagot ang router mula sa cache o, kapag wala, nagbubukas ng sariling query patungo sa server sa itaas.

Ang ikalawang query na iyon ay may router bilang pinagmulan at bilang sariling destinasyon, at pinipili ng plataporma ang landas nito mula sa ibang bloke ng kompigurasyon. Parehong may parehong pangalan ang dalawang palitan, at wala sa kanila ang kopya ng isa. Kaya't ang pagkuha na ginawa sa panig ng LAN ay nagpapatunay kung saan napunta ang packet ng kliyente at walang sinasabi tungkol sa palabas na packet.

Ang praktikal na pagsusuri ay pagmasdan ang dalawang panig nang sabay. Sa router, ilista ang socket ng resolver, tanungin ito nang lokal at kunin ang interface ng WAN:

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

Kung ang listahan ng socket ay nagpapakita ng tagapakinig na nakatali sa address ng loopback o LAN, sumasagot ang router nang lokal sa halip na ipasa sa ibang host. Pagkatapos ay ipinapakita ng pagkuha kung ang nagresultang upstream na query ay lumalabas sa interface ng tunnel o sa WAN, at iyon ang sagot na hindi kailanman ibibigay ng tuntunin sa ruta ng patakaran.

Bakit hindi kailanman nakikita ng patakaran sa ruta ang ikalawang query

Ang mga tuntunin ng firewall ay isinusulat laban sa isang interface, pinagmulan, destinasyon at port, at sinusuri ang mga ito para sa mga packet na dumadaan sa aparato. Ang query na nililikha ng router ay hindi dumadaan sa anuman, dahil ang isang lokal na proseso ay direktang naghahatid nito sa talahanayan ng ruta. Patakaran sa ruta at NAT kaya nalalapat lamang ang mga ito sa ipinasang landas, at iyon ang dahilan kung bakit ang isang set ng tuntunin ay maaaring magmukhang kumpleto at gayon pa man ay iiwan ang DNS ng router sa labas ng tunnel.

Ang pagkakaibang ito ay nananatili pagkatapos ng bawat muling pagsulat ng firmware dahil nagmumula ito sa landas ng packet at hindi sa isang katangian. Anumang nililikha ng aparato para sa sarili nito, maging mga query ng resolver, sinkronisasyon ng oras, pagsusuri ng update o pag-access sa mga salamin ng packet, ay lokal ang pinagmulan at nahuhulog sa parehong patay na anggulo. Iyon din ang dahilan kung bakit walang pinatutunayan ang pagsusuri mula sa laptop tungkol sa router.

Saan nagpapasya ang resolver ng pfSense ng sarili nitong upstream na landas

Ginagawang nakikita ng pfSense ang paghahati. Ang trapiko ng kliyente ay maaaring iruta ayon sa patakaran sa pamamagitan ng gateway ng VPN samantalang ang sariling trapiko ng firewall ay sumusunod sa setting ng labasan ng resolver sa halip na sa mga tuntunin ng LAN. Sa web interface, ang setting na iyon ay nasa ilalim ng Services > DNS Resolver > Outgoing Network Interfaces, at ang halaga nito ay ang listahan ng mga interface na maaaring gamitin ng resolver para sa mga upstream na query.

Ang pagbanggit doon ng interface ng tunnel, at ng interface na iyon lamang, ang siyang dahilan kung bakit sinusundan ng sariling paghahanap ng router ang tunnel. Kung iiwang sa default, pinipili ng resolver ang labasan mula sa talahanayan ng ruta, na sa host na may dalawang WAN o VPN ay madalas na WAN.

Ibinubunyag ng ibang firmware ang parehong pasya sa ibang label: listahan ng mga server sa itaas na nakatali sa address ng pinagmulan, mode na ipasa lamang, o dokumentadong patakaran sa ruta. Ang setting na hahanapin ay laging ang pumipili ng labasan o pinagmulan para sa mga query na nilikha nang lokal. Ang sanggunian sa kompigurasyon ng resolver ay nagdodokumento ng opsyong iyon para sa pfSense at sulit basahin bago ang pagbabago.

Piliin ang pag-uugali sa pagpalya bago ang setting

Kapag bumagsak ang tunnel, dalawang pag-uugali ang maipagtatanggol: ihinto ang mga upstream na query upang walang tumagas, o bumalik sa isang aprubadong resolver sa kilalang landas. Parehong patakaran ang mga ito, at wala sa kanila ang nakukuha bilang default. Magpasya kung alin ang kailangan ng network bago hawakan ang listahan ng interface.

Ang pagsasara sa pagpalya ay mas madaling ipagtanggol, ngunit ginagawang pagkawala ng resolusyon ng pangalan para sa bawat aparato sa likod ng router ang pagkawala ng tunnel. Ang pagbabalik ay nagpapanatiling magagamit ang opisina, sa halaga ng isang palitan sa itaas sa labas ng tunnel na dapat sadyang katanggap-tanggap at hindi aksidente. Isulat ang pinili, dahil ang susunod na taong makakakita ng address ng resolver sa labas ng VPN ay babasahin ito bilang pagtagas maliban kung may tala na nagsasabi ng iba. Ang talang iyon ang naghihiwalay sa dokumentadong pagbabalik mula sa hindi maipaliwanag na natuklasan sa pagsusuri ng susunod na quarter.

Dalawang kaso ang nagpapakumplikado sa pasya. Ang mga pribadong pangalan ay maaaring mangailangan ng panloob na resolver na nararating ng tunnel, at ang browser o aplikasyong may sariling naka-encrypt na DNS ay maaaring lumampas nang lubusan sa router, kaya't ang resolver na kinompigura mo ay hindi laging ang ginagamit ng isang partikular na app.

Subukan ang dalawang landas at panatilihing hiwalay ang mga resulta

Ang pagsusuri ng DNS sa browser ay sumasagot sa makitid na tanong: aling mga resolver ang ginamit ng browser na iyon, sa ilalim ng mga kondisyon ng pagsusuring iyon. Hindi nito iniimbentaryo ang mga aparato sa network at hindi nito nakikita ang query na nilikha ng router para sa sarili nito. Ituring ang output nito na isang datos at hindi bilang audit.

Mula sa kliyente sa LAN, humingi sa router ng pampublikong pangalan at pagkatapos ng pribadong pangalan na dapat sagutin lamang ng iyong panloob na sona. Ang pagpalya lamang sa ikalawang query ay tumuturo sa pagpapasa ng pangalan at hindi sa tunnel:

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

Pagkatapos ay ibaba ang tunnel at ulitin ang dalawang query. Ang mga tinanggihang sagot ay nangangahulugang nagsasara ang resolver sa pagpalya; ang matagumpay na sagot ay tumuturo sa pantulong na resolver at sa landas na ginamit nito. Ihambing iyon sa talang isinulat mo at sa pagkuha sa interface ng WAN na kinuha sa parehong minuto.

Panatilihing hiwalay ang mga obserbasyon sa talaan: ang palitan ng kliyente at router, ang palitan ng router at server sa itaas, at ang kompigurasyong nagpasya sa pangalawa. Ang susunod na pagbabago sa ruta ay gagamit sa ikalawang palitan na iyon nang walang babala. Ang sagot na dumarating mula sa ibang lugar maliban sa dulo ng VPN ay hindi pagtagas sa sarili nito; nagiging pagtagas lamang ito kapag pinili ng kompigurasyon ang landas na iyon nang aksidente.