mDNS VPN-en belül: miért nem oldódnak fel a .local nevek

Az irodai nyomtató megjelenik a munkaasztalán lévő minden alkalmazásban, és eltűnik a VPN-en, pedig pingelheti azt a címet, amelyről tudja, hogy van neki. Semmi nem romlott el az alagútban: a felderítés és az elérhetőség külön szolgáltatások, és alapértelmezés szerint csak az egyikük halad át egy route-olt alagúton. Az alábbi ellenőrzések szétválasztják őket, mielőtt elkezdene útvonalakat hozzáadni. Egy útvonal nem tudja megjavítani azt a lekérdezést, amely soha nem hagyta el a linket.

Ellenőrizze, mi oldódik fel ma, és mi csak feloldottnak látszik

Először válassza szét a két kérdést: a hosztnév unicast lekérdezése egy feloldót kérdez, míg a _ipp._tcp keresése a helyi linket. Linuxon a avahi-browse -a megmutatja, mit láthat a multicast DNS, a resolvectl query name.local pedig azt, hogy a feloldó verem mit tesz ezzel a névvel. macOS-en a dns-sd -B _ipp._tcp felsorolja a felderített szolgáltatásokat anélkül, hogy előbb címre lenne szükség.

Ha a cím válaszol és a név nem, a route-olás működik, a felderítés nem. A .local nevet magán a hoszton is meg lehet válaszolni nss-mdns-en keresztül, ha az avahi-browse nincs telepítve, ezért egy sikeres getent vagy ping erre a névre nem bizonyítja, hogy a felderítés átkelt az alagúton; a keresési eredmény és a feloldó eredménye különböző bizonyítékok. Az alkalmazások gyorsítótárazzák, amit felderítettek, ezért a hiba gyakran órákkal a kapcsolódás után jelenik meg, nem a kapcsolódáskor. Zárja be és nyissa újra az alkalmazást, majd ellenőrizze, hogy a gyorsítótárazott bejegyzés nevet vagy címet tartalmaz-e, mert a cím még sokáig működik azután, hogy a felderítés leállt.

Miért nem halad át a lekérdezés soha az alagúton

A multicast DNS lekérdezéseket küld a 224.0.0.251 címre, a helyi hálózat vezérlőblokkján belül, az UDP 5353-as portjára. Az útválasztók nem továbbítják az ebből a blokkból származó címeket, ezért a lekérdezés azon a linken marad, ahová küldték. A küldők az IP TTL-t, illetve az IPv6 ugrási határt 255-re állítják, hogy a fogadó elutasíthasson egy már útválasztón áthaladt csomagot; így észleli a protokoll a linken kívüli hamisítást, nem így marad helyi. A lokalitás a célcímtől jön, nem egy ugrásnyi TTL-től.

Az alagút típusa is számít. A tun stílusú interfész IP-csomagokat visz és semmi mást, ezért egyetlen multicast csoport sem éli túl. A tap stílusú híd magát a szórási tartományt terjeszti ki, ezért néhány régi tervezés hidalt a route-olás helyett, és örökölte a híd minden problémáját.

A megbízható LAN kivétele ezen semmit sem változtat, mert azt dönti el, mely forgalom használhatja az alagutat, ahelyett hogy megtanítaná az alagutat multicast továbbítására. A csomagnak továbbra sincs közös szegmense, ahol hallható lenne.

Válasszon olyan névtervezést, amelyet fenn tud tartani

A vállalati erőforrásokhoz a tartós válasz egy route-olt hosztnév, amelyet a VPN által küldött feloldó szolgál ki, osztott DNS-sel, hogy a belső nevek belső szerverekre menjenek, minden más pedig ne. A Windows ezt névfeloldási házirend-táblaként teszi elérhetővé, a macOS interfészenkénti korlátozott feloldókat használ, és a legtöbb kliensnek van egyenértékű küldési beállítása. Az eszköz megtartja szokásos nevét a belső DNS-ben, és a felderítés megszűnik az útvonal részének lenni.

Egy felderítési proxy vagy mDNS-tükröző áthidalhatja a rést, és ez valódi tervezés saját hoszttal, saját kitettséggel és saját klienskövetelményekkel. Nem azért jelenik meg, mert útvonalat adott hozzá. Soha ne továbbítson .local lekérdezéseket nyilvános feloldóhoz: a tartományt a helyi multicast használat számára a RFC 6762 tartja fenn, és kifelé küldése lassú hibákat és szükségtelen adatfeltárást okoz.

A szolgáltatást ellenőrizze, ne a nevet

Egy név a keresési listában a felderítési lépést bizonyítja, nem azt, hogy a szolgáltatás válaszol. Nyissa meg a nyomtatási sort vagy a webes felületet, és hajtson végre valódi műveletet, majd ismételje meg újracsatlakozás után.

A felderítés agresszíven gyorsítótárazza a neveket, ezért egy elavult bejegyzés sikernek tűnhet. Ha tanúsítvány vagy hitelesítési kérés jelenik meg, az a következő réteg és külön probléma. Jegyezze fel, melyik mechanizmust változtatta meg, a feloldót vagy a felderítést, hogy a következő embernek ne kelljen újranyitnia az egész kérdést.