Hatiang DNS at VPN: ang mga patakaran ng domain ay hindi ruta ng IP
Pinipili ng hatiang DNS ang resolver ayon sa pangalan, at ang sagot ay kailangan pa rin ng ruta. Subukan ang tuntunin ng domain at ang landas nang hiwalay, sa platform na talagang pinapatakbo mo.
Niresolba ng iyong laptop ang intranet.corp sa pamamagitan ng tunnel habang ang gitlab.com ay patuloy na pumupunta sa resolver ng provider, at ito ang kaayusang gumagana ayon sa disenyo. Dalawang magkahiwalay na desisyon ang lumikha nito: pinili ng tuntunin sa pagtutugma ng pangalan ang resolver, at nagdala pabalik ng sagot ang isang ruta. Sirain ang alinman sa dalawa at ang browser ay magpapakita ng pagkabigo na mukhang pareho mula sa labas. Karamihan sa mga ulat tungkol sa hatiang DNS ay naglalarawan ng pangalawang pagkabigo habang sumisipi ng ebidensya tungkol sa una.
Ang dalawang hati ay nakatira sa magkaibang lugar at karaniwang ine-edit ng magkaibang tao. Ang isa ay patakaran ng DNS na nakakabit sa profile ng VPN, ang isa ay rutang ini-install o hinahawakan ng tunnel. Humihinto ang pag-debug kapag walang nagtatatag kung aling hati ang talagang gumalaw.
Dalawang desisyong nakatago sa isang kahilingan
Ang hati ng pangalan ay bagay ng patakaran, hindi ruta. Sa Windows ito ay patakaran sa pagresolba ng pangalan sa profile ng VPN; sa mga platform ng Apple isang set ng mga tugmang domain sa isang bagay ng mga setting ng DNS; sa Linux isang domain ng routing, isang linyang hati ng resolver o ang pagkakasunod-sunod ng switch ng serbisyo ng pangalan. Ang hati ng landas ay ordinaryong routing, ini-install ng tunnel o sa kamay, at wala itong kaalaman kung ano ang hostname. Ang profile na tumatanggap ng suffix ay nagpapasya lamang kung sino ang sasagot; hindi nito ginagawang maabot ang sagot.
Isang mabilis na pagsubok ng sintomas ang naghihiwalay sa kanila: palitan ang pangalan ng address. Kung gumagana ang address, maayos ang landas at mali ang tuntunin. Kung nabigo rin ang address, maaaring tama ang tuntunin at kulang ang landas.
Paano ipinapahayag ng bawat platform ang parehong tuntunin ng pangalan
Ang layunin ay magkapareho at ang mga pangalan ng field ay hindi. Ang halimbawang kinopya mula sa isang kliyente patungo sa isa pa ay malinis na napa-parse at hindi kailanman tumutugma. Ganito ang tatlong anyo:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Ang domain ng pagtutugma o routing ay pagsubok ng suffix, kaya sinasaklaw ng intranet.corp ang git.intranet.corp at hindi sinasaklaw ang corp.intranet, at ang pagbabaliktad nito ang pinakakaraniwang pagkakamali sa buong setup. Dinadala ng Windows ang mapping bilang patakaran sa pagresolba ng pangalan na nakakabit sa profile, na may sariling pagkakasunod-sunod ng priyoridad laban sa anumang listahan ng suffix na mayroon na ang interface. Ikakabit ng mga platform ng Apple ang mga tugmang domain sa bagay ng mga setting ng DNS ng extension ng network, at inilalapat ito ng system sa bawat resolver na may saklaw. Wala sa mga anyong ito ang ruta, at wala ring makakagawa ng maabot ang isang address na hindi maabot. Ang sangguniang patakaran sa pagresolba ng pangalan ng Windows ay naglilista ng mga pangalan ng field at mga tuntunin ng priyoridad para sa platform na iyon, at hindi ito ang ginagamit ng mga dokumento ng Apple o systemd.
Ang tamang sagot ay nangangailangan pa rin ng landas
Ang sagot ng resolver ay address lamang, at kailangan pa ring maabot ito ng aplikasyon. Madalas itulak ng disenyo ng hatiang tunnel ang 10.20.0.0/16 at hawakan ang default na ruta, kaya naresolba ang panloob na pangalan at pagkatapos ay nabibitin ang koneksyon. Ang kabaligtarang kaso ay kasingkaraniwan: may ruta, sinasagot ng pampublikong resolver ang pribadong pangalan ng NXDOMAIN, at ang pagkabigo ay naitala bilang problema sa routing. Ang pagsubok muna sa landas ay nag-iiwan sa iyong nakatitig sa mga ruta para sa pangalang hindi kailanman mairesolba.
Mayroon ding ikatlong pintuan na hindi sinasaklaw ng alinmang hati. Ang ACL sa gateway, patakaran ng firewall o patakaran sa gilid ng kliyente ay maaaring magpabagsak ng koneksyon pagkatapos na tama ang dalawang desisyon. Kapag naresolba ang pangalan, may ruta at nag-time out pa rin ang koneksyon, itigil ang pagsubok sa DNS.
Pagsubok sa mga pangalan at landas sa takdang pagkakasunod-sunod
Pumili ng pagkakasunod-sunod at panatilihin ito, kung hindi ay hahabulin mo ang hakbang na huling nabigo. Iresolba ang dokumentadong buong panloob na pangalan, tiyakin na ang sagot ay address na kayang dalhin ng talahanayan ng ruta, pagkatapos ay ulitin gamit ang pampublikong pangalan upang patunayang hindi nahuli ng tunnel ang lahat. Sa host na systemd ang query at ang domain ng routing ng resolver ay isang utos ang layo sa isa't isa:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Ang kliyente ng Windows ay nagtatanong ng parehong dalawang tanong gamit ang ibang cmdlet. Ang pangalawa ay nag-uulat ng interface na talagang gagamitin ng system:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Kung nagbabalik ng address ang paghahanap at pinapangalanan ng pagsusuri ng landas ang pisikal na interface, gumana ang tuntunin ng pangalan at hindi ang ruta. Kung nabigo ang maikling pangalan habang naresolba ang buong pangalan, mali ang listahan ng suffix at hindi ang resolver.
Kung saan karaniwang nagkakamali ang paghahambing
Ang unang pagkakamali ay ang magtanong sa walang kaugnayang pampublikong resolver tungkol sa pribadong pangalan at basahin ang pagtanggi bilang ebidensya tungkol sa VPN. Ang pangalawa ay ipagpalagay na ang gumaganang pampublikong paghahanap ay nagpapatunay sa landas ng resolver ng tunnel. Ang pangatlo ay ituring ang hatiang tunneling at hatiang DNS bilang isang desisyon sa disenyo, gayong ang deployment ay maaaring tama sa isa at sira sa isa. Bawat pagkakamali ay nagbubunga ng kumpiyansang konklusyon mula sa pagsubok na hindi kailanman nagpraktis sa bahaging pinagbibintangan.
Ang browser na may sariling secure na DNS ay maaari ring laktawan ang tuntunin ng system, kaya ang pagkabigo ng isang browser habang nagtatagumpay ang isa ay hindi kontradiksyon. Ihambing ang resolver na sumagot, hindi ang browser na nagreklamo.
Kapag nakita na ang dalawang hati, ang natitirang tanong ay patakaran at hindi teknikal: aling mga namespace ang pag-aari ng organisasyon, sino ang may-ari ng bawat sagot, at alin sa mga ito ang dapat umalis sa makina. Isulat iyon sa tabi ng profile, dahil kakailanganin ito ng susunod na taong gagalaw sa tuntunin.