DNS í VPN virkar, en .local-nöfn mistakast samt: hver leysir þau?

Tvær vélar á sama VPN, sama hýsilanafn, og aðeins önnur þeirra leysir það: munurinn er venjulega ekki göngin heldur hvaða leysir svaraði. Á Linux-skjáborði getur það nafn farið í gegnum nafnþjónusturofann, í gegnum stub systemd-resolved eða í gegnum leysi sem forritið bar með sér, og hver þeirra beitir sinni eigin reglu á sama viðskeytið. Það er við viðskeytið sem reglurnar greinir, því .local er ekki hlutlaus merking. Finndu út hvaða slóð forritið sem mistekst fer í raun og veru áður en þú breytir röðinni sem eitthvað keyrir í.

Tveir leysar, tvö mismunandi svör

Hefðbundin glibc-uppfletting gengur eftir hosts: línunni í nsswitch.conf og spyr hverja einingu á fætur annarri þar til ein svarar. Biðlarinn sem talar við systemd-resolved í gegnum stub-hlustaran spyr í staðinn eitt ferli, og það ferli beitir stefnu fyrir hvert tengi auk sinna eigin sérstöku tilvika. Forrit sem kemur með sinn eigin leysi, eða tengir bókasafn sem gerir það, getur farið fram hjá báðum. Þannig getur eitt hýsilanafn haft þrjá eigendur á einni vél, og aðeins einn þeirra veit hvað VPN-ið ætlaði sér.

Greindu eigandann áður en þú breytir einhverju, því lagfæringin er mismunandi fyrir hvern þeirra þriggja. Vafri og skipanalínutæki á sama skjáborði geta löglega verið ósammála, og það ósamræmi er vísbendingin, ekki villan. Ef vafrinn leysir nafnið en tækið ekki, ertu að kemba leysislóð en ekki VPN-slóð. Staðfestu slóðina sérstaklega, svo að beiningavilla verði ekki rugluð saman við villu í nafnþjónustu. Þegar báðir eru sammála er villan ofar hýsilnum og leysisstillingin hér er ekki annarrar breytingar virði.

Hvaða skipun spurði leysinn þinn í raun

Tvær leseingar-skipanir svara skyldum spurningum, og að bera þær saman staðsetur vandann fljótar en að lesa stillingar. Notaðu raunverulegt innra nafn og haltu úttakinu einkalegu, því innri færslur eru áfram innri. Keyrðu báðar í sama lotu og forritið sem mistekst keyrir í:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Fyrri spyr í gegnum stilltu einingarnar, sem er það sem dæmigert forrit upplifir. Seinni spyr beint systemd-resolved og greinir frá tenginu, samskiptareglunni og netþjóninum sem svaraði. Að spyrja fyrirtækjanetþjóninn eftir vistfangi sannar aðeins að netþjónninn hafi færsluna, því það segir ekkert um hvort forritið hafi einhvern tíma spurt hann. Lestu tengið sem ber VPN-ið og lénin sem það segist eiga, og berðu síðan þann lista saman við viðskeytið í nafninu sem mistekst.

Hvers vegna .local fer fram hjá unicast-svæðinu þínu

tilvísun systemd-resolved segir að fjölmerkt nöfn sem enda á .local fari venjulega í multicast DNS þegar mDNS er virkt, frekar en í venjulegt unicast DNS. RFC 6762 tekur það nafnrými frá fyrir link-local multicast, svo fyrirtækjasvæði getur haft rétta færslu sem aldrei er spurt um fyrir það viðskeyti. Göngin geta beint leysinum fullkomlega og tapað samt keppninni. Ping sem tekst úr skyndiminni segir ekkert um uppflettinguna sem varð rétt í þessu.

Það er skjalfest undantekning, og hún leysir flest þessara tilvika: þegar tengi lýsir því viðskeyti sem leitarléni eða beiningaléni heldur djöfullinn því á unicast-slóðinni og sleppir sérstaka multicast-tilvikinu. Það er stefna fyrir hvert tengi en ekki alþjóðleg forgangsröðun. Tvær vélar með sama VPN-netþjón geta hagað sér mismunandi þegar eitt netkerfissnið lýsir léninu en hitt ekki, svo lestu virka sniðið en ekki það sem þú manst að hafa breytt.

Þrönga undantekningin vinnur á alþjóðlegri endurröðun

Fyrir núverandi svæði sem þú getur ekki endurnefnt skaltu láta eigendur leysisins og VPN-sins lýsa léninu á tengingunni sem ber það. Beiningalénsfærsla fyrir þetta eina viðskeyti auk fyrirhugaðs netþjónsvistfangs er lítil breyting með nafngreindum eiganda, og hún býr með tenginu frekar en í handbreyttri skrá.

Hún lifir einnig af aftengingu, því stefna tengisins er beitt aftur þegar tengið kemur til baka. Að breyta sameiginlega nsswitch.conf er freistandi og dýrari valkosturinn, því það breytir uppflettingarhegðun fyrir hvert nafn á vélinni, þar á meðal staðbundna uppgötvun. Að slökkva á multicast-djöflinum er ekki heldur jafngilt: það fjarlægir staðbundna hegðun án þess að kenna nokkrum leysi fyrirtækjasvæðið. Ef þjónustan er ný en ekki erfð, settu hana undir undirlén sem stofnunin þín stýrir og slepptu samkeppninni algjörlega. Veldu þröngu undantekninguna þegar nafnið er fest í fastbúnaði eða prentað á merkimiða, og veldu nýtt undirlén þegar þú stýrir biðlinum enn.

Hvað á að sanna eftir breytinguna

Sannaðu lagfæringuna með eigin uppflettingu forritsins frekar en tæki sem þú settir upp til að prófa, og hreinsaðu hvaða skyndiminni sem gæti svarað í þess stað. Staðfestu síðan leysislóðina og tengið sem veitti svarið. Athugaðu að lokum að staðbundin uppgötvun hagi sér eins og fyrir breytinguna, því prentarinn sem hættir að birtast er sá hluti sem fólk tekur síðast eftir. Þessar þrjár skipanir athuga nafnið, slóðina og TLS-auðkenninna í þeirri röð:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Rétt vistfang með röngu skírteini lætur strangan biðlara samt mistakast, svo athugaðu nafnið sem forritið væntir þegar leysingin virkar. Staðfestu að þjónustan samþykki tengingar frá VPN-vistfanginu en ekki aðeins úr skrifstofubilinu. Skrifaðu umfang lénsins, netþjóninn og eigandann í skjöl tengingarinnar. Annars grípur næsta manneskja sem lendir í þessari bilun í sömu alþjóðlegu breytinguna sem þú varst að forðast.