VPN અંદર mDNS: .local નામો કેમ ઉકેલાતા નથી

તમારા ઓફિસનું પ્રિન્ટર તમારા ડેસ્ક પરની દરેક એપ્લિકેશનમાં દેખાય છે અને VPN પર અદૃશ્ય થઈ જાય છે, જોકે તમે જાણો છો તે સરનામાને પિંગ કરી શકો છો. ટનલમાં કંઈ તૂટ્યું નથી: શોધ અને પહોંચ એ અલગ સેવાઓ છે, અને મૂળભૂત રીતે તેમાંથી ફક્ત એક જ રૂટેડ ટનલ પાર કરે છે. નીચેની ચકાસણીઓ રૂટ ઉમેરવાનું શરૂ કરો તે પહેલાં તેમને અલગ પાડે છે. જે ક્વેરીએ કદી લિંક છોડી નથી તેને રૂટ સુધારી શકતું નથી.

આજે શું ઉકેલાય છે અને શું ફક્ત ઉકેલાયેલું લાગે છે તે તપાસો

પહેલા બે પ્રશ્નો અલગ કરો: હોસ્ટનામ માટેની unicast ક્વેરી રિઝોલ્વરને પૂછે છે, જ્યારે _ipp._tcp માટેની શોધ સ્થાનિક લિંકને પૂછે છે. Linux પર, avahi-browse -a બતાવે છે કે મલ્ટિકાસ્ટ DNS શું જોઈ શકે છે, અને resolvectl query name.local બતાવે છે કે રિઝોલ્વર સ્ટેક તે નામ સાથે શું કરે છે. macOS પર, dns-sd -B _ipp._tcp પહેલા સરનામાની જરૂર વગર શોધાયેલી સેવાઓની યાદી બનાવે છે.

જો સરનામું જવાબ આપે અને નામ નહીં, તો રૂટિંગ કામ કરે છે અને શોધ કામ કરતી નથી. .local નામ હોસ્ટ પર જ nss-mdns દ્વારા પણ જવાબ મળી શકે છે, avahi-browse ઇન્સ્ટોલ ન હોય તો પણ, તેથી તે નામ પર સફળ getent કે પિંગ એ પુરાવો નથી કે શોધ ટનલ પાર થઈ છે; શોધ પરિણામ અને રિઝોલ્વર પરિણામ અલગ પુરાવા છે. એપ્લિકેશનો જે શોધ્યું તે કેશ કરે છે, તેથી નિષ્ફળતા ઘણી વાર કનેક્ટ થયાના કલાકો પછી દેખાય છે, કનેક્ટ થતી વખતે નહીં. એપ્લિકેશન બંધ કરી ફરી ખોલો, પછી તપાસો કે કેશ થયેલી એન્ટ્રીમાં નામ છે કે સરનામું, કારણ કે શોધ અટક્યા પછી ઘણા સમય સુધી સરનામું કામ કરતું રહે છે.

ક્વેરી કેમ કદી ટનલ પાર કરતી નથી

મલ્ટિકાસ્ટ DNS ક્વેરી 224.0.0.251 પર મોકલે છે, સ્થાનિક નેટવર્ક કંટ્રોલ બ્લોકની અંદર, UDP પોર્ટ 5353 પર. રાઉટર તે બ્લોકના સરનામાં ફોરવર્ડ કરતા નથી, તેથી ક્વેરી જે લિંક પર મોકલાઈ હતી ત્યાં જ રહે છે. પ્રેષકો IP TTL, અથવા IPv6 હોપ મર્યાદા, 255 પર સેટ કરે છે જેથી પ્રાપ્તકર્તા પહેલેથી રાઉટર પાર કરી ગયેલું પેકેટ નકારી શકે; પ્રોટોકોલ આ રીતે લિંકની બહારની છેતરપિંડી શોધે છે, એ રીતે નહીં કે તે સ્થાનિક રહે છે. સ્થાનિકતા ગંતવ્ય સરનામામાંથી આવે છે, એક-હોપ TTLમાંથી નહીં.

