VPN એ DNS હાથમાં લીધું અને સ્થાનિક નામો તોડ્યાં: સૂચિ સુધારો

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

સૂચિ જાણી જોઈને સુધારો, પછી પુશ મિકેનિઝમ સાથે અલગથી વ્યવહાર કરો. રૂટ્સ ત્રીજો વિષય છે અને તે અહીં સુધારાતો નથી.

એપ્લિકેશનો ખરેખર કઈ સૂચિ વાપરે છે

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

પ્રશ્ન એ છે કે કયા સર્વરો આગળ આવ્યા અને તેઓ સ્થિર એન્ટ્રી તરીકે આવ્યા કે DHCP લીઝ તરીકે. બંને હકીકતો નક્કી કરે છે કે તમને કયો સુધારો ઉપલબ્ધ છે.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

ટનલ એડેપ્ટર અને ભૌતિક એડેપ્ટર માટે આઉટપુટ વાંચો, અને દરેક પરનું દરેક સરનામું નોંધો. સ્થિર એન્ટ્રી નીતિ અથવા સ્ક્રિપ્ટ દ્વારા દૂર કરી શકાય છે; DHCP દ્વારા મળેલી એન્ટ્રી લીઝ સાથે બંધાયેલી છે અને પાછી આવશે, જે તમારે પસંદ કરવાનો સુધારો બદલે છે. દૂરના નેટવર્કનાં નામો જાહેર કરેલા રિઝોલ્વરથી રિઝોલ્વ થાય છે, સ્થાનિક LANનાં નામો ભૌતિક એડેપ્ટરથી, અને ક્વેરી જે સૂચિ પહેલી જોવાય છે તેના તરફ જાય છે.

ધકેલાયેલા સર્વરો દૂર કરો, અથવા તેમને નીચે ગોઠવો

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

ઇન્ડેક્સ 1 પહેલો જોવાય છે, તેથી ધકેલાયેલા સરનામાં ઉપલબ્ધ રહે છે પણ દરેક ક્વેરીનો ડિફોલ્ટ જવાબ બનવાનું બંધ કરે છે. validate=no ફ્લેગ એક પહોંચની કસોટી છોડે છે જે ઘણી વાર નિષ્ફળ જાય છે જ્યારે ટનલ હજી સ્થિર થઈ રહી હોય, તેથી એક્ઝિટ કોડ પર ભરોસો કરવાને બદલે show આદેશથી પરિણામની પુષ્ટિ કરો.

આના પર આધાર રાખતા પહેલાં બે મર્યાદા જાણવા જેવી છે. Windows એ સર્વરો કાઢશે નહીં જે DHCP દ્વારા netsh મારફતે આવ્યા છે, અને તે મૂલ્યો ઇન્ટરફેસની રજિસ્ટ્રી કી હેઠળ DhcpNameServer તરીકે ટકી રહે છે, તેથી રજિસ્ટ્રી સંપાદન એ છેલ્લો ઉપાય છે જે આગલી લીઝ પછી ફરી તપાસવો પડે. એડેપ્ટર બાઇન્ડિંગ ક્રમ પણ વિશ્વસનીય રેન્કિંગ મિકેનિઝમ નથી, કારણ કે VPN ક્લાયન્ટ પોતાની એન્ટ્રી સૂચિની ટોચ પર દાખલ કરી શકે છે.

પુશ ક્યાં ફિલ્ટર કરી શકાય

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

pull-filter ignore "dhcp-option DNS "

અંતની જગ્યા મેળ સાથે સંબંધિત છે અને ફિલ્ટર સર્વર સરનામાને બદલે વિકલ્પનું નામ લે છે. જો પ્રોફાઇલમાં block-outside-dns નિર્દેશ પણ હોય, તો તેને દૂર કરવાથી લીક સુરક્ષા બદલાય છે, નામ રિઝોલ્યુશન નહીં, તેથી બે સંપાદનોને જોડવાને બદલે તેને અલગથી નક્કી કરો.

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

સુધારાને ફરી કનેક્ટ થવા ટકી રહેવા દો

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

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

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

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