ખાનગી DNS નામો VPN ક્લાયન્ટ પર કેમ નિષ્ફળ જાય છે અને ક્યાં તપાસવું

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

કોઈ પણ પ્રોફાઇલ સંપાદિત કરતા પહેલાં ક્લાયન્ટ નામ સાથે શું કરે છે તેની ખાતરી કરો. Linux માં resolvectl query files.corp.example બતાવે છે કે કઈ લિંક અને કયા રિઝોલ્વરે જવાબ બનાવ્યો. Windows માં Resolve-DnsName files.corp.example જવાબ આપનાર સર્વર અને તેણે પાછું આપેલું સરનામું બતાવે છે.

કંઈ પણ બદલતા પહેલાં જવાબ વાંચો

જો નામ થોડા મિલિસેકન્ડમાં NXDOMAIN તરીકે પાછું આવે, તો પ્રશ્ન ક્યારેય તમારા ઝોન સુધી પહોંચ્યો નથી અને કોઈ જાહેર કે હોટેલ રિઝોલ્વરે જવાબ આપ્યો છે. જો તે લાંબા વિરામ પછી પાછું આવે, તો રસ્તામાં કંઈક UDP પોર્ટ 53 ફેંકી રહ્યું છે અને ક્લાયન્ટ છેવટે વિકલ્પ પર ઊતરી આવ્યો. જો તે સાચા સરનામા સાથે જવાબ આપે પણ કનેક્શન હજી અટકી જાય, તો શોધ બરાબર છે અને તમારી સમસ્યા રૂટિંગમાં કે સેવામાં જ છે.

આ ત્રણ ભાગમાં વહેંચણી એક કલાકનો અંદાજ બચાવે છે. તે એ પણ કહે છે કે VPN ને અડવું છે કે નહીં: જે નામ સાચા ખાનગી સરનામા પર ઉકેલાય છે તેણે રિઝોલ્વરનો રસ્તો પહેલેથી સાબિત કરી દીધો છે, તેથી બાકીનું કામ ડેટાના રસ્તે છે.

રિઝોલ્વરને ટનલની અંદરથી વહેંચો

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

OpenVPN પહેલા જૂથમાં છે. સર્વર પર push "dhcp-option DNS 10.8.0.53" અને push "dhcp-option DOMAIN corp.example" નિયંત્રણ ચેનલ દ્વારા નીચે જાય છે, પણ ત્યારે જ જ્યારે ક્લાયન્ટના કન્ફિગરેશનમાં pull હજી સક્રિય હોય. હાથે સંપાદિત ક્લાયન્ટ જે pull-filter ignore "dhcp-option" વહન કરે છે તે તેમને ક્યારેય જોશે નહીં, અને આ એક જ લાઇન આશ્ચર્યજનક રીતે ઘણા એવા કિસ્સાઓની સમજૂતી આપે છે કે «સર્વર તેને ધકેલે છે પણ મારું લેપટોપ માનતું નથી».

WireGuard બીજા જૂથમાં છે, કારણ કે પ્રોટોકોલમાં વિકલ્પોની કોઈ વાટાઘાટ જ નથી. રિઝોલ્વર અને શોધ ડોમેન ક્લાયન્ટના પોતાના [Interface] બ્લોકમાં DNS = 10.8.0.53, corp.example તરીકે જાય છે. wg-quick તેને resolvconf કે systemd-resolved દ્વારા લાગુ કરે છે, અને Windows પર સત્તાવાર ક્લાયન્ટ NRPT ના તે નિયમો સ્થાપિત કરે છે જે ફક્ત ટનલ ઊભી હોય ત્યાં સુધી જ હોય છે: Get-DnsClientNrptPolicy તેમને સૂચિબદ્ધ કરે છે, જે ક્લાયન્ટે તમારી ફાઇલ ક્યારેય લાગુ કરી કે નહીં તે જોવાની ઝડપી રીત બનાવે છે.

IPsec/IKEv2 વચ્ચે છે. strongSwan નું attr પ્લગઇન ખાબોચિયામાંથી લીધેલું DNS સર્વર પાછું આપી શકે છે, અને Windows ક્લાયન્ટ સામાન્ય રીતે તે સ્વીકારે છે, પણ પોતાનું નામ સર્વર જમાવી દેતી પ્રોફાઇલ ગેટવે જે આપે તે બધા પર ભારે પડે છે. Linux ક્લાયન્ટ પર સમાન હાથનું પગલું resolvectl dns wg0 10.8.0.53 અને પછી resolvectl domain wg0 '~corp.example' છે; બંને ઇન્ટરફેસ સાથે જ અદૃશ્ય થાય છે, જે ટનલ સુધી મર્યાદિત સેટિંગ માટે બરાબર એ જ છે જે તમે ઇચ્છો છો.

દરેક પ્રશ્ન ગળી જવાને બદલે પ્રત્યય મર્યાદિત કરો

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

અંદર ફક્ત ખાનગી પ્રત્યય મોકલો. systemd-resolved માં ~ થી શરૂ થતું ડોમેન ફક્ત રૂટિંગ માટે છે, તેથી ~corp.example નો અર્થ છે કે તે પ્રત્યય હેઠળની પૃચ્છાઓ તે લિંકના સર્વરોને જાય છે જ્યારે બાકીનું બધું ભૌતિક નેટવર્ક વાપરતું રહે છે. Windows એ જ કામ નામસ્થાન સુધી મર્યાદિત NRPT નિયમોથી કરે છે, અને macOS /etc/resolver/ હેઠળના વધારાની રિઝોલ્વર ફાઇલથી.

મલ્ટિકાસ્ટ નામો પોતાના જવાબને લાયક છે. .local નામો રચનાથી link-local છે (RFC 6762) અને બિંદુ-થી-બિંદુ tun ઇન્ટરફેસ તે મલ્ટિકાસ્ટ જૂથ વહન કરતું નથી, તેથી જાહેર રિઝોલ્વર ઉમેરવાથી તે પ્રકાશિત થશે નહીં અને આંતરિક unicast રિઝોલ્વરને તેમના વિશે પૂછવાથી NXDOMAIN પાછું આવે છે. avahi જેવું પરાવર્તક પરાવર્તન મોડમાં બે ખંડ જોડી શકે છે, પણ તે સર્વર પક્ષનો નિર્ણય છે જે કોઈ ક્લાયન્ટ માગી શકતું નથી. જો પ્રિન્ટર કે NAS નામથી પહોંચવા યોગ્ય હોવું જ જોઈએ, તો તેના બદલે તમારા ઝોનમાં તેને A રેકોર્ડ આપો.

સાબિત કરો કે જવાબ પાછો આવી શકે છે

અપહોચ સરનામા તરફ ઈશારો કરતો સાચો જવાબ બરાબર રિઝોલ્વરની સમસ્યા જેવો લાગે છે જ્યાં સુધી તમે માર્ગ તપાસો નહીં. કર્નલને પૂછો કે જવાબ ક્યાં જશે: ip route get 10.20.5.20 ઇન્ટરફેસ અને વધુ ઉપયોગી રીતે તે વાપરશે તે સ્રોત સરનામું જણાવે છે.

રિઝોલ્વરના સરનામા પર જ નજર રાખો. જે ક્લાયન્ટ પાસે DNS = 10.8.0.53 સાથે AllowedIPs = 10.20.0.0/16 છે તે પોતાની પૃચ્છાઓ ભૌતિક NIC દ્વારા બહાર મોકલે છે, જ્યાં તે ચૂપચાપ મરી જાય છે, કારણ કે રિઝોલ્વર ટનલ જે કોઈ પ્રિફિક્સનો દાવો કરે છે તેમાં નથી. આ અસંગતિ આ આખા ક્ષેત્રમાં સૌથી સામાન્ય એક-કારણ નિષ્ફળતા છે, અને DNS સેટિંગની મંજૂર પ્રિફિક્સ સાથે લીટી-દર-લીટી સરખામણી ન કરો ત્યાં સુધી તે અદૃશ્ય રહે છે.

ઓવરલેપિંગ શ્રેણીઓ ઊલટી નિષ્ફળતા સર્જે છે. જવાબ સાચો છે, માર્ગ અસ્તિત્વમાં છે, અને તે ખોટા યજમાન તરફ ઈશારો કરે છે, કારણ કે ઘરે 192.168.0.0/24 તે જ શ્રેણી તરફના ટનલના માર્ગ કરતાં વધુ વિશિષ્ટ છે. એક બાજુ ફરી ક્રમાંકિત કરો અથવા સાંકડો માર્ગ ધકેલો, પછી સેવા યજમાનનો ફાયરવોલ અને પરતનો માર્ગ ખાતરી કરો; strongSwan ની અગ્રેષણ અંગેની નોંધ તે માર્ગની sysctl બાજુને આવરી લે છે.

પ્રમાણપત્રો એ અલગ ઓળખ તપાસ છે જેનો દોષ લોકો DNS પર નાખે છે. જો બ્રાઉઝર ઉકેલવાની ભૂલને બદલે નામની અસંગતિ જણાવે, તો શોધ પહેલેથી ચાલી ગઈ છે અને પ્રમાણપત્રનું SAN જ સુધારવાની વસ્તુ છે. HTTPS નામ સામે ચકાસો, ક્યારેય નગ્ન IP સામે નહીં.

ગેટવેથી નહીં, ક્લાયન્ટથી ફરી ચકાસો

જે એપ્લિકેશનની વપરાશકર્તા ફરિયાદ કરે છે તેની અંદર ચકાસો, કારણ કે કમાન્ડ લાઇનની શોધ સાબિત કરતી નથી કે બ્રાઉઝર એ જ રસ્તો લે છે. Chrome નું સુરક્ષિત DNS અને Firefox નું network.trr.mode સિસ્ટમ રિઝોલ્વરને સંપૂર્ણપણે બાયપાસ કરી શકે છે, અને જ્યારે એમ કરે ત્યારે ખાનગી નામ કાં તો નિષ્ફળ જાય છે કાં જાહેર રિઝોલ્વર તરફ સરી જાય છે. resolvectl query ની હાથે ચલાવેલા dig @10.8.0.53 files.corp.example સાથે સરખામણી કહે છે કે બેમાંથી શું થયું.

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

આગલી મશીન માટે ટૂંકી યાદી: નામ ટનલના રિઝોલ્વર દ્વારા ઉકેલાય છે, પ્રત્યય મર્યાદિત છે વૈશ્વિક નહીં, રિઝોલ્વરનું સરનામું મંજૂર પ્રિફિક્સની અંદર છે, જવાબનું યજમાન સેવાના પોર્ટ પર જવાબ આપે છે, અને પ્રમાણપત્ર વપરાશકર્તાએ લખેલું નામ આવરી લે છે.