Hvers vegna einkanleg DNS-nöfn mistakast á VPN-biðlurum og hvar á að athuga

Þú opnar fartölvu á hótelherbergi, ræsir biðlarann, skrifar nafn innri skráaþjónsins og fær ekkert til baka. Göngin segja tengt, og ping á vistfang í sama undirneti svarar enn, svo flutningurinn sjálfur er í lagi. Aðeins nafnið mistekst, og það bil þrengir vandamálið að tveimur stöðum: hvaða uppgjafara biðlarinn spurði og hvort svarið sem hann fékk komist til baka um göngin. Lagaðu annað og slepptu hinu, og bilunin færist einfaldlega til.

Áður en þú breytir einhverju prófíli skaltu staðfesta hvað biðlarinn gerir við nafnið. Á Linux sýnir resolvectl query files.corp.example hvaða tengingu og hvaða uppgjafari framleiddu svarið. Á Windows sýnir Resolve-DnsName files.corp.example þjóninn sem svaraði og vistfangið sem hann skilaði.

Lestu svarið áður en þú breytir einhverju

Ef nafnið kemur til baka sem NXDOMAIN á nokkrum millisekúndum náði fyrirspurnin aldrei til svæðisins þíns og einhver opinber eða hóteluppgjafari svaraði í staðinn. Ef það kemur til baka eftir langa hlé er eitthvað að sleppa UDP-porti 53 á leiðinni og biðlarinn féll að lokum til baka. Ef það svarar með réttu vistfangi en tengingin stendur samt kyrr er uppflettingin í lagi og vandamálið þitt er í leiðsögn eða þjónustunni sjálfri.

Sú þrískipting sparar klukkustund af ágiskunum. Hún segir þér líka hvort þú eigir að snerta VPN-ið yfirleitt: nafn sem leysist í rétt einkanlegt vistfang hefur þegar sannað leið uppgjafarans, svo vinnan sem eftir er liggur á gagnaleiðinni.

Úthlutaðu uppgjafaranum innan frá göngunum

Biðlarar falla í tvo hópa. Öðrum getur þjónninn bent á uppgjafara við uppsetningu tengingarinnar; hinn heldur stillingunni í staðbundinni skrá sem engin gátt getur breytt úr fjarlægð.

OpenVPN er í fyrri hópnum. Á þjóninum fara push "dhcp-option DNS 10.8.0.53" og push "dhcp-option DOMAIN corp.example" niður stýrisrásina, en aðeins ef stilling biðlarans hefur pull enn virkt. Handbreyttur biðlari með pull-filter ignore "dhcp-option" sér þau aldrei, og sú eina lína skýrir ótrúlega mörg tilfelli þar sem þjónninn ýtir þessu en fartölvan mín er ósammála.

WireGuard er í seinni hópnum, því samskiptareglurnar hafa engar valkostaviðræður yfirleitt. Uppgjafarinn og leitarlénin fara í eigið [Interface] blokk biðlarans sem DNS = 10.8.0.53, corp.example. wg-quick beitir því gegnum resolvconf eða systemd-resolved, og á Windows setur opinberi biðlarinn upp NRPT-reglur sem eru aðeins til á meðan göngin standa: Get-DnsClientNrptPolicy telur þær upp, sem gerir það að fljótlegri leið til að sjá hvort biðlarinn beitti skránni þinni einhvern tíma.

IPsec/IKEv2 stendur á milli. attr-viðbót strongSwan getur skilað DNS-þjóni úr laug, og Windows-biðlari samþykkir það venjulega, en prófíll sem festir sinn eigin nafnaþjón vinnur gegn hverju því sem gáttin býður. Á Linux-biðlara er samsvarandi handvirk skref resolvectl dns wg0 10.8.0.53 og síðan resolvectl domain wg0 '~corp.example'; bæði hverfa með tenginu, sem er einmitt það sem þú vilt fyrir stillingu sem er bundin göngunum.

Afmarkaðu viðskeytið í stað þess að gleypa hverja fyrirspurn

Að beina öllum uppgjafaralista biðlarans að innri þjóninum þínum er auðvelt og yfirleitt rangt. Þá leysist hvert opinbert nafn upp frá útgangi gagnamiðstöðvarinnar þinnar, CDN skila fjarlægum vistföngum, og ein uppgjafarbilun dregur vafur notandans með sér.

