mDNS unutar VPN-a: zašto se .local imena ne razrješavaju

Pisač u vašem uredu pojavljuje se u svakoj aplikaciji za vašim stolom i nestaje na VPN-u, iako možete pingati adresu za koju znate da ju ima. Ništa u tunelu nije pokvareno: otkrivanje i dostupnost odvojene su usluge i samo jedna od njih prema zadanim postavkama prelazi usmjereni tunel. Provjere u nastavku razdvajaju ih prije nego počnete dodavati rute. Ruta ne može popraviti upit koji nikad nije napustio vezu.

Provjerite što se danas razrješava, a što samo izgleda razrješeno

Najprije razdvojite dva pitanja: unicast upit za ime hosta pita razrješivač, dok pretraga za _ipp._tcp pita lokalnu vezu. Na Linuxu avahi-browse -a pokazuje što multicast DNS može vidjeti, a resolvectl query name.local pokazuje što razrješivački stog radi s tim imenom. Na macOS-u dns-sd -B _ipp._tcp navodi otkrivene usluge bez potrebe za adresom.

Ako adresa odgovara, a ime ne, usmjeravanje radi, a otkrivanje ne. Ime .local može se odgovoriti i na samom hostu preko nss-mdns bez instaliranog avahi-browse, pa uspješan getent ili ping na to ime nije dokaz da je otkrivanje prešlo tunel; rezultat pretrage i rezultat razrješivača različiti su dijelovi dokaza. Aplikacije keširaju ono što su otkrile, zato se kvar često pojavljuje satima nakon spajanja, a ne pri spajanju. Zatvorite i ponovno otvorite aplikaciju, zatim provjerite sadrži li keširani zapis ime ili adresu, jer adresa nastavlja raditi dugo nakon što je otkrivanje stalo.

Zašto upit nikad ne prelazi tunel

Multicast DNS šalje upite na 224.0.0.251, unutar bloka za upravljanje lokalnom mrežom, na UDP port 5353. Usmjerivači ne prosljeđuju adrese iz tog bloka, pa upit ostaje na vezi na koju je poslan. Pošiljatelji također postavljaju IP TTL, odnosno IPv6 ograničenje skoka, na 255 kako bi primatelj mogao odbiti paket koji je već prešao usmjerivač; tako protokol otkriva lažiranje izvan veze, a ne tako što ostaje lokalno. Lokalnost dolazi od odredišne adrese, ne od TTL-a od jednog skoka.

Vrsta tunela također je važna. Sučelje u stilu tun-a prenosi IP pakete i ništa drugo, pa nijedna multicast grupa ne preživljava kroz njega. Most u stilu tap-a proširuje samu domenu emitiranja, zato su neki stari dizajni postavljali most umjesto usmjeravanja i naslijedili svaki problem koji most donosi.

Iznimka za pouzdanu LAN mrežu ne mijenja ništa od ovoga jer odlučuje koji promet smije koristiti tunel, umjesto da tunel uči prosljeđivati multicast. Paket još uvijek nema zajednički segment na kojem bi se čuo.

Odaberite dizajn imenovanja koji možete održavati

Za tvrtkine resurse trajan odgovor je usmjereno ime hosta koje poslužuje razrješivač koji VPN gura, uz podijeljeni DNS tako da interna imena idu na interne poslužitelje, a sve ostalo ne. Windows to izlaže kao tablicu pravila razrješavanja imena, macOS koristi ograničene razrješivače po sučelju, a većina klijenata ima ekvivalentnu postavku guranja. Uređaj zadržava svoje uobičajeno ime u internom DNS-u i otkrivanje prestaje biti dio puta.

Proxy za otkrivanje ili mDNS reflektor može premostiti tu prazninu i to je stvaran dizajn s vlastitim hostom, vlastitom izloženošću i vlastitim zahtjevima klijenata. Ne pojavljuje se zato što ste dodali rutu. Nikada ne prosljeđujte .local upite javnom razrješivaču: domena je rezervirana za lokalnu multicast uporabu prema RFC 6762, a slanje prema van stvara spora neuspjeha i nepotrebno otkrivanje podataka.

Provjerite uslugu, a ne ime

Ime na popisu pretrage dokazuje korak otkrivanja, a ne da usluga odgovara. Otvorite red za ispis ili web sučelje i obavite stvarnu radnju, zatim je ponovite nakon ponovnog spajanja.

Otkrivanje agresivno kešira imena, pa zastario zapis može izgledati kao uspjeh. Ako se pojavi certifikat ili upit za provjeru autentičnosti, to je sljedeći sloj i zaseban problem. Zapišite koji ste mehanizam promijenili, razrješivač ili otkrivanje, da sljedeća osoba ne mora ponovno otvarati cijelo pitanje.