Hvers vegna /etc/hosts-færslan þín nær ekki DNS VPN-sins
Að tengjast VPN hleður ekki /etc/hosts upp. Aðskildu uppflettingu kerfisins frá beinni DNS-fyrirspurn og birtu síðan einkaaðila nöfn í gegnum stýrða svæði.
Þú bættir nafni við /etc/hosts, tengdist VPN og bjóst við að færslan myndi birtast öllum. Það gerist ekki, og óvart kemur venjulega með annarri einkunn: nafnið leysist á þinni vél og mistekst hjá samstarfsmanni, sem lítur út eins og biluð VPN DNS-þjónusta og er í raun hosts-skráin að gera nákvæmlega það sem hún var hönnuð fyrir. Hosts-skrá er staðbundin stilling nafnaupplausnar, ekki svæðisuppfærsla, og ekkert í venjulegri VPN-tengingu hleður henni upp.
Hosts er staðbundin yfirskrift, ekki svæðisuppfærsla
Skráin er listi yfir varpanir sem nafnþjónustusöfn ráðfæra sig við áður en þau spyrja DNS-þjón eða í staðinn fyrir það. Lína eins og 10.40.0.20 build.corp.example breytir því sem forrit á þeirri einu vél komast að. Hún býr ekki til færslu, hún fer ekki gegnum göngin, og DNS-þjónninn sem göngin benda á hefur ekki hugmynd um að hún sé til.
Þess vegna er mistakið ósamhverft. Biðlarinn þinn fær svar úr skránni. Annar biðlari spyr DNS-þjón VPN-sins, sem skilar engu, og forritið tilkynnir að nafnið sé ekki til. Báðar vélar hegða sér rétt; aðeins önnur þeirra hefur yfirskrift sem hin hefur aldrei séð.
Tvær skipanir, tveir mismunandi hlutar
Skjótasta leiðin til að stöðva rifrildið er að gera muninn sýnilegan í tveimur skipunum, báðum keyrðum á biðlinum sem hefur hosts-færsluna:
getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A
Fyrri spyr eigin uppflettileið kerfisins, sem á dæmigerðu glibc-kerfi les staðbundnar skrár fyrir DNS. Seinni sendir DNS-fyrirspurn beint til þjónsins á því vistfangi og ráðfærir sig alls ekki við staðbundnar skrár. Þegar fyrri skilar færslunni þinni og seinni skilar NXDOMAIN, hefur þú sannað að færslan er ekki til í DNS og að vélin þín svarar úr staðbundinni yfirskrift.
Röðin er stillanleg, og það er þess virði að athuga hana áður en þú ályktar nokkuð um tiltekna dreifingu. Horfðu á hosts: línuna í /etc/nsswitch.conf; hosts: files dns ráðfærir sig fyrst við skrár. Ekki afrita það dæmi yfir vinnandi stillingu bara til að breyta röðinni, því raunveruleg kerfi telja oft upp viðbótargjafir og skilyrtar þjónustufærslur sem dæmið hefur ekki.
systemd-resolved gerir prófið óskýrt
Á kerfi sem notar systemd-resolved þjónar staðbundni stubburinn einnig nöfnum úr hosts-gagnagrunninum. Þess vegna er fyrirspurn til 127.0.0.53 ekki óháð próf á fjartengda þjóninum, þótt hún líti út eins og DNS-fyrirspurn og hegði sér þannig. Þú getur staðfest hvað leysirinn veit og hvaða þjóna hann myndi spyrja með:
resolvectl query build.corp.example
resolvectl status
Status-úttakið nefnir DNS-þjónana fyrir hverja tengingu, og þannig kemst þú að því hvort VPN-tengingin fékk yfirhöfuð leysi. Sú spurning er aðskilin frá hosts-færslunni og er sú sem er þess virði að spyrja þegar einkaaðila nafn mistekst hjá hverjum notanda en ekki einum.
Forrit geta bætt við enn einu lagi. Vafri með eigin DNS-over-HTTPS stillingu, gámur með eigin stillingu leysisins eða keyrsluumhverfi sem skyggir uppflettingar í minni alla líftíma ferlisins geta hvert um sig svarað öðruvísi en kerfið. Prófaðu forritið sem þér er annt um í stað þess að gera ráð fyrir að ein skipun lýsi hverju forriti á vélinni.
Hvað deilir í raun nafni yfir VPN-ið
Ef einkaaðila nafn á að virka fyrir alla þarf það eiganda sem leysir allra getur náð til. Hreina svarið er að birta færsluna í stýrðu svæði og gera það svæði leysanlegt í gegnum fyrirhugaða DNS-leið VPN-sins. Þá hefur færslan eina sannleiksheimild, endurskoðunarslóð og lífsferil, og enginn þarf að muna hvaða fartölva ber staðbundna yfirskrift.
Að dreifa hosts-skrám er lögmætur valkostur, og það er endapunktastjórnun frekar en nafnþjónusta. Ef þú velur það verður skráin að vera sett upp, útgáfustýrð og fjarlægð af því sem stjórnar flotanum, og það á að lýsa því þannig í hönnuninni. „VPN-ið sér um það“ er ekki lýsing á því ferli.
Kvöldun DNS-skráningar er þriðja aðferðin, með eigin heimildum, auðkenningu uppfærslna og líftíma færslu. Hún leiðir ekki af hosts-færslu, og hún leiðir ekki heldur af því að biðlari tengist einfaldlega, nema þjónninn og biðlarinn hafi báðir verið stilltir til þess. Færsla sem birtist af sjálfu sér er merki um að einhver hafi virkjað öruggar uppfærslur og biðlari sem skráir sig sjálfur, og sú stilling á heima í hönnunarskjalinu frekar en í villuleitarlotu. Ef enginn getur nefnt hver á þá stillingu, meðhöndlaðu sjálfvirku færsluna sem óstaðfesta og haltu stýrða svæðinu sem sannleiksheimild.
Leyst nafn er ekki leið
Nafnaupplausn og aðgengi eru aðskilin, og úrelt staðbundin varpan er klassíska leiðin til að rugla þeim saman. Hosts-færsla sem bendir á vistfang sem hefur flutt mun halda áfram að velja úrelta hýsilinn löngu eftir að DNS var leiðrétt, og einkennin líta út eins og leiðarvilla á nafni sem leysist vel.
Þannig að þegar skýrslan er „nafnið leysist en ekki er hægt að ná þjónustunni“, berðu saman uppflettingu kerfisins og skýra fyrirspurn til DNS-þjóns VPN-sins, og athugaðu síðan vistfangið sem þú fékkst á móti því sem þjónustan notar í raun. systemd-resolved tilvísunin skjalfestir staðbundnu gjafirnar sem hann ráðfærir sig við, og það er kortið sem þú þarft fyrir þann samanburð.
Lagaðu síðan yfirskriftina í gegnum eiganda hennar. Að fjarlægja línu úr þinni eigin hosts-skrá gerir ekkert fyrir þær tólf fartölvur sem fengu sömu línu úr uppsetningarskripti, og það er útgáfan af þessu vandamáli sem fólk á í raun og veru.