mDNS in een VPN: waarom .local-namen niet worden opgelost

De printer van uw kantoor verschijnt in elke applicatie op uw bureau en verdwijnt op de VPN, ook al kunt u het adres pingen waarvan u weet dat hij het heeft. Niets in de tunnel is kapot: ontdekking en bereikbaarheid zijn aparte diensten, en standaard steekt slechts één ervan een gerouteerde tunnel over. De controles hieronder scheiden ze voordat u routes gaat toevoegen. Een route kan een query die het link nooit heeft verlaten niet repareren.

Controleer wat vandaag wordt opgelost, en wat alleen opgelost lijkt

Scheid eerst de twee vragen: een unicast-query voor een hostnaam vraagt een resolver, terwijl een zoektocht naar _ipp._tcp het lokale link vraagt. Op Linux laat avahi-browse -a zien wat multicast-DNS kan zien, en resolvectl query name.local laat zien wat de resolver-stack met die naam doet. Op macOS somt dns-sd -B _ipp._tcp ontdekte diensten op zonder eerst een adres nodig te hebben.

Als het adres antwoordt en de naam niet, werkt routing en werkt ontdekking niet. Een .local-naam kan ook op de host zelf via nss-mdns worden beantwoord zonder dat avahi-browse is geïnstalleerd, dus een geslaagde getent of ping naar die naam is geen bewijs dat ontdekking de tunnel overstak; het zoekresultaat en het resolverresultaat zijn verschillende bewijzen. Applicaties cachen wat ze hebben ontdekt, waardoor de fout vaak uren na het verbinden verschijnt en niet bij het verbinden. Sluit en heropen de applicatie en controleer dan of de gecachte vermelding een naam of een adres bevat, want een adres blijft lang werken nadat ontdekking is gestopt.

Waarom de query de tunnel nooit oversteekt

Multicast-DNS stuurt queries naar 224.0.0.251, binnen het besturingsblok voor het lokale netwerk, op UDP-poort 5353. Routers sturen adressen uit dat blok niet door, dus de query blijft op de link waarnaar hij is verzonden. Afzenders zetten ook de IP-TTL, of de IPv6-hoplimiet, op 255 zodat een ontvanger een pakket kan weigeren dat al een router heeft gepasseerd; zo detecteert het protocol spoofing buiten de link, niet zo blijft het lokaal. Lokaliteit komt van het bestemmingsadres, niet van een TTL van één hop.

Het tunneltype is ook belangrijk. Een interface in tun-stijl draagt IP-pakketten en niets anders, dus geen enkele multicast-groep overleeft die. Een brug in tap-stijl breidt het broadcast-domein zelf uit, waardoor sommige oude ontwerpen bruggen in plaats van routeren en alle problemen die een brug meebrengt erfden.

Een uitzondering voor een vertrouwd LAN verandert hier niets aan, omdat die bepaalt welk verkeer de tunnel mag gebruiken in plaats van de tunnel te leren multicast door te sturen. Het pakket heeft nog steeds geen gedeeld segment om op gehoord te worden.

Kies een naamontwerp dat u kunt onderhouden

Voor bedrijfsbronnen is het duurzame antwoord een gerouteerde hostnaam die wordt bediend door de resolver die de VPN pusht, met gesplitste DNS zodat interne namen naar interne servers gaan en al het andere niet. Windows biedt dat als een tabel voor naamresolutiebeleid, macOS gebruikt beperkte resolvers per interface, en de meeste clients hebben een gelijkwaardige push-instelling. Het apparaat behoudt zijn normale naam in interne DNS, en ontdekking houdt op deel van het pad te zijn.

Een ontdekkingsproxy of een mDNS-reflector kan de kloof overbruggen, en dat is een echt ontwerp met zijn eigen host, zijn eigen blootstelling en zijn eigen cliëntvereisten. Het verschijnt niet omdat u een route hebt toegevoegd. Stuur nooit .local-queries naar een publieke resolver: het domein is door RFC 6762 gereserveerd voor lokaal multicast-gebruik, en het naar buiten sturen levert trage fouten en onnodige gegevensopenbaarmaking op.

Verifieer de dienst, niet de naam

Een naam in een zoeklijst bewijst de ontdekkingsstap, niet dat de dienst antwoordt. Open de afdrukwachtrij of de webinterface en voltooi een echte bewerking, en herhaal die na een herverbinding.

Ontdekking cachet namen agressief, dus een verouderde vermelding kan op succes lijken. Als er een certificaat of een authenticatievraag verschijnt, is dat de volgende laag en een apart probleem. Noteer welk mechanisme u hebt gewijzigd, resolver of ontdekking, zodat de volgende persoon de hele vraag niet opnieuw hoeft te openen.