mDNS binne ’n VPN: waarom .local-name nie oplos nie

Jou kantoor se drukker verskyn in elke toepassing by jou lessenaar en verdwyn op die VPN, selfs al kan jy die adres ping wat jy weet hy het. Niks in die tonnel is stukkend nie: ontdekking en bereikbaarheid is aparte dienste, en net een van hulle steek by verstek ’n geroteerde tonnel oor. Die kontroles hieronder skei hulle voordat jy begin roetes byvoeg. ’n Roete kan nie ’n navraag regmaak wat nooit die skakel verlaat het nie.

Kontroleer wat vandag oplos, en wat net opgelos lyk

Skei eers die twee vrae: ’n unicast-navraag vir ’n gasheernaam vra ’n resolver, terwyl ’n soektog na _ipp._tcp die plaaslike skakel vra. Op Linux wys avahi-browse -a wat multicast-DNS kan sien, en resolvectl query name.local wys wat die resolver-stapel met daardie naam doen. Op macOS lys dns-sd -B _ipp._tcp ontdekte dienste sonder om eers ’n adres te nodig te hê.

As die adres antwoord en die naam nie, werk roetering en werk ontdekking nie. ’n .local-naam kan ook op die gasheer self deur nss-mdns beantwoord word sonder dat avahi-browse geïnstalleer is, so ’n suksesvolle getent of ping na daardie naam is nie bewys dat ontdekking die tonnel oorgesteek het nie; die soekresultaat en die resolver-resultaat is verskillende stukke bewyse. Toepassings kas wat hulle ontdek het, en daarom verskyn die fout dikwels ure ná verbinding eerder as by verbinding. Sluit die toepassing en maak dit weer oop, kyk dan of die gekaste inskrywing ’n naam of ’n adres bevat, want ’n adres werk lank nadat ontdekking opgehou het.

Waarom die navraag nooit die tonnel oorsteek nie

Multicast-DNS stuur navrae na 224.0.0.251, binne die plaaslike netwerkbeheerblok, op UDP-poort 5353. Roeters stuur nie adresse uit daardie blok aan nie, so die navraag bly op die skakel waarna dit gestuur is. Versenders stel ook die IP-TTL, of die IPv6-hoplimiet, op 255 sodat ’n ontvanger ’n pakket kan verwerp wat reeds ’n roeter gekruis het, en dit is hoe die protokol buite-skakel-spoofing opspoor eerder as hoe dit plaaslik bly. Lokaliteit kom van die bestemmingsadres, nie van ’n TTL van een hop nie.

Die tonneltipe maak ook saak. ’n tun-styl koppelvlak dra IP-pakkette en niks anders nie, so geen multicast-groep oorleef dit nie. ’n tap-styl brug brei die uitsaaidomein self uit, en daarom het sommige erfenisontwerpe eerder gebrug as geroteer, en elke probleem wat brugging bring, geërf.

’n Uitsondering vir vertroude LAN verander niks hiervan nie, want dit bepaal watter verkeer die tonnel mag gebruik eerder as om die tonnel te leer om multicast aan te stuur. Die pakket het steeds geen gedeelde segment om op gehoor te word nie.

Kies ’n naamontwerp wat jy kan ondersteun

Vir maatskappybronne is die duursame antwoord ’n geroteerde gasheernaam wat deur die resolver bedien word wat die VPN stoot, met split DNS sodat interne name na interne bedieners gaan en alles anders nie. Windows bied dit as ’n naamresolusie-beleidstabel, macOS gebruik begrensde resolvers per koppelvlak, en die meeste kliënte het ’n ekwivalente stootinstelling. Die toestel hou sy normale naam in interne DNS, en ontdekking hou op om deel van die pad te wees.

’n Ontdekkingsproxy of ’n mDNS-reflector kan die gaping oorbrug, en dit is ’n werklike ontwerp met sy eie gasheer, sy eie blootstelling en sy eie kliëntvereistes. Dit verskyn nie omdat jy ’n roete bygevoeg het nie. Moet nooit .local-navrae na ’n openbare resolver aanstuur nie: die domein is vir plaaslike multicast-gebruik gereserveer deur RFC 6762, en om dit uitwaarts te stuur lewer stadige mislukkings en onnodige data-openbaarmaking.

Verifieer die diens, nie die naam nie

’n Naam in ’n soeklys bewys die ontdekkingsstap, nie dat die diens antwoord nie. Maak die drukwerkwaglys of die webkoppelvlak oop en voltooi ’n werklike bewerking, en herhaal dit ná ’n herverbinding.

Ontdekking kas name aggressief, so ’n verouderde inskrywing kan soos sukses lyk. As ’n sertifikaat- of outentiseringsaansporing verskyn, is dit die volgende laag en ’n aparte probleem. Skryf neer watter meganisme jy verander het, resolver of ontdekking, sodat die volgende persoon nie die hele vraag weer moet oopmaak nie.