PowerShell વડે Windows VPN એડેપ્ટર પર DNS સેટ કરો, પછી ચકાસો

Windows VPN કનેક્શન તમે સેટિંગ્સમાં સંપાદિત કરો છો તે પ્રોફાઇલમાં DNS સર્વર સંગ્રહિત કરતું નથી. જ્યારે ટનલ ઉપર આવે છે, ત્યારે ક્લાઇન્ટ ગેટવે સાથે IP રૂપરેખાંકનની વાટાઘાટ કરે છે, ગેટવે રિઝોલ્વરની યાદી મોકલે છે, અને Windows તેને ટનલ એડેપ્ટર પર લાગુ કરે છે. તે એડેપ્ટર તમારા Wi-Fi કે Ethernet થી અલગ ઇન્ટરફેસ છે, અને યાદી ઇન્ટરફેસની છે, પ્રોફાઇલની નહીં. જ્યારે તમે જાણો કે કઈ વસ્તુ આ મૂલ્ય ધરાવે છે, ત્યારે PowerShell માં તેને ઓવરરાઇડ કરવું એક જ આદેશ છે; ઓવરરાઇડ ફરી કનેક્ટ થવા પર ટકે તે કરવું એ ભાગ છે જેને નિર્ણયની જરૂર છે.

કઈ વસ્તુ સરનામું ધરાવે છે

RAS કનેક્શન સફળ થાય ત્યારે ટનલ એડેપ્ટર બનાવે છે અને કનેક્શન તૂટે ત્યારે તેને દૂર કરે છે. ipconfig /all માં તમે જે DNS સર્વર જુઓ છો તે તે રૂપરેખાંકન વિનિમય દરમિયાન, IPv4 અને IPv6 સરનામાં તથા રૂટની બાજુમાં આવે છે. કારણ કે મૂલ્ય ઇન્ટરફેસ સાથે જોડાયેલું છે, Set-DnsClientServerAddress એવી વસ્તુમાં લખે છે જે કનેક્શન હોય ત્યાં સુધી જ અસ્તિત્વમાં હોય છે.

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

DNS ને સ્પર્શ કરતા પહેલાં એલિયસ શોધો

પ્રોફાઇલનું નામ અને ઇન્ટરફેસ એલિયસ સામાન્ય રીતે એક જ શબ્દમાળા હોય છે, પણ તે એક જ વસ્તુ નથી. Get-VpnConnection પ્રોફાઇલની યાદી બતાવે છે; Get-NetAdapter Windows પાસે ખરેખર જે ઇન્ટરફેસ છે તેની યાદી બતાવે છે. DNS cmdlet ને બીજું જોઈએ છે, અને બંને લોકો ધારે તેના કરતાં વધુ વાર અલગ પડે છે, ખાસ કરીને જ્યારે ક્લાઇન્ટ એડેપ્ટરના નામે "(RAS)" જેવું વર્ણન ઉમેરે છે.

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

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

એક વાર કનેક્ટ થાઓ, પછી કોઈપણ DNS આદેશ લખતા પહેલાં ખરો એલિયસ વાંચો:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

ઓવરરાઇડ યોગ્ય ક્રમમાં લાગુ કરો

ક્રમ સિન્ટેક્સ કરતાં વધુ મહત્ત્વનો છે. એડેપ્ટર ઉપર હોવું જોઈએ, એલિયસ ઉકેલાવું જોઈએ, અને ખાતાને ઇન્ટરફેસ સેટિંગ્સ બદલવાની પરવાનગી હોવી જોઈએ. દરેક વપરાશકર્તાનું કનેક્શન સામાન્ય રીતે લોગ ઇન થયેલા વપરાશકર્તા તરફથી ફેરફાર સ્વીકારે છે; -AllUserConnection સાથે બનાવેલું બધા વપરાશકર્તાનું કનેક્શન સામાન્ય રીતે ઉન્નત શેલ માંગે છે.

cmdlet પોતે એક જ લીટી છે, જે Microsoft ના Set-DnsClientServerAddress સંદર્ભ માં દસ્તાવેજિત છે:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

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

ફરી કનેક્ટ થવાથી ફેરફાર કેમ રદ થઈ શકે

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

ત્રણ ટકાઉ જવાબ છે, અને તેમને એકઠા કરવાથી પોતાની ભૂલો થાય છે. કનેક્શન-વિશિષ્ટ DNS પ્રત્યય અને NRPT નિયમ ફક્ત આંતરિક નામસ્થાનને આંતરિક રિઝોલ્વર પર મોકલે છે અને જાહેર નામોને શાંત રહેવા દે છે. VPN કનેક્શન પર લાગુ કરેલી Group Policy કે MDM સેટિંગ કોઈ સ્ક્રિપ્ટ વિના કનેક્શન સમયે DNS સેટ કરે છે. કનેક્શન ઘટનાને પ્રતિસાદ આપીને cmdlet ફરી ચલાવતું નિર્ધારિત કાર્ય કઠોર વિકલ્પ છે, પણ તે કામ કરે છે અને લોગ છોડે છે. DNS માટે એક જ માલિક પસંદ કરો અને લખો કે કયો છે.

એક લેબલવાળા આંતરિક નામોને પણ પ્રત્યય શોધ યાદીની જરૂર છે. Set-DnsClientGlobalSetting -SuffixSearchList આખા મશીન પર લાગુ છે, તેથી તે કમ્પ્યુટર પરના દરેક એડેપ્ટર માટે, Ethernet સહિત, ઉકેલ બદલે છે. ઇમેજમાં જાય તે પહેલાં પ્રયોગશાળાના મશીન પર તેને ચકાસો.

ફક્ત સેટિંગ નહીં, ઉકેલ ચકાસો

એડેપ્ટર પર સૂચિબદ્ધ રિઝોલ્વર ફક્ત એ સાબિત કરે છે કે મૂલ્ય લખાયું છે. ઇચ્છિત સર્વરને સીધું પૂછો, પછી સામાન્ય માર્ગે પૂછો:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

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

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