mDNS VPN-i sees: miks .local-nimed ei lahene

Teie kontori printer ilmub igasse rakendusse teie töölaual ja kaob VPN-is, kuigi saate pingida aadressi, mis teil teada on tal olemas. Tunnelis pole miski katki: avastamine ja kättesaadavus on eraldi teenused ning vaikimisi ületab marsruuditud tunnelit ainult üks neist. Allolevad kontrollid eraldavad need enne, kui hakkate marsruute lisama. Marsruut ei saa parandada päringut, mis kunagi lingilt ei lahkunud.

Kontrollige, mis täna laheneb ja mis ainult tundub lahenevat

Eraldage esmalt kaks küsimust: hostinime unicast-päring küsib resolverilt, samas kui _ipp._tcp otsing küsib kohalikult lingilt. Linuxis näitab avahi-browse -a, mida multicast-DNS näha suudab, ja resolvectl query name.local näitab, mida resolveri pinu selle nimega teeb. macOS-is loetleb dns-sd -B _ipp._tcp avastatud teenused ilma, et oleks esmalt aadressi vaja.

Kui aadress vastab ja nimi mitte, töötab marsruutimine ja avastamine ei tööta. Nimele .local saab vastata ka hosti enda peal nss-mdns kaudu ilma avahi-browse'i paigaldamata, seega edukas getent või ping sellele nimele ei ole tõestus, et avastamine tunnelit ületas; otsingutulemus ja resolveri tulemus on erinevad tõendid. Rakendused cache'ivad seda, mida nad avastasid, mistõttu ilmub tõrge sageli tunde pärast ühendamist, mitte ühendamise hetkel. Sulgege ja avage rakendus uuesti, seejärel kontrollige, kas cache'itud kirje sisaldab nime või aadressi, sest aadress töötab kaua pärast seda, kui avastamine lakkas.

Miks päring kunagi tunnelit ei ületa

Multicast DNS saadab päringud aadressile 224.0.0.251, kohaliku võrgu juhtploki sees, UDP-pordile 5353. Marsruuterid ei edasta selle ploki aadresse, seega jääb päring linki, kuhu see saadeti. Saatjad seavad ka IP TTL-i ehk IPv6 hüppepiiri väärtusele 255, et vastuvõtja saaks tagasi lükata paketi, mis on juba marsruuterit ületanud; nii tuvastab protokoll lingivälise võltsimise, mitte nii ei jää see kohalikuks. Kohalikkus tuleb sihtaadressist, mitte ühe hüppe TTL-ist.

Ka tunnelitüüp loeb. tun-stiilis liides kannab IP-pakette ja mitte midagi muud, seega ei jää ükski multicast-grupp sellest ellu. tap-stiilis sild laiendab leviedastusdomeeni ennast, mistõttu mõned vanad kujundused sillutasid marsruutimise asemel ja pärisid kõik probleemid, mida sild toob.

Usaldusväärse LAN-i erand ei muuda sellest midagi, sest see otsustab, milline liiklus tohib tunnelit kasutada, mitte ei õpeta tunnelit multicast'i edastama. Paketil pole endiselt ühist segmenti, mille peal seda kuulda.

Valige nimekujundus, mida suudate toetada

Ettevõtte ressursside jaoks on kestev vastus marsruuditud hostinimi, mida teenindab resolver, mille VPN läbi surub, koos jagatud DNS-iga, et sisemised nimed läheksid sisemistele serveritele ja kõik muu mitte. Windows esitab seda nimeresolutsiooni poliitika tabelina, macOS kasutab liidesepõhiseid piiratud resolvereid ja enamikul klientidel on samaväärne läbisurumise seade. Seade hoiab oma tavalist nime sisemises DNS-is ja avastamine lakkab olemast tee osa.

Avastamisproksi või mDNS-reflektor võib selle lõhe sillata ja see on tõeline kujundus oma hosti, oma kokkupuute ja oma kliendinõuetega. See ei ilmu seetõttu, et lisasite marsruudi. Ärge kunagi edastage .local päringuid avalikku resolverisse: domeen on RFC 6762 järgi reserveeritud kohalikuks multicast-kasutuseks ja selle väljapoole saatmine tekitab aeglaseid tõrkeid ja asjatut andmete avalikustamist.

Kontrollige teenust, mitte nime

Nimi otsinguloendis tõestab avastamise sammu, mitte seda, et teenus vastab. Avage prindijärjekord või veebiliides ja sooritage tõeline toiming, seejärel korrake seda pärast uuesti ühendamist.

Avastamine cache'ib nimesid agressiivselt, seega vananenud kirje võib tunduda õnnestumisena. Kui ilmub sertifikaat või autentimisküsimus, on see järgmine kiht ja eraldi probleem. Kirjutage üles, millist mehhanismi muutsite, resolverit või avastamist, et järgmine inimene ei peaks kogu küsimust uuesti avama.