mDNS yn in VPN: wêrom’t .local-nammen net oplost wurde

De printer fan jo kantoar ferskynt yn elke applikaasje by jo buro en ferdwynt op ’e VPN, ek al kinne jo it adres pingje dat jo witte dat er hat. Neat yn ’e tunnel is stikken: ûntdekking en berikberens binne aparte tsjinsten, en mar ien fan beide stekt by default in routed tunnel oer. De kontrôles hjirûnder skiede se foardat jo rûtes begjinne ta te foegjen. In rûte kin in fraach net reparearje dy’t nea de keppeling ferlitten hat.

Kontrolearje wat hjoed oplost, en wat allinnich oplost liket

Skiede earst de twa fragen: in unicast-fraach foar in hostnamme freget in resolver, wylst in syktocht nei _ipp._tcp de lokale keppeling freget. Op Linux lit avahi-browse -a sjen wat multicast-DNS sjen kin, en resolvectl query name.local lit sjen wat de resolver-stapel mei dy namme docht. Op macOS listet dns-sd -B _ipp._tcp ûntdutsen tsjinsten op sûnder earst in adres nedich te hawwen.

As it adres antwurdet en de namme net, dan wurket routing en wurket ûntdekking net. In .local-namme kin ek op ’e host sels beantwurde wurde fia nss-mdns sûnder dat avahi-browse ynstallearre is, dus in suksesfolle getent of ping nei dy namme is gjin bewiis dat ûntdekking de tunnel oerstutsen hat; it sykresultaat en it resolver-resultaat binne ferskillende stikken bewiis. Applikaasjes cache wat se ûntdutsen hawwe, en dêrom ferskynt de flater faak oeren nei’t ferbûn is ynstee fan by it ferbinen. Slút en iepene de applikaasje opnij, en kontrolearje dan oft de cachede ynfier in namme of in adres befettet, want in adres bliuwt lang wurkjen neidat ûntdekking stoppe.

Wêrom’t de fraach nea de tunnel oerstekt

Multicast DNS stjoert fragen nei 224.0.0.251, binnen it lokale netwurkbehearblok, op UDP-poarte 5353. Routers stjoere gjin adressen út dat blok troch, dus de fraach bliuwt op ’e keppeling dêr’t er hinne stjoerd is. Stjoerders sette ek de IP-TTL, of de IPv6-hoplimyt, op 255 sadat in ûntfanger in pakket wegerje kin dat al in router oerstutsen hat; sa ûntdekt it protokol spoofing bûten de keppeling, net sa bliuwt it lokaal. Lokaliteit komt fan it bestimmingsadres, net fan in TTL fan ien hop.

It tunneltype makket ek út. In ynterface fan it tun-type ferfiert IP-pakketten en neat oars, dus gjin multicast-groep oerlibbet dat. In brêge fan it tap-type wreidet it broadcast-domein sels út, en dêrom brêgen guon âlde ûntwerpen ynstee fan te routen, en erven elke probleem dy’t brêgen bringt.

In útsûndering foar fertroude LAN feroaret hjir neat oan, want dy bepaalt hokker ferkear de tunnel brûke mei ynstee fan ’e tunnel te learen multicast troch te stjoeren. It pakket hat noch altyd gjin dielde segmint om op heard te wurden.

Kies in namme-ûntwerp dat jo ûnderstypje kinne

Foar bedriuwsboarnen is it duorsume antwurd in routed hostnamme tsjinne troch de resolver dy’t de VPN pusht, mei split DNS sadat ynterne nammen nei ynterne servers gean en al it oare net. Windows biedt dat as in namme-resolúsjebeliedstabel, macOS brûkt beheinde resolvers per ynterface, en de measte kliïnten hawwe in lykweardige push-ynstelling. It apparaat hâldt syn normale namme yn ynterne DNS, en ûntdekking hâldt op diel fan it paad te wêzen.

In ûntdekkingsproxy of in mDNS-reflektor kin de kleau oerbrêgje, en it is in echt ûntwerp mei syn eigen host, syn eigen bleatstelling en syn eigen klienteasken. It ferskynt net om’t jo in rûte tafoege hawwe. Stjoer nea .local-fragen nei in iepenbiere resolver: it domein is foarbeholden foar lokaal multicast-gebrûk troch RFC 6762, en it nei bûten stjoeren jout stadige flaters en ûnnedige gegevensbleatstelling.

Ferifiearje de tsjinst, net de namme

In namme yn in syklist bewiist de ûntdekkingsstap, net dat de tsjinst antwurdet. Iepenje de printwachtlist of de webynterface en foltôgje in echte operaasje, en werhelje dy nei in werferbining.

Ûntdekking cachet nammen agressyf, dus in ferâldere ynfier kin op sukses lykje. As der in sertifikaat of autentikaasjepromt ferskynt, is dat de folgjende laach en in apart probleem. Skriuw op hokker meganisme jo feroare hawwe, resolver of ûntdekking, sadat de folgjende persoan de hiele fraach net opnij iepenje hoecht.