ટનલનો પ્રકાર પણ મહત્વનો છે. tun-શૈલીનું ઇન્ટરફેસ ફક્ત IP પેકેટ લઈ જાય છે અને બીજું કંઈ નહીં, તેથી કોઈ મલ્ટિકાસ્ટ જૂથ તેને પાર ટકી શકતું નથી. tap-શૈલીનો બ્રિજ બ્રોડકાસ્ટ ડોમેનને જ વિસ્તારે છે, તેથી કેટલાક જૂના ડિઝાઇન રૂટિંગને બદલે બ્રિજ કરતા હતા, અને બ્રિજ લાવે છે તે દરેક સમસ્યા વારસામાં મેળવી.

વિશ્વસનીય LAN માટેનો અપવાદ આમાંથી કંઈ બદલતો નથી, કારણ કે તે નક્કી કરે છે કે કયો ટ્રાફિક ટનલ વાપરી શકે, ટનલને મલ્ટિકાસ્ટ ફોરવર્ડ કરવાનું શીખવવાને બદલે. પેકેટ પાસે હજી પણ સાંભળી શકાય તેવો કોઈ સહિયારો સેગમેન્ટ નથી.

એવી નામકરણ ડિઝાઇન પસંદ કરો જે તમે ટકાવી શકો

કંપનીના સંસાધનો માટે ટકાઉ જવાબ એ રૂટેડ હોસ્ટનામ છે જે VPN ધકેલે છે તે રિઝોલ્વર દ્વારા પરોવાય છે, સાથે સ્પ્લિટ DNS જેથી આંતરિક નામો આંતરિક સર્વર પર જાય અને બાકીનું બધું ન જાય. Windows તેને નામ રિઝોલ્યુશન પોલિસી ટેબલ તરીકે આપે છે, macOS ઇન્ટરફેસ દીઠ સ્કોપ્ડ રિઝોલ્વર વાપરે છે, અને મોટાભાગના ક્લાયન્ટ પાસે સમકક્ષ પુશ સેટિંગ હોય છે. ઉપકરણ આંતરિક DNSમાં તેનું સામાન્ય નામ રાખે છે, અને શોધ માર્ગનો ભાગ બનવાનું બંધ કરે છે.

ડિસ્કવરી પ્રોક્સી કે mDNS રિફ્લેક્ટર આ અંતરને પુલ કરી શકે છે, અને તે પોતાના હોસ્ટ, પોતાના એક્સપોઝર અને પોતાના ક્લાયન્ટ જરૂરિયાતો સાથેનું વાસ્તવિક ડિઝાઇન છે. તમે રૂટ ઉમેર્યું તેના કારણે તે દેખાતું નથી. કદી પણ .local ક્વેરી જાહેર રિઝોલ્વરને ફોરવર્ડ કરશો નહીં: ડોમેન RFC 6762 દ્વારા સ્થાનિક મલ્ટિકાસ્ટ ઉપયોગ માટે અનામત છે, અને તેને બહાર મોકલવાથી ધીમી નિષ્ફળતાઓ અને બિનજરૂરી માહિતી જાહેર થાય છે.

નામ નહીં, સેવા ચકાસો

શોધ યાદીમાં નામ શોધનું પગલું સાબિત કરે છે, સેવા જવાબ આપે છે તે નહીં. પ્રિન્ટ કતાર કે વેબ ઇન્ટરફેસ ખોલો અને વાસ્તવિક ક્રિયા પૂરી કરો, પછી ફરી કનેક્ટ થયા પછી તેને પુનરાવર્તિત કરો.

શોધ નામોને આક્રમક રીતે કેશ કરે છે, તેથી જૂની એન્ટ્રી સફળતા જેવી લાગી શકે છે. જો પ્રમાણપત્ર કે પ્રમાણીકરણ પ્રોમ્પ્ટ દેખાય, તો તે આગલું સ્તર અને અલગ સમસ્યા છે. તમે કઈ પદ્ધતિ બદલી છે, રિઝોલ્વર કે શોધ, તે લખો જેથી આગલી વ્યક્તિએ આખો પ્રશ્ન ફરી ન ખોલવો પડે.