mDNS innan VPN: hvers vegna .local-nöfn leysast ekki

Prentarinn á skrifstofunni birtist í hverju forriti á skrifborðinu þínu og hverfur á VPN, þótt þú getir pingað vistfangið sem þú veist að hann hefur. Ekkert í göngunum er bilað: uppgötvun og aðgengi eru aðskildar þjónustur og aðeins önnur þeirra fer í gegnum beint göng að sjálfgefnu. Prófin hér að neðan aðskilja þær áður en þú byrjar að bæta við leiðum. Leið getur ekki lagað fyrirspurn sem fór aldrei frá tengingunni.

Athugaðu hvað leysist í dag og hvað virðist aðeins leyst

Aðskildu fyrst spurningarnar tvær: unicast-fyrirspurn um hýsingarheiti spyr leysi, en leit að _ipp._tcp spyr staðbundnu tenginguna. Á Linux sýnir avahi-browse -a hvað multicast DNS getur séð og resolvectl query name.local sýnir hvað leysisstakkurinn gerir við það heiti. Á macOS listar dns-sd -B _ipp._tcp uppgötvaðar þjónustur án þess að þurfa fyrst vistfang.

Ef vistfangið svarar og heitið ekki, virkar beining og uppgötvun ekki. Einnig er hægt að svara heiti .local á hýsingunni sjálfri í gegnum nss-mdns án þess að avahi-browse sé uppsett, svo árangursríkt getent eða ping á það heiti er ekki sönnun þess að uppgötvun hafi farið í gegnum göngin; leitarniðurstaðan og niðurstaða leysisins eru mismunandi sönnunargögn. Forrit setja í skyndiminni það sem þau uppgötvuðu, þess vegna kemur bilunin oft fram klukkustundum eftir tengingu en ekki við tengingu. Lokaðu og opnaðu forritið aftur og athugaðu þá hvort skyndiminnisfærslan inniheldur heiti eða vistfang, því vistfang virkar lengi eftir að uppgötvun stöðvaðist.

Hvers vegna fyrirspurnin fer aldrei í gegnum göngin

Multicast DNS sendir fyrirspurnir á 224.0.0.251, innan stýriblokks staðbundna netsins, á UDP-port 5353. Beinar senda ekki vistföng úr þeim blokk áfram, svo fyrirspurnin verður eftir á tengingunni sem hún var send á. Sendendur stilla einnig IP TTL, eða IPv6 hoppmörk, á 255 svo viðtakandi geti hafnað pakka sem þegar fór yfir beina; þannig greinir samskiptareglan fölsun utan tengingarinnar, ekki þannig verður hún staðbundin. Staðbundið eðli kemur frá áfangavistfanginu, ekki frá TTL einnar hopp.

Tegund ganganna skiptir líka máli. Viðmót af tun-stíl ber aðeins IP-pakka og ekkert annað, svo enginn multicast-hópur lifir það af. Brú af tap-stíl útvíkkar sjálft útsendingarsviðið, þess vegna brúaði sumar eldri hönnun í stað þess að beina, og erfði hvert það vandamál sem brúin færir.

Undantekning fyrir traustu LAN breytir engu af þessu, því hún ákveður hvaða umferð má nota göngin í stað þess að kenna göngunum að senda multicast áfram. Pakkinn hefur enn ekkert sameiginlegt svið til að heyrast á.

Veldu nafnahönnun sem þú getur staðið undir

Fyrir auðlindir fyrirtækisins er varanlega svarið beint hýsingarheiti sem leysirinn sem VPN-inn ýtir þjónar, með skiptu DNS svo innri heiti fari á innri netþjóna og allt annað ekki. Windows sýnir það sem stefnutöflu fyrir heitalausn, macOS notar takmörkuð leysa fyrir hvert viðmót og flestir biðlarar hafa samsvarandi ýtiparametra. Tækið heldur venjulegu heiti sínu í innra DNS og uppgötvun hættir að vera hluti leiðarinnar.

Uppgötvunarumboð eða mDNS-endurkastandi getur brúað þetta bil og það er raunveruleg hönnun með eigin hýsingu, eigin útsetningu og eigin kröfum biðlara. Það birtist ekki af því að þú bættir við leið. Sendu aldrei .local fyrirspurnir til opinbers leysis: lénið er frátekið fyrir staðbundna multicast-notkun af RFC 6762 og að senda það út veldur hægum bilunum og óþarfa upplýsingaleki.

Staðfestu þjónustuna, ekki heitið

Heiti í leitarlista sannar uppgötvunarskrefið, ekki að þjónustan svari. Opnaðu prentröðina eða vefviðmótið og ljúktu raunverulegri aðgerð, endurtaktu hana svo eftir endurtengingu.

Uppgötvun skyndiminnir heiti mjög, svo gömul færsla getur virst árangur. Ef skírteini eða auðkenningarbeiðni birtist er það næsta lag og sérstakt vandamál. Skrifaðu niður hvaða aðferð þú breyttir, leysi eða uppgötvun, svo næsta manneskja þurfi ekki að opna alla spurninguna aftur.