Sendu aðeins einkaviðskeytið inn. Á systemd-resolved er lén sem byrjar á ~ aðeins fyrir leiðsögn, svo ~corp.example þýðir að fyrirspurnir undir því viðskeyti fara til þjóna þeirrar tengingar á meðan allt annað heldur áfram að nota eðlislegt netið. Windows gerir það sama með NRPT-reglum sem eru afmarkaðar við nafnrými, og macOS með viðbótarskrá uppgjafarans undir /etc/resolver/.

Fjölvarpsnöfn eiga skilið eigið svar. .local nöfn eru link-local að hönnun (RFC 6762) og punkt-í-punkt tun-tengi ber ekki þann fjölvarpshóp, svo að bæta við opinberum uppgjafara birtir þau ekki og að spyrja innri einvarpsuppgjafara um þau skilar NXDOMAIN. Endurkastari eins og avahi í endurkastarham getur brúað tvo hluta, en það er ákvörðun á þjónahlið sem enginn biðlari getur krafist. Ef prentari eða NAS verður að vera aðgengilegt eftir nafni skaltu gefa því A-færslu í svæðinu þínu í staðinn.

Sannaðu að svarið komist til baka

Rétt svar sem bendir á óaðgengilegt vistfang lítur nákvæmlega út eins og uppgjafaravandamál þar til þú athugar leiðina. Spurðu kjarnann hvert svarið myndi fara: ip route get 10.20.5.20 nefnir tengið og, gagnlegra, upprunavistfangið sem það myndi nota.

Fylgstu með uppgjafaravistfanginu sjálfu. Biðlari með DNS = 10.8.0.53 við hlið AllowedIPs = 10.20.0.0/16 sendir fyrirspurnir sínar út um eðlislega netkortið, þar sem þær deyja hljóðlega, því uppgjafarinn er ekki innan neins forskeytis sem göngin gera tilkall til. Þetta misræmi er algengasta einnar orsakar bilunin á öllu þessu sviði, og það er ósýnilegt nema þú berir DNS-stillinguna saman við leyfðu forskeytin línu fyrir línu.

Skörun sviða veldur gagnstæðri bilun. Svarið er rétt, leiðin er til og hún bendir á rangan hýsil, því 192.168.0.0/24 heima er nákvæmara en leið ganganna að sama sviði. Endurnúmeraðu aðra hliðina eða ýttu fram mjórri leið, og staðfestu síðan eldvegg og bakleið þjónshýsilsins; athugasemdir strongSwan um endursendingu ná yfir sysctl-hlið þeirrar leiðar.

Skírteini eru sérstök auðkenningarkönnun sem fólk kennir DNS um. Ef vafrinn tilkynnir nafnamisræmi í stað uppflettingarvillu hefur uppflettingin þegar virkað og það er SAN í skírteininu sem þarf að laga. Prófaðu HTTPS á nafnið, aldrei á bert IP.

Prófaðu aftur frá biðlaranum, ekki frá gáttinni

Prófaðu inni í forritinu sem notandinn kvartar undan, því uppfletting á skipanalínu sannar ekki að vafrinn fari sömu leið. Öruggt DNS Chrome og network.trr.mode Firefox geta farið algjörlega fram hjá kerfisuppgjafaranum, og þegar þau gera það mistekst einkanlegt nafn eða lekur til opinbers uppgjafara. Að bera saman resolvectl query við handvirkt dig @10.8.0.53 files.corp.example segir þér hvor tveggja gerðist.

Aftengdu síðan og tengdu aftur áður en þú kallar það lagað. Stillingar sem settar eru handvirkt á tengi hverfa með tenginu, og prófíll sem leit rétt út eingöngu vegna gleymdrar staðbundinnar breytingar mun mistakast við næstu ræsingu.

Stuttur gátlisti fyrir næstu vél: nafnið leysist upp gegnum uppgjafara ganganna, viðskeytið er afmarkað í stað alþjóðlegt, uppgjafaravistfangið er innan leyfðu forskeytanna, hýsillinn úr svarinu svarar á þjónustuporinu og skírteinið nær yfir nafnið sem notandinn skrifaði.