mDNS VPN:n sisällä: miksi .local-nimet eivät ratkea

Toimiston tulostin ilmestyy kaikkiin työpöytäsi sovelluksiin ja katoaa VPN:ssä, vaikka voit pingata osoitetta, jonka tiedät sillä olevan. Tunnelissa ei ole mitään rikki: löytäminen ja tavoitettavuus ovat eri palveluita, ja oletuksena vain toinen niistä ylittää reititetyn tunnelin. Alla olevat tarkistukset erottavat ne ennen kuin alat lisätä reittejä. Reitti ei voi korjata kyselyä, joka ei koskaan lähtenyt linkiltä.

Tarkista, mikä ratkeaa tänään ja mikä vain näyttää ratkenneelta

Erottele ensin kaksi kysymystä: isäntänimen unicast-kysely kysyy resolverilta, kun taas _ipp._tcp-haku kysyy paikalliselta linkiltä. Linuxissa avahi-browse -a näyttää, mitä multicast DNS voi nähdä, ja resolvectl query name.local näyttää, mitä resolveripino tekee sillä nimellä. macOS:ssä dns-sd -B _ipp._tcp luettelee löydetyt palvelut ilman, että osoitetta tarvitaan ensin.

Jos osoite vastaa ja nimi ei, reititys toimii ja löytäminen ei. Nimelle .local voidaan vastata myös itse isännällä nss-mdns:n kautta ilman asennettua avahi-browse'ta, joten onnistunut getent tai ping siihen nimeen ei ole todiste siitä, että löytäminen ylitti tunnelin; hakutulos ja resolverin tulos ovat eri todisteita. Sovellukset välimuistittavat sen, mitä ne löysivät, minkä vuoksi vika ilmestyy usein tunteja yhteyden muodostamisen jälkeen eikä yhteyden muodostuksen hetkellä. Sulje ja avaa sovellus uudelleen ja tarkista sitten, sisältääkö välimuistissa oleva merkintä nimen vai osoitteen, sillä osoite toimii vielä kauan sen jälkeen, kun löytäminen lakkasi.

Miksi kysely ei koskaan ylitä tunnelia

Multicast DNS lähettää kyselyt osoitteeseen 224.0.0.251, paikallisverkon ohjauslohkon sisällä, UDP-porttiin 5353. Reitittimet eivät välitä kyseisen lohkon osoitteita, joten kysely jää linkille, jolle se lähetettiin. Lähettäjät asettavat myös IP TTL:n tai IPv6:n hyppyluokan arvoon 255, jotta vastaanottaja voi hylätä paketin, joka on jo ylittänyt reitittimen; näin protokolla havaitsee linkin ulkopuolisen väärennöksen, ei näin se pysyy paikallisena. Paikallisuus tulee kohdeosoitteesta, ei yhden hypyn TTL:stä.

Tunnelityyppikin merkitsee. tun-tyylinen liitäntä kuljettaa IP-paketteja eikä mitään muuta, joten mikään multicast-ryhmä ei selviä sen läpi. tap-tyylinen silta laajentaa itse lähetysaluetta, minkä vuoksi jotkin vanhat ratkaisut siltoivat reitittämisen sijaan ja perivät kaikki ongelmat, joita silta tuo.

Luotetun lähiverkon poikkeus ei muuta tästä mitään, koska se päättää, mikä liikenne saa käyttää tunnelia, sen sijaan että opettaisi tunnelin välittämään multicastia. Paketilla ei edelleenkään ole yhteistä segmenttiä, jolla se kuultaisiin.

Valitse nimeämisratkaisu, jota voit ylläpitää

Yrityksen resursseille kestävä vastaus on reititetty isäntänimi, jota palvelee resolveri, jonka VPN työntää, yhdessä jaetun DNS:n kanssa, jotta sisäiset nimet menevät sisäisille palvelimille eikä kaikki muu. Windows esittää sen nimien ratkaisun käytäntötauluna, macOS käyttää rajattuja resolvereita liitäntäkohtaisesti ja useimmilla asiakkailla on vastaava työntöasetus. Laite säilyttää tavallisen nimensä sisäisessä DNS:ssä, ja löytäminen lakkaa olemasta osa polkua.

Löytämisvälityspalvelin tai mDNS-heijastin voi sillata tämän kuilun, ja se on todellinen ratkaisu, jolla on oma isäntänsä, oma altistuksensa ja omat asiakasvaatimuksensa. Se ei ilmesty siksi, että lisäsit reitin. Älä koskaan välitä .local-kyselyitä julkiselle resolverille: toimialue on varattu paikalliseen multicast-käyttöön RFC 6762:n mukaan, ja sen lähettäminen ulospäin tuottaa hitaita vikoja ja tarpeetonta tiedon paljastumista.

Tarkista palvelu, älä nimeä

Nimi hakuluettelossa todistaa löytämisvaiheen, ei sitä, että palvelu vastaa. Avaa tulostusjono tai verkkokäyttöliittymä ja tee todellinen toimenpide, ja toista se uudelleenyhdistämisen jälkeen.

Löytäminen välimuistittaa nimiä aggressiivisesti, joten vanhentunut merkintä voi näyttää onnistumiselta. Jos esiin tulee varmenne tai todennuspyyntö, se on seuraava kerros ja erillinen ongelma. Kirjoita muistiin, mitä mekanismia muutit, resolveria vai löytämistä, jotta seuraavan henkilön ei tarvitse avata koko kysymystä uudelleen.