Hvers vegna innri hýsitölvur leysast í dig en mistakast í curl á VPN

Fartölvan þín er á VPN, dig service.internal.example svarar með 10.x vistfangi og curl hættir samt með Could not resolve host. Göngin eru ekki vandamálið: þau fluttu dig-fyrirspurnina án kvartana. Það sem er ólíkt er hver spyr. dig sendir eina fyrirspurn á einn netþjón sem þú tilgreinir, en curl fer í gegnum uppflettikeðju stýrikerfisins, og sú keðja hefur sínar eigin reglur um hvaða netþjón er spurður.

Tvær uppflettingar fyrir sama nafn

dig er sinn eigin stub-resolver. Það les /etc/resolv.conf, velur nafnaþjón, sendir eina A- eða AAAA-fyrirspurn og birtir svarið. Það sleppir nsswitch algjörlega og veit ekkert um stöðu hvers tengils sem systemd-resolved eða NetworkManager heldur utan við þá skrá, og þess vegna getur dig-svar verið rétt og samt sagt þér ekkert um það sem forritið þitt mun sjá.

Forrit kalla á getaddrinfo, og getaddrinfo gengur eftir lengri keðju: röð eininga í nsswitch, svo einingunni sem sér um nafnið og loks resolverinum sem byggður er úr núverandi tengilstillingum. Á systemd-vél fer fyrirspurnin til 127.0.0.53 og systemd-resolved velur yfirnetþjón fyrir hvern tengil út frá leiðardómeninu sem er tengt tun-snertingunni.

Tvær skipanir aðskilja þessi lög án þess að giska:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent notar sama slóð og curl, svo getent-villa við hlið virkrar dig staðsetur bilunina í uppflettistefnunni en ekki í pakkaleiðunum. resolvectl query birtir líka snertinguna og yfirnetþjóninn sem gaf svarið, sem sýnir hvort göngutengillinn eða líkamlegi tengillinn vann ákvörðunina.

Lestu resolverinn sem forritið notar í raun

/etc/resolv.conf er myndað á flestum skjáborðum, og VPN-þjónn hefur þrjár leiðir til að eiga við það: setja nafnaþjón fyrst, skrifa yfir skrána eða afhenda netþjóna sína NetworkManager og láta dæmoninn endurskrifa hana. Aðeins þriðja mynstrið varðveitir DNS fyrir hvern tengil, því netþjónarnir haldast tengdir snertingu í stað þess að vera fletjaðir í einn alþjóðlegan lista.

Á NetworkManager-kerfum fer útkoman eftir bakendanum í /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Með dns=default eru netþjónar þjónsins sameinaðir í resolv.conf í þeirri röð sem vinnur, og einkauppfletting getur samt farið til opinbera resolverins. Með bakenda sem skilur tengla, systemd-resolved eða dnsmasq, haldast netþjónar ganganna bundnir við göngin og aðeins nöfn sem passa við leiðardómen þeirra fara þangað. Þessi afmörkun er það sem split DNS þýðir í reynd, og hún er sá hluti sem oftast vantar þegar þjónn segist styðja hana.

Lestu stöðuna áður en þú breytir einhverju:

resolvectl status
resolvectl dns tun0

Þú vilt sjá tun-snertinguna skráða með DNS-netþjóni og leiðardómeni fyrir einkaviðskeytið, birt sem ~internal.example. Enginn netþjónn á tenglinum þýðir að þjónninn sendi ekkert. Netþjónn án dómens þýðir að uppflettingar fara allar þangað eða engar, eftir þjóninum, og hvorugt er split DNS.

Þar sem nsswitch endar uppflettinguna of snemma

Stöðluð skjáborðslína lítur svona út:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal sér um multicast-DNS og gerir tilkall til hvers nafns sem endar á .local. Kubernetes-þjónusta eins og api.infra.svc.cluster.local endar líka á .local. Þegar mDNS-einingin tilkynnir NOTFOUND, endar aðgerðin [NOTFOUND=return] alla uppflettinguna í stað þess að halda áfram til dns-einingarinnar, svo nafnið er aldrei sent til VPN-resolverins. dig sneiðir algjörlega fram hjá skránni, og það er einmitt ástæðan fyrir því að verkfærin tvö eru ósammála.

Þetta er skýrasta andstæðan í þessu vandamáli, og hún snýst um eitt orð í stillingaskrá sem er eldri en VPN-ið þitt. Að breyta aðgerðinni í [NOTFOUND=continue] heldur mDNS fyrir prentara og staðbundin tæki á meðan DNS getur séð nafnið. Að skipta línunni út fyrir hosts: files dns virkar líka og er grófara: það felldir .local-uppflettingu fyrir prentarann sem þú notar í raun.

Nöfn sem búa í nákvæmlega einu neti

Einkanetsvæði eru ráðandi á nákvæmlega einum stað. AWS-nafn eins og ip-10-0-4-31.eu-west-1.compute.internal er svarað í gegnum VPC-resolver þess svæðis, og aðeins á meðan VPN-endapunkturinn þinn er á sama svæði og auðlindin. Tengstu endapunkti í Frankfurt, flettu upp compute.internal-nafni frá Írlandi, og engin staðbundin stilling hjálpar: svæðið sem heldur færslunni er ekki aðgengilegt þaðan.

Leitardómen búa til spegilmyndina. Bert service er fyllt út með því viðskeyti sem resolverinn telur eiga við, og með VPN-tengli getur staðbundið dómen unnið á því fyrirtækisins. Flettu upp með punkti í lokin til að fjarlægja giskunina, getent ahosts service.internal.example., og ef það virkar á meðan stutta nafnið mistekst, er réttingin leitardómenið á göngunum, ekki netþjónsfangið.

Stýrðir þjónar bæta þriðja lagi ofan á resolver stýrikerfisins. Windows-VPN-snið getur borið eigin stefnu um nafnaupplausn, reglur fyrir hvert forrit og NRPT-töflu sem gildir jafnvel þegar göngin eru niðri. Forrit með eigin DNS-skyndiminni, algeng í .NET- og Java-umhverfum, halda gölluðu úttaki lengi eftir að keðjan er löguð. Apple-þjónar stilla split DNS með samsvörunardómenum í DNS-stillingunum í stað resolv.conf, og Chromium eða Firefox í secure-DNS-ham geta sneitt fram hjá resolver kerfisins fyrir opinber nöfn. Microsoft-tilvísunin um nafnaupplausn VPN lýsir Windows-hlið þess stefnulags.

Ákveddu hvaða lag á að laga

Vinnuðu frá einkenninu að laginu í stað þess að prófa lagfæringar í röð:

Tvær raðir bera mestu þyngdina. Tímarof er aðgengileikavandamál: einka-resolverinn svarar ekki í gegnum göngin, svo athugaðu leiðina að vistfanginu og hvort DNS-netþjónninn á tenglinum sé sá sem þú heldur. NXDOMAIN er valdavandamál: eitthvað svaraði og þekkir ekki nafnið, sem bendir á svæðið, landsvæðið eða resolver sem aldrei átti að fá fyrirspurnina.

Síðasta röðin er sú sem fólk missir af því báðir helmingar líta út eins og árangur. Stutt nafn sem leysist öðruvísi en FQDN er viðskeytamisræmi, og að endurtengja göngin breytir ekki því viðskeyti sem þjónninn sendir.

Skráðu stöðuna áður en þú breytir stillingaskrá, svo þú getir sagt hvort breytingin gerði eitthvað:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Keyrðu prófanirnar í þessari röð og stöðvaðu við þá fyrstu sem mistekst. getent og resolvectl query verða að stemma; ef getent mistekst á meðan dig svarar, vertu í uppflettikeðjunni og snertu ekki leiðakerfið. resolvectl status verður að sýna DNS-netþjón og leiðardómen á tun-snertingunni. nsswitch má ekki snúa aftur of snemma á NOTFOUND fyrir viðskeytið sem þú prófar. Nafnið verður að vera ráðandi í netinu sem endapunkturinn þinn er tengdur við, prófað með punkti í lokin. Forritið má ekki halda eigin skyndiminni eða secure-DNS-yfirskrift.

Lagaðu aðeins fyrsta lagið sem mistekst og keyrðu svo sömu skipanir aftur. Tvær breytingar í einu gera þér ókleift að segja hvor skipti máli, og næsta bilun byrjar rannsóknina frá núlli.