WireGuard DNS sa iPhone: ang domain ay hulapi ng paghahanap lamang

Nagsusulat ka ng isang linya na may address ng resolver at domain ng kumpanya, umaasang ang mga pangalan lamang sa domain na iyon ang gagamit ng resolver ng tunnel. Sa Apple client, lahat ng pangalan ay pumupunta na roon, at ang maiikling pangalan sa domain ay nareresolba rin. Dalawang magkaibang bagay ang ginagawa ng linya, at isa lamang sa mga ito ang tungkol sa kung aling mga query ang hinahawakan ng tunnel. Ang isa pa ay kaginhawaan sa pagta-type na inangat sa patakaran ng pag-asang pagbasa.

Ano ang pinaghihiwalay ng linya ng DNS

Binabasa ng client ang entry bilang listahan at inuuri ang bawat item ayon sa hugis. Anumang mukhang address ay nagiging DNS server; anumang mukhang domain ay nagiging hulapi ng paghahanap. Parehong napupunta sa mga setting ng tunnel, ngunit sa magkaibang field. Ang isang halimbawang linya para sa tunnel na may pribadong resolver at isang panloob na domain ay ganito ang hitsura.

DNS = 10.24.8.53, lab.internal.example

Ang address ay nagbibigay ng resolver. Ang domain ay nagbibigay ng hulapi na nagpapahintulot sa client na mag-type ng maiikling pangalan at sa system na idagdag ang natitira bago magtanong. Wala sa dalawa ang nagsasabi ng anuman tungkol sa paglimita ng resolver sa domain na iyon, at iyon ang bahaging inaasahan ng mga tao ngunit hindi nakukuha. Isang field lamang sa platform ang makapagsasabi ng paghihigpit na iyon, at hindi ito ang field na ito.

Dalawang field ng Apple, dalawang magkaibang trabaho

Inilalantad ng Apple ang pagkakaiba sa object ng mga setting ng DNS nito. Ang listahan ng domain ng paghahanap ay nakadokumento bilang listahan na ginagamit upang kwalipikahin ang mga hostname na may isang label: mag-type ng hubad na hostname at maaaring idagdag ng system ang bawat hulapi nang sunud-sunod. Ito ay tuntunin ng pagkumpleto, hindi tuntunin ng routing. Wala sa listahang iyon ang nagpapasya kung aling server ang tatanungin.

Ang listahan ng domain ng pagtutugma ay ibang katangian. Ito ang nagpapasya kung aling mga namespace ang gumagamit ng set na ito ng mga setting ng DNS, at ang walang laman na entry ay nangangahulugang ang default na domain at hindi isang partikular na hulapi. generator ng mga setting ng packet tunnel sa Apple client ay sumusunod sa modelong iyon. Inilalagay nito ang mga nasuri na hulapi ng paghahanap sa listahan ng paghahanap, at kapag may mga server, itinatakda nito ang listahan ng pagtutugma sa walang laman na string. Ang resulta ay isang resolver ng tunnel na sumasagot sa lahat ng ipinapadala ng system dito, kasama ang isang hulapi na tumutulong sa maiikling pangalan.

Kaya ang domain sa linyang iyon ay hindi tagapili ng namespace. Ang pagdaragdag ng isa pa ay hindi nagpapaliit sa kung aling mga query ang ginagamit ng tunnel, at ang pag-alis nito ay hindi rin nagpapalawak. Ang tanging nagbabago ay kung ilang maiikling pangalan ang nakukumpleto.

Bakit ang bawat pangalan ay umaabot pa rin sa resolver ng tunnel

Sa walang laman na entry ng pagtutugma, ang tunnel ay kandidatong resolver para sa mga ordinaryong pangalan, hindi lamang para sa domain ng kumpanya. Sa isang full-tunnel na configuration, kadalasan ay hindi ito gaanong mahalaga, dahil ang lahat ng trapiko ay nasa tunnel na. Sa isang split tunnel, napakahalaga nito. Ang mga pampublikong pangalan ay maaaring resolbahin na ngayon ng isang resolver na may pribadong zone lamang, at ang pagkabigo ay mukhang sirang VPN kapag sa katunayan ito ay resolver na sumasagot lamang sa bahagi ng namespace. Maayos ang tunnel, lumalabas ang mga query, at bumabalik na walang laman ang mga sagot.

May dalawang pag-aayos at magkaibang desisyon ang mga ito. Gawing kumpletong resolver ang resolver ng tunnel na nagpapasa ng mga pampublikong pangalan sa aprubadong landas, o itigil ang pagpapadala ng mga pampublikong pangalan doon sa pamamagitan ng pagbabago ng configuration ng client sa halip na listahan ng domain. Ang una ay nagpapanatili ng bawat query sa tunnel at nagtitiwala sa upstream. Ang pangalawa ay nagpapanatili ng ilang query nang lokal at tinatanggap na ang mga pribadong pangalan ay maaaring tumigil sa pagresolba habang patay ang tunnel.

Ano ang talagang kailangan ng split DNS

Ang patakaran ng resolver na limitado sa namespace ay nangangailangan ng client na nagpapahintulot sa iyo na ipahayag ito: itugma ang mga domain sa mga platform ng Apple, o katumbas na setting sa produktong ginagamit mo. Ang field ng configuration na tumatanggap lamang ng mga server at hulapi ay hindi ito maipahahayag, gaano man ito kapuntuwasyon. Ang profile ay makapagdadala ng patakaran dahil inilalarawan nito ang pinamamahalaang configuration at hindi pahiwatig sa oras ng pagkonekta. Maaari nitong pangalanan ang domain, ang mga server, at kung ano ang dapat mangyari kapag hindi maabot ang domain na iyon. Iyon ang pagkakaiba ng isang setting at isang kontrata.

Sa mga pinamamahalaang Apple device, karaniwang ibinibigay ito sa pamamagitan ng configuration profile na nagdadala ng mga setting ng DNS na partikular sa domain. Iba itong mekanismo sa configuration file ng WireGuard, at ang dalawa ay maaaring magkasama lamang kung iginagalang ng client ang profile. Tingnan kung ano talaga ang itinatawag ng client mo sa field bago ipagpalagay na pareho ang kilos ng dalawang produkto. Ang script na may wg-quick sa Mac at ang WireGuard app sa iPhone ay nagbabasa ng magkatulad na linya at ini-install ang mga ito sa pamamagitan ng iba't ibang layer.

Basahin ang mga naka-install na setting, hindi ang configuration

Sa Mac maaari mong siyasatin kung ano ang napuntahan ng system, na mas nagbibigay-kaalaman kaysa sa muling pagbasa ng file na isinulat mo. Ipinapakita ng listahan ng resolver kung aling mga server ang naka-configure para sa aling mga domain, at ipinapakita ng mga scoped query kung alin ang nanalo. Ang client na sumisira sa linya ay nagpapakita nito rito at hindi sa file na isinulat mo. Sa iOS walang katumbas na command line, kaya ang ebidensya doon ay isang resulta: isang pribadong pangalan na nareresolba sa tunnel, at isang pampublikong pangalan na ang sagot ay naghahayag kung aling resolver ang sumagot.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Ang dalawang command na ito ay nagpi-print ng kasalukuyang configuration ng resolver at ng mga DNS server ng aktibong serbisyo. Kung ang resolver ng tunnel ay lumilitaw bilang default na resolver na walang paghihigpit sa domain, ginagawa ng configuration ang eksaktong hiniling ng client. Ayusin ito sa pamamagitan ng pagbabago ng mekanismo, hindi sa pagdaragdag ng pangalawang hulapi at pag-asa na magbabago ang kilos.