વિભાજિત DNS અને VPN: ડોમેન નિયમો IP રૂટ નથી
વિભાજિત DNS નામ પ્રમાણે રિઝોલ્વર પસંદ કરે છે, અને જવાબને હજી પણ રૂટની જરૂર છે. ડોમેન નિયમ અને માર્ગ અલગ રીતે ચકાસો, જે પ્લેટફોર્મ તમે ખરેખર ચલાવો છો તેના પર.
તમારો લેપટોપ intranet.corp ને ટનલ દ્વારા ઉકેલે છે જ્યારે gitlab.com સેવા પ્રદાતાના રિઝોલ્વર તરફ જતું રહે છે, અને આ એ ગોઠવણ છે જે રચના મુજબ કામ કરે છે. બે અલગ નિર્ણયોએ તેને બનાવ્યું: નામ-મેળ નિયમે રિઝોલ્વર પસંદ કર્યું, અને રૂટે જવાબ પાછો લાવ્યો. બેમાંથી કોઈપણ તોડો અને બ્રાઉઝર એવી નિષ્ફળતા દેખાડે છે જે બહારથી એકસરખી લાગે છે. વિભાજિત DNS ના મોટા ભાગના અહેવાલો બીજી નિષ્ફળતાનું વર્ણન કરે છે અને સાથે પ્રથમ વિશે પુરાવા ટાંકે છે.
બંને અર્ધભાગ જુદી જગ્યાએ રહે છે અને સામાન્ય રીતે જુદા લોકો તેમને સંપાદિત કરે છે. એક VPN પ્રોફાઇલ સાથે જોડાયેલ DNS નીતિ છે, બીજો એ રૂટ છે જે ટનલ સ્થાપિત કરે છે અથવા રોકે છે. જ્યારે કોઈ નક્કી ન કરે કે ખરેખર કયો અર્ધભાગ ખસ્યો, ડિબગિંગ અટકી જાય છે.
એક વિનંતીમાં છુપાયેલા બે નિર્ણય
નામનો અર્ધભાગ નીતિ ઑબ્જેક્ટ છે, રૂટ નથી. Windows પર તે VPN પ્રોફાઇલ પર નામ-ઉકેલ નીતિ છે; Apple પ્લેટફોર્મ પર DNS સેટિંગ્સ ઑબ્જેક્ટ પર મેળ ખાતા ડોમેનનો સમૂહ; Linux પર રૂટિંગ ડોમેન, વિભાજિત રિઝોલ્વર લાઇન અથવા નામ સેવા સ્વિચનો ક્રમ. માર્ગનો અર્ધભાગ સામાન્ય રૂટિંગ છે, ટનલ અથવા હાથે સ્થાપિત, અને હોસ્ટનામ શું છે તે તે જાણતું નથી. જે પ્રોફાઇલ પ્રત્યય સ્વીકારે છે તે ફક્ત નક્કી કરે છે કે કોણ જવાબ આપશે; તે જવાબને કદી પહોંચી શકાય તેવો બનાવતું નથી.
ઝડપી લક્ષણ પરીક્ષણ તેમને અલગ પાડે છે: નામની જગ્યાએ સરનામું મૂકો. જો સરનામું કામ કરે, તો માર્ગ ઠીક છે અને નિયમ ખોટો. જો સરનામું પણ નિષ્ફળ જાય, તો નિયમ સાચો હોઈ શકે અને માર્ગ ખૂટતો હોઈ શકે.
દરેક પ્લેટફોર્મ એક જ નામ નિયમ કેવી રીતે વ્યક્ત કરે છે
હેતુ એકસરખો છે અને ક્ષેત્રોનાં નામ નથી. એક ક્લાયન્ટમાંથી બીજામાં નકલ કરેલું ઉદાહરણ સ્વચ્છ રીતે પાર્સ થાય છે અને કદી મેળ ખાતું નથી. ત્રણ સ્વરૂપો આવા દેખાય છે:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
મેળ અથવા રૂટિંગ ડોમેન એ પ્રત્યય પરીક્ષણ છે, તેથી intranet.corp git.intranet.corp ને આવરે છે અને corp.intranet ને આવરતું નથી, અને તેને ઉલટાવવું આખી ગોઠવણની સૌથી સામાન્ય ભૂલ છે. Windows મેપિંગને પ્રોફાઇલ સાથે જોડાયેલ નામ-ઉકેલ નીતિ તરીકે વહન કરે છે, ઇન્ટરફેસ પાસે પહેલેથી હતી તેવી કોઈપણ પ્રત્યય યાદી સામે પોતાના અગ્રતા ક્રમ સાથે. Apple પ્લેટફોર્મ નેટવર્ક એક્સ્ટેન્શનના DNS સેટિંગ્સ ઑબ્જેક્ટ સાથે મેળ ખાતા ડોમેન જોડે છે, અને સિસ્ટમ તેમને દરેક મર્યાદિત રિઝોલ્વર માટે લાગુ કરે છે. આ સ્વરૂપોમાંથી કોઈ રૂટ નથી, અને કોઈ પણ અગમ્ય સરનામાને ગમ્ય બનાવી શકતું નથી. Windows નામ-ઉકેલ નીતિ સંદર્ભ તે પ્લેટફોર્મ માટે ક્ષેત્રોનાં નામ અને અગ્રતા નિયમોની યાદી આપે છે, અને તે Apple કે systemd દસ્તાવેજો વાપરે છે તે નિયમો નથી.
સાચા જવાબને હજી પણ માર્ગની જરૂર છે
રિઝોલ્વરનો જવાબ ફક્ત એક સરનામું છે, અને એપ્લિકેશને હજી ત્યાં પહોંચવું પડે છે. વિભાજિત-ટનલ રચના ઘણી વાર 10.20.0.0/16 ધકેલે છે અને મૂળભૂત રૂટ રોકી રાખે છે, તેથી આંતરિક નામ ઉકેલાય છે અને પછી જોડાણ લટકી જાય છે. વિરુદ્ધ કિસ્સો પણ એટલો જ સામાન્ય છે: રૂટ અસ્તિત્વમાં છે, જાહેર રિઝોલ્વર ખાનગી નામને NXDOMAIN સાથે જવાબ આપે છે, અને નિષ્ફળતા રૂટિંગ સમસ્યા તરીકે નોંધાય છે. પહેલાં માર્ગ ચકાસવાથી તમે એવા નામ માટે રૂટ સામે જોઈ રહો છો જે કદી ઉકેલાવાનું ન હતું.
એક ત્રીજું દ્વાર પણ છે જે કોઈ અર્ધભાગ આવરતું નથી. ગેટવે પરનું ACL, ફાયરવૉલ નિયમ અથવા ક્લાયન્ટ-બાજુની નીતિ બંને નિર્ણય સાચા થયા પછી જોડાણ કાઢી નાખી શકે છે. જ્યારે નામ ઉકેલાય, રૂટ અસ્તિત્વમાં હોય અને જોડાણ તો પણ સમય સમાપ્ત કરે, ત્યારે DNS ચકાસવાનું બંધ કરો.
નિશ્ચિત ક્રમમાં નામ અને માર્ગ ચકાસવા
એક ક્રમ પસંદ કરો અને તેને પકડી રાખો, નહીં તો તમે છેલ્લે નિષ્ફળ ગયેલા પગલા પાછળ દોડશો. દસ્તાવેજીકૃત પૂર્ણ આંતરિક નામ ઉકેલો, ખાતરી કરો કે જવાબ એ સરનામું છે જે રૂટ કોષ્ટક વહન કરી શકે, પછી જાહેર નામ સાથે પુનરાવર્તન કરો જેથી સાબિત થાય કે ટનલે બધું કબજે કર્યું નથી. systemd હોસ્ટ પર પ્રશ્ન અને રિઝોલ્વરનું રૂટિંગ ડોમેન એક આદેશના અંતરે છે:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows ક્લાયન્ટ એ જ બે પ્રશ્નો જુદા cmdlet સાથે પૂછે છે. બીજું એ ઇન્ટરફેસ જણાવે છે જે સિસ્ટમ ખરેખર વાપરશે:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10જો શોધ સરનામું પાછું આપે અને માર્ગ તપાસ ભૌતિક ઇન્ટરફેસનું નામ લે, તો નામ નિયમ કામ કર્યું અને રૂટ નહીં. જો ટૂંકું નામ નિષ્ફળ જાય જ્યારે પૂર્ણ નામ ઉકેલાય, તો પ્રત્યય યાદી ખોટી છે, રિઝોલ્વર નહીં.
સરખામણી સામાન્ય રીતે ક્યાં ખોટી પડે છે
પ્રથમ ભૂલ એ છે કે અસંબંધિત જાહેર રિઝોલ્વરને ખાનગી નામ વિશે પૂછવું અને ઇનકારને VPN વિશે પુરાવા તરીકે વાંચવો. બીજી એ છે કે કામ કરતી જાહેર શોધ ટનલના રિઝોલ્વર માર્ગને સાબિત કરે છે એમ માનવું. ત્રીજી એ છે કે વિભાજિત ટનલિંગ અને વિભાજિત DNS ને એક જ રચના નિર્ણય ગણવો, જ્યારે તૈનાતી એકમાં સાચી અને બીજામાં તૂટેલી હોઈ શકે. દરેક ભૂલ એવી પરીક્ષામાંથી આત્મવિશ્વાસુ નિષ્કર્ષ આપે છે જેણે આરોપિત ભાગનો કદી અભ્યાસ કર્યો નથી.
પોતાનું સુરક્ષિત DNS ધરાવતું બ્રાઉઝર પણ સિસ્ટમ નિયમને ટાળી શકે છે, તેથી એક બ્રાઉઝર નિષ્ફળ જાય અને બીજું સફળ થાય તે વિરોધાભાસ નથી. જવાબ આપનારા રિઝોલ્વરની સરખામણી કરો, ફરિયાદ કરનારા બ્રાઉઝરની નહીં.
એકવાર બંને અર્ધભાગ દેખાય, ત્યારે બાકીનો પ્રશ્ન નીતિનો છે, ટેકનિકલ નહીં: કયા નામ-અવકાશ સંસ્થાના છે, દરેક જવાબનો માલિક કોણ છે, અને તેમાંથી કયા મશીન છોડવા જોઈએ. તે પ્રોફાઇલની બાજુમાં લખો, કારણ કે નિયમને અડનારી આગલી વ્યક્તિને તેની જરૂર પડશે.