Windows VPN DNS લીક: મેટ્રિક રૂટને કેમ હરાવે છે

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

એક લીક માટે બે સમજૂતી

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

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

મેટ્રિક અને રિઝોલ્વર સાથે સરખાવો

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

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

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

કોઈ પણ રિઝોલ્વર ગોઠવેલું ન હોય તેવું ટનલ એડેપ્ટર એટલું જ સામાન્ય સ્વરૂપ છે. ક્લાયન્ટ DNS દબાણ કર્યા વિના ઇન્ટરફેસ ઉપર લાવે છે, તેથી ક્રમનો પ્રશ્ન જ ઊભો થતો નથી.

ટનલને ઉપર લાવો અને ફરી તપાસો

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

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

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

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

ફરી જોડાણમાં ટકી રહે તેમ બનાવો

દરેક જોડાણ પર ફરી બનતા એડેપ્ટર પરનું જાતે આપેલું મેટ્રિક એ લુપ્ત થતી સેટિંગ છે. જો ક્લાયન્ટ ઇન્ટરફેસ ફરી બનાવે, તો આ ઓવરરાઇડ માટે જોડાણ પછીની સ્ક્રિપ્ટ, નીતિ કે એવી ક્લાયન્ટ ગોઠવણી જરૂરી છે જે જોડાણ દરમિયાન DNS ધરાવે.

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