mDNS VPN iekšienē: kāpēc .local vārdi netiek atrisināti

Jūsu biroja printeris parādās katrā lietotnē uz jūsu galda un pazūd VPN, lai gan jūs varat pingot adresi, kurai, kā jūs zināt, tas ir. Tunelī nekas nav salūzis: atklāšana un sasniedzamība ir atsevišķi pakalpojumi, un pēc noklusējuma tikai viens no tiem šķērso maršrutētu tuneli. Tālāk esošās pārbaudes atdala abus pirms maršrutu pievienošanas. Maršruts nevar salabot vaicājumu, kas nekad nav pametis saiti.

Pārbaudiet, kas šodien tiek atrisināts un kas tikai izskatās atrisināts

Vispirms atdaliet divus jautājumus: unicast vaicājums par resursdatora nosaukumu jautā risinātājam, savukārt _ipp._tcp meklēšana jautā vietējai saitei. Linux sistēmā avahi-browse -a parāda, ko var redzēt multicast DNS, un resolvectl query name.local parāda, ko risinātāja steks dara ar šo nosaukumu. macOS sistēmā dns-sd -B _ipp._tcp uzskaita atklātos pakalpojumus, vispirms neprasot adresi.

Ja adrese atbild un nosaukums ne, maršrutēšana darbojas, un atklāšana ne. Nosaukums .local var tikt atbildēts arī pašā resursdatorā, izmantojot nss-mdns, bez instalēta avahi-browse, tāpēc veiksmīgs getent vai ping uz šo nosaukumu nav pierādījums, ka atklāšana šķērsoja tuneli; meklēšanas rezultāts un risinātāja rezultāts ir dažādi pierādījumi. Lietotnes kešatmiņā glabā to, ko atklājušas, tāpēc kļūme bieži parādās stundas pēc savienojuma, nevis savienojuma brīdī. Aizveriet un vēlreiz atveriet lietotni, pēc tam pārbaudiet, vai kešatmiņas ierakstā ir nosaukums vai adrese, jo adrese darbojas vēl ilgi pēc tam, kad atklāšana ir apstājusies.

Kāpēc vaicājums nekad nešķērso tuneli

Multicast DNS sūta vaicājumus uz 224.0.0.251, vietējā tīkla vadības bloka iekšienē, uz UDP ostu 5353. Maršrutētāji nepārsūta adreses no šī bloka, tāpēc vaicājums paliek saitē, uz kuru tas tika nosūtīts. Sūtītāji arī iestata IP TTL jeb IPv6 lēciena ierobežojumu uz 255, lai uztvērējs varētu noraidīt paketi, kas jau ir šķērsojusi maršrutētāju; tā protokols atklāj viltošanu ārpus saites, nevis tā tas paliek vietējs. Vietējums nāk no galamērķa adreses, nevis no viena lēciena TTL.

Arī tuneļa tips ir svarīgs. tun stila saskarne pārvadā IP paketes un neko citu, tāpēc neviena multicast grupa to nešķērso. tap stila tilts paplašina pašu apraides domēnu, tāpēc daži vecie dizaini tiltu izvēlējās maršrutēšanas vietā un mantoja visas tilta radītās problēmas.

Uzticama LAN izņēmums neko nemaina, jo tas izlemj, kurš trafiks drīkst izmantot tuneli, nevis māca tunelim pārsūtīt multicast. Paketei joprojām nav kopīga segmenta, kurā to sadzirdēt.

Izvēlieties nosaukumu dizainu, ko varat uzturēt

Uzņēmuma resursiem ilgtspējīgā atbilde ir maršrutēts resursdatora nosaukums, ko apkalpo VPN virzītais risinātājs, kopā ar sadalītu DNS, lai iekšējie nosaukumi iet uz iekšējiem serveriem, bet viss pārējais ne. Windows to parāda kā nosaukumu izšķiršanas politikas tabulu, macOS izmanto ierobežotus risinātājus katram interfeisam, un lielākajai daļai klientu ir līdzvērtīgs virzīšanas iestatījums. Ierīce saglabā savu parasto nosaukumu iekšējā DNS, un atklāšana pārstāj būt ceļa daļa.

Atklāšanas starpnieks vai mDNS atstarotājs var pārmest tiltu pār šo plaisu, un tas ir īsts dizains ar savu resursdatoru, savu pakļautību un savām klienta prasībām. Tas neparādās tāpēc, ka pievienojāt maršrutu. Nekad nepārsūtiet .local vaicājumus publiskam risinātājam: domēns ir rezervēts vietējai multicast lietošanai saskaņā ar RFC 6762, un tā sūtīšana uz āru rada lēnas kļūmes un nevajadzīgu datu atklāšanu.

Pārbaudiet pakalpojumu, nevis nosaukumu

Nosaukums meklēšanas sarakstā pierāda atklāšanas soli, nevis to, ka pakalpojums atbild. Atveriet drukas rindu vai tīmekļa saskarni un veiciet reālu darbību, pēc tam atkārtojiet to pēc atkārtota savienojuma.

Atklāšana agresīvi kešatmiņā glabā nosaukumus, tāpēc novecojis ieraksts var izskatīties kā panākums. Ja parādās sertifikāts vai autentifikācijas pieprasījums, tas ir nākamais slānis un atsevišķa problēma. Pierakstiet, kuru mehānismu mainījāt, risinātāju vai atklāšanu, lai nākamajai personai nav jāatver viss jautājums no jauna.