Windows પર OpenConnect ની DNS સેટિંગ્સ ખરેખર કોણ લાગુ કરે છે?
Windows રિઝોલ્વર સ્થિતિ ત્રણ જગ્યાએ રાખે છે. એડેપ્ટર DNS જાતે સંપાદિત કરતાં કે નેમસ્પેસ નિયમ ઉમેરતાં પહેલાં કનેક્શન ધરાવતો હેલ્પર શોધો.
ટનલ ઉપર લાવવી એ તેની DNS કિંમતો સ્થાપિત કરવા જેવું નથી. OpenConnect વાટાઘાટ કરે છે, અને Windows બાજુનો હેલ્પર લાગુ કરે છે. આ બે પગલાં વચ્ચેનું અંતર આ ક્લાયન્ટ પરના મોટા ભાગના ખાનગી-નામ નિષ્ફળતાઓ સમજાવે છે, અને હેલ્પર લગભગ કદી Windows VPN સેટિંગ્સ પૃષ્ઠ નથી.
ગેટવેએ આપેલું અને Windows દ્વારા સ્થાપિત થયેલું અલગ કરો
ક્લાયન્ટ કનેક્શન ડેટા સ્ક્રિપ્ટ ઇન્ટરફેસને સોંપે છે, અને Unix તથા Windows રૂપો અલગ પ્રોગ્રામ છે. Windows પર અમલ સામાન્ય રીતે JavaScript હેલ્પર હોય છે જે આંતરિક DNS સર્વર અને આંતરિક ડોમેન જેવા ચલ વાંચે છે તે પહેલાં કોઈ એડેપ્ટરને સ્પર્શે. ટનલમાં કંઈ જ રિઝોલ્વર સ્થિતિ લખતું નથી.
એ વિભાજન મહત્ત્વનું છે કારણ કે કિંમત વાટાઘાટમાં હોઈ શકે અને એડેપ્ટર સુધી કદી ન પહોંચે. જે હેલ્પર ગુમ છે, અડધે રસ્તે નિષ્ફળ જાય છે, અથવા GUI આવરણમાં બંધાયેલી જૂની નકલ છે તે Windows ને બરાબર જેમ હતું તેમ છોડી દે છે. સત્ર જોડાયેલું દેખાય છે, ખાનગી નામ હજી સ્થાનિક પ્રદાતા દ્વારા ઉકેલાય છે, અને ક્લાયન્ટ વિન્ડોમાં કંઈ જ તફાવત તરફ ઇશારો કરતું નથી. હેલ્પરનું પોતાનું આઉટપુટ વાંચવું એ કયો તબક્કો તૂટ્યો તે જાણવાનો એકમાત્ર વિશ્વસનીય રસ્તો છે.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI આવરણ પોતાની ક્લાયન્ટ અને હેલ્પરની નકલ લાવી શકે છે, તેથી ડિસ્ક પર બીજે ક્યાંય બીજું openconnect.exe હોવું કંઈ સાબિત કરતું નથી. તેની ગોઠવણીનો નિર્ણય કરતાં પહેલાં જે એક્ઝિક્યુટેબલ સત્ર શરૂ કર્યું તે શોધો.
રિઝોલ્વર સ્થિતિ બદલ્યા વિના વાંચો
ત્રણ ફક્ત-વાંચન પ્રશ્નો સામાન્ય મૂંઝવણ આવરી લે છે, અને દરેક અલગ પ્રશ્નનો જવાબ આપે છે:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveએડેપ્ટર-સ્તરનો સર્વર એ છે જેને મોટા ભાગના લોકો VPN DNS કહે છે. કનેક્શન-વિશિષ્ટ પ્રત્યય નક્કી કરે છે કે ટૂંકું નામ બિલકુલ વિસ્તરિત થાય છે કે નહીં. નેમસ્પેસ નીતિ યાદી એડેપ્ટર ક્રમને ધ્યાનમાં લીધા વિના મેળ ખાતા નામોને લાગુ પડે છે, અને ત્યાં ખાલી પરિણામ ખામી નથી જ્યારે હેલ્પરે કદી એક બનાવવાનો ઇરાદો ન હતો. સંપાદન પહેલાં ત્રણેય વાંચવું એ જ એવી સુધારણા અટકાવે છે જે ફક્ત લક્ષણને બીજે ખસેડે છે.
સંપૂર્ણ લાયક નામથી શરૂ કરો. જો FQDN ઉકેલાય અને ટૂંકું નામ ન ઉકેલાય, તો પ્રત્યય કે શોધ યાદી એ અંતર છે, સર્વર સરનામું નહીં.
બીજા પગલા તરીકે ઇચ્છિત સર્વરને સીધો પૂછો, પહેલેથી સ્થાપિત કોઈપણ રિઝોલ્વર સાધન સાથે. સીધો જવાબ સાબિત કરે છે કે સર્વર સુલભ છે અને ઝોન માટે સત્તાવાર છે. એ કંઈ સાબિત કરતું નથી કે એપ્લિકેશન ડિફોલ્ટ રૂપે કયા સર્વરને પૂછે છે.
કનેક્શન ધરાવતા ઘટકનું નામ આપો
બે ગોઠવણીઓ સામાન્ય છે. ટર્મિનલથી શરૂ થયેલો ક્લાયન્ટ તેનો સ્ક્રિપ્ટ માર્ગ સ્પષ્ટ રીતે પસાર કરે છે, તેથી માલિક ચાલેલા આદેશમાં દેખાય છે. પેકેજ્ડ એપ્લિકેશન તમારા વતી ક્લાયન્ટ શરૂ કરે છે અને હેલ્પરને પોતાની ડિરેક્ટરીમાં રાખે છે, એટલે કે વેન્ડર નક્કી કરે છે કે તે ક્યારે બદલાશે.
કંઈપણ બદલતાં પહેલાં ઇન્સ્ટોલેશનો વચ્ચે હેલ્પર આવૃત્તિઓની તુલના કરો. ફાઇલનું નામ પરિચિત લાગે છે એટલે મિરરમાંથી લાવેલો હેલ્પર ઉન્નત અધિકારો સાથે ચલાવવો DNS અંતરને સુરક્ષા ઘટનામાં ફેરવે છે.
માલિક જાણીતો થાય એટલે સુધારણાનું લક્ષ્ય સ્પષ્ટ થાય છે: લોન્ચરમાં સમર્થિત સ્ક્રિપ્ટ માર્ગ, પેકેજ અપડેટ, અથવા ગેટવે પર સુધારેલી પ્રોફાઇલ. એમાંથી કોઈને એડેપ્ટર ગુણધર્મો જાતે સંપાદિત કરવાની જરૂર નથી.
માલિક સુધારો, એડેપ્ટર નહીં
એડેપ્ટર પર જાતે સેટ કરેલું DNS ઘણી વાર ડિસ્કનેક્ટ પછી ટકી રહે છે, તેથી તે કામ કરતું લાગે છે અને પછી આગલા નેટવર્ક પર મુશ્કેલી ઊભી કરે છે. દરેક ઇન્ટરફેસ પર બોલ્ટ કરેલું જાહેર રિઝોલ્વર ખાનગી નેમસ્પેસની સમસ્યાને ઉકેલવાને બદલે છુપાવે છે. જ્યારે હેલ્પરને કદી DNS કિંમત મળી નથી, ત્યારે ગેટવે પ્રોફાઇલ જોવાનું સ્થળ છે. જ્યારે તેને એક મળી અને એડેપ્ટર હજી જૂનો સર્વર દર્શાવે છે, ત્યારે હેલ્પર કનેક્ટ દરમિયાન નિષ્ફળ ગયું છે અને ક્લાયન્ટ લોગ સામાન્ય રીતે તેને ટનલ સેટઅપની લાઇનો નજીક નોંધે છે.
સમર્થિત માર્ગે સ્થિતિ ફરી બનાવો, પછી આખું ચક્ર ચકાસો: કનેક્ટ કરો, ખાનગી FQDN ઉકેલો, સેવા ખોલો, ડિસ્કનેક્ટ કરો, અને ખાતરી કરો કે એડેપ્ટર તેના અગાઉના સર્વરો સાથે પાછું આવ્યું છે.
ખરેખર નિષ્ફળ થતી એપ્લિકેશન તપાસો
પોતાની એન્ક્રિપ્ટેડ-DNS સેટિંગ ધરાવતું બ્રાઉઝર ઉપરના બધાને અવગણે છે અને જાહેર રિઝોલ્વરથી જવાબ આપવાનું ચાલુ રાખે છે. ટનલ ઉપર આવતાં પહેલાંનો કેશ કરેલો નકારાત્મક જવાબ રાખતી એપ્લિકેશન પણ એ જ રીતે વર્તે છે. રિઝોલ્વર સરનામાં ફરી બદલતાં પહેલાં તેને એ જ મશીન પરના સાદા સિસ્ટમ પ્રશ્ન સાથે સરખાવો.
જો સિસ્ટમ પ્રશ્ન સાચો હોય અને એપ્લિકેશન ખોટી હોય, તો બાકીની ખામી તે એપ્લિકેશનની DNS ગોઠવણીમાં છે, VPN માર્ગમાં નહીં.