Internaj nomoj malsukcesas ĉe VPN dum publikaj retejoj funkcias

Unu uzanto raportas, ke la intraneta gastnomo ne solviĝas tra la VPN. Dua raporto, de la sama tekkomputilo, diras ke lika testo ankoraŭ montras demandojn responditajn de la loka solvilo. Ili sonas kiel unu problemo kaj estas du, kun malsamaj pruvoj, kaj la kutima riparo por la unua plimalbonigas la duan. Apartigu ilin antaŭ ol tuŝi ajnan agordon.

Du simptomoj, kiuj ne estas unu paneo

Malsukceso solvi internan nomon signifas, ke la demando iris tien, kie ne ekzistas respondo por ĝi. Demandoj forlasantaj la tunelon signifas, ke la demando iris al la malĝusta loko eĉ kiam la respondo estis havebla. Tiuj estas kontraŭaj paneoj: unu estas mankanta respondo, la alia estas superflua celo.

La kaptilo estas, ke aldoni la oficejan solvilon ĉie riparas la unuan kaj garantias la duan. Aldoni publikan solvilon ĉie faras la malon.

Notu ambaŭ observojn kun tempstampo, poste trairu la kvar kontrolojn sube laŭ ordo.

Kiu adaptila solvilo ricevas la demandon

En Windows la DNS-kliento elektas servilojn laŭ la bindado-ordo de la adaptiloj, kaj la tunela adaptilo ne estas aŭtomate la unua. Malfermu la altnivelajn agordojn de la adaptilo kaj movu la fora-alira ligilon super la fizikan adaptilon, poste rekonektu por ke la ŝanĝo validu en nova seanco.

Bindado-ordo estas nur la unua duono. La kliento ankaŭ devas scii, kiuj nomoj apartenas al tiu adaptilo, kaj tio estas sufiksa demando, ne orda demando.

Metu la eligon de ipconfig /all de la funkcianta maŝino apud tiu de la tekkomputilo, ambaŭ prenitaj dum la tunelo staras. La funkcianta maŝino montros ligo-specifan DNS-sufikson sur sia oficeja adaptilo, kaj la tekkomputilo eble montros neniun sur la tunelo. Tiu diferenco klarigas tutan klason de raportoj de la tipo la servilo estas ĝuste tie kaj la nomo ankoraŭ malsukcesas, ĉar sen sufikso la mallonga nomo neniam kompletiĝas al la zono, kiun servas la oficeja solvilo.

Mallonga nomo bezonas sufikson antaŭ ol itineron

Tajpi nekvalifikitan gastnomon petas la solvilon diveni domajnon. La diveno venas de la sufiksa listo alligita al la ligilo, kaj se tiu listo estas malplena, la demando eliras kiel unu sola etikedo, kiun neniu privata zono kongruos.

Kopiu la sufikson de la funkcianta maŝino en la IPv4-ecojn de la VPN-adaptilo en la langeto DNS, poste rekonektu. En Linux la ekvivalento estas la serĉa domajno sur la tunela ligilo, kiun systemd-resolved montras po ligilo kaj ne tutmonde.

Tenu la du agordojn aparte en viaj notoj. La sufikso ŝanĝas, kio estas demandata; la solvila adreso ŝanĝas, kiu estas demandata. Ripari unu dum la alia malĝustas produktas rezulton, kiu aspektas hazarda.

Demandu la solvilon rekte, poste la nomon

Rekta demando al la oficeja solvilo apartigas nomproblemon de vojproblemo, ĉar ĝi tute preteriras la solvilan elekton de la kliento.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

La unua komando demandas specifan servilon pri plene kvalifikita nomo. Se ĝi respondas, la solvilo kaj la itinero al ĝi estas en ordo kaj la paneo estas en la elekto aŭ la sufikso. Se la tempo elĉerpiĝas, la adreso malĝustas aŭ neatingeblas kaj la problemo estas en encirkulado, ne en DNS. La dua komando montras, kio okazas kun la mallonga nomo, kaj la tria presas la solvilan agordon po ligilo sur systemd-gastiganto.

Atentu sovaĝkartajn respondojn, kiujn iuj retoj redonas por nekonataj nomoj. Kredinda respondo ne pruvas, ke la celita servilo respondis, do komparu la redonitan adreson kun tiu, kiun la interna servo efektive uzas. Se la adreso apartenas al parkuma paĝo aŭ al prokuro, la solvilo respondis, sed la respondo neniam estis via. Tiu distingo ŝparas horon da ĉasado de tunelo, kiu funkciis la tutan tempon.

En Linux VPN-kliento, kiu reskribas /etc/resolv.conf, anstataŭigas la lokajn solvilojn tute. vpnc elmetas DNSUpdate no por malhelpi tion, kaj systemd-resolved povas enkursigi nur la listigitajn domajnojn al la tunela ligilo. Ambaŭ aliroj tenas publikajn nomojn ĉe la loka solvilo kaj sendas internajn nomojn al la oficejo.

Likoj estas regulo, ne markobutono

Nomsolvado estas UDP-interŝanĝo al pordo 53, do tunelo, kiu portas retan trafikon sed ne UDP, lasas la demandon sur la fizika vojo. Pruvu tion kaptante sur la fizika retkarto dum publika nomo solviĝas. Demando videbla sur tiu interfaco en legebla formo signifas, ke la tunelo ne portas ĝin.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Se la demando aperas sur tiu interfaco en legebla formo, la tunelo ne portas ĝin. La riparo estas regulo, kiu permesas pordon 53 nur al la solvilo, kiun la VPN puŝis, kaj forĵetas aliajn celojn, plus klienta agordo, kiu ne forĵetas silente la puŝitan opcion.

Tiu lasta parto gravas pli, ol ĝi aspektas. Lanĉu OpenVPN kun route-nopull kaj la puŝita DNS-opcio malaperas kune kun la itineroj, se la eltira filtrilo ne estas larĝigita por teni ĝin. Kaj kliento, kiu ignoras dhcp-option DNS, daŭre uzos tion, kion ĝi havis antaŭe. Ĉiu ŝanĝo ĉe la servila flanko bezonas novan seanon por validi, ĉar la solvila listo estas liverata kiam la tunelo leviĝas kaj malnova seano daŭre montras la malnovan staton.

Notu, kiun paneon vi efektive observis antaŭ ol fermi la bileton. Mankanta interna respondo kaj demando eskapanta el la tunelo postulas malsamajn riparojn, kaj sufiksa ŝanĝo, kiu riparas la unuan, povas silente plimalbonigi la duan. Kiu prenos la bileton poste, fidos la etikedon, do faru la etikedon preciza.