તમારી સ્પ્લિટ ટનલ એપ સુધી પહોંચે છે પણ તેના DNS સર્વર સુધી નહીં
સ્પ્લિટ ટનલ એપનું સબનેટ રૂટ કરી શકે છે અને તેમ છતાં તેની બાજુમાં રહેલું રિઝોલ્વર છોડી શકે છે. હોસ્ટ રૂટ ઉમેરો, પછી તપાસો કે Windows ખરેખર કયો સર્વર પસંદ કરે છે.
એપ્લિકેશનનું સબનેટ રૂટ કરવું સ્પ્લિટ ટનલનો સ્પષ્ટ ભાગ છે અને તે આખું કામ નથી. રિઝોલ્વર ઘણી વાર જે એપ્લિકેશનને સેવા આપે છે તેના કરતાં અલગ સરનામા પર બેસે છે, તેથી કાર્યકારી ટનલ પણ લુકઅપને તેની બહાર મૂકી શકે છે. જે પ્રોફાઇલ 10.80.0.0/16 વહન કરે છે અને બીજું કંઈ નહીં, તે 10.90.0.53 માટેની ક્વેરી સ્થાનિક ઇન્ટરફેસ દ્વારા મોકલે છે, જ્યાં કોઈ ખાનગી ઝોન નથી. રિઝોલ્વરનો રસ્તો ઉમેરો, પછી સમસ્યાનો બીજો અડધો ભાગ જુઓ: ક્લાયન્ટ ખરેખર કયો સર્વર પસંદ કરે છે.
દંતકથા: એક રૂટ આખી સેવાને આવરી લે છે
સ્પ્લિટ ટનલ એ કનેક્શનમાંથી પસાર થતા ગંતવ્યોની યાદી છે, સેવાનું વર્ણન નથી. એપ્લિકેશનનું સબનેટ અને રિઝોલ્વરનું સરનામું બે ગંતવ્યો છે, અને પ્રોફાઇલ એક વિના બીજું વહન કરી શકે છે. જ્યારે એવું થાય છે, ત્યારે એપ્લિકેશન સરનામા દ્વારા પહોંચી શકાય તેવી હોય છે જ્યારે તેનું નામ નિષ્ફળ જાય છે, જે રૂટિંગ ગેપ કરતાં DNS ખામી જેવું લાગે છે.
રિઝોલ્વરની આસપાસનું સબનેટ પણ આપોઆપ આવરી લેવાતું નથી. એક સરનામા માટે હોસ્ટ રૂટ તે રિઝોલ્વર માટે પૂરતો છે અને તેના પડોશીઓને ખોલતો નથી. હોસ્ટ રૂટનો અર્થ એ જ છે: રચનાથી સાંકડો, અને આગલી સેવા એ જ સબનેટમાં દેખાય ત્યારે ભૂલી જવો સહેલો.
લુકઅપ કામ કરે તે માટે ત્રણ વસ્તુઓ સાચી હોવી જોઈએ: ક્લાયન્ટ રિઝોલ્વરનું સરનામું ટનલ દ્વારા રૂટ કરે, ગેટવે તે વિનંતી સ્વીકારે અને મોકલે, અને રિઝોલ્વર જે સ્રોત મેળવે તે સ્વીકારે. જવાબ પણ સંમત માર્ગે પાછો આવવો જોઈએ. તેમાંથી કોઈ એક પણ ન હોય તો લક્ષણ સરખું જ રહે છે, તેથી ગોઠવણીને સ્પર્શ કરતાં પહેલાં સરનામાંનું કોષ્ટક લખી લેવું યોગ્ય છે.
પ્રોફાઇલે કયા સરનામાં વહન કરવા જોઈએ તે નક્કી કરો
ગંતવ્યો ક્રમમાં સૂચિબદ્ધ કરો: એપ્લિકેશન નેટવર્ક, રિઝોલ્વરનું સરનામું અને સાર્વજનિક અંતિમ બિંદુ જે ટનલને જ સમાપ્ત કરે છે. ત્રીજાને ક્યારેય ટનલમાં રૂટ કરવું ન જોઈએ, કારણ કે બહારના કનેક્શનને એવો માર્ગ જોઈએ છે જે ટનલ પહેલાં હાજર હોય.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS માટે UDP અને TCP બંને સામેલ કરો, કારણ કે અમલીકરણોએ UDP સાથે TCP પણ ટેકો આપવાની અપેક્ષા હોય છે, અને અવરોધિત TCP માર્ગ સ્વચ્છ નિષ્ફળતાને બદલે ધીમી, આંશિક નિષ્ફળતા ઉત્પન્ન કરે છે. જો ખાનગી ઝોન IPv6 દ્વારા પણ પરોવાય છે, તો સમાન હોસ્ટ અપવાદ IPv6 સરનામું અને પ્રીફિક્સ વાપરે છે અને તે અલગ એન્ટ્રી છે.
કંઈ ઉમેરતા પહેલાં પ્રોફાઇલ પહેલેથી શું આવરી લે છે તે નોંધો. નકલી રૂટ હાનિકારક નથી, પરંતુ અણધાર્યો હાલનો રૂટ તમને કહે છે કે પ્રોફાઇલ તમને મળેલા સરનામા પ્લાન કરતાં અલગ પ્લાન માટે રચાયું હતું.
કનેક્શનના માલિક દ્વારા હોસ્ટ રૂટ ઉમેરો
સ્થાનિક રીતે સંચાલિત મૂળ Windows પ્રોફાઇલ માટે, રૂટ મશીનના વૈશ્વિક રૂટિંગ કોષ્ટકને બદલે કનેક્શનનો હોય છે. પહેલાં ઉમેરાનું પૂર્વદર્શન કરો, પછી પ્રોફાઇલ જે અવકાશ વાપરે તે જ અવકાશ સાથે તેને લાગુ કરો.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
પહેલો આદેશ કંઈ સ્થાપિત કર્યા વિના ફેરફારનું પૂર્વદર્શન કરે છે, અને બીજો પ્રોફાઇલ હાલમાં જે રૂટ વહન કરે છે તેની યાદી આપે છે. Microsoft ની Add-VpnConnectionRoute ની સંદર્ભ દરેક વપરાશકર્તા અને બધા વપરાશકર્તાના અવકાશનું દસ્તાવેજીકરણ કરે છે; બધા વપરાશકર્તાની પ્રોફાઇલને પોતાનું અવકાશ પરિમાણ જોઈએ છે, અને બધા વપરાશકર્તાની પ્રોફાઇલ સામે દરેક વપરાશકર્તાનો આદેશ નિષ્ફળ જાય છે અથવા ખોટી જગ્યાએ પહોંચે છે.
જ્યારે પ્રોફાઇલ સંચાલિત હોય અથવા વેન્ડર ક્લાયન્ટમાંથી આવે, ત્યારે ફેરફાર તે માલિકનો હોય છે. કનેક્શન નીતિ પર કાયમી સિસ્ટમ રૂટ ચઢાવવું ત્યાં સુધી કામ કરે છે જ્યાં સુધી નીતિ ફરી લાગુ ન થાય અને રૂટ ન જાય, જે સામાન્ય રીતે પરીક્ષણ દરમિયાન નહીં પણ સપોર્ટ કૉલ દરમિયાન થાય છે. એ નિષ્ફળતા શાંત છે: રૂટ અદૃશ્ય થાય છે, નામ ઉકેલવાનું બંધ કરે છે, અને કોઈ બે ઘટનાઓને જોડતું નથી. ફેરફારને માલિકના પોતાના રેકોર્ડમાં મૂકો જેથી આગળનું પુનઃલાગુ તેને ભૂંસવાને બદલે વહન કરે.
લાગુ કર્યા પછી રૂટ અમલમાં આવ્યો છે એમ માનવાને બદલે પ્રોફાઇલ ફરી જોડો. જીવંત કનેક્શન પરના રૂટ ફેરફારો હંમેશા ઉપાડાતા નથી, અને ફરી જોડવાથી તમારા વપરાશકર્તાઓ ખરેખર જે સ્થિતિમાં હશે તે પણ પુનઃઉત્પન્ન થાય છે.
ક્લાયન્ટે ખરેખર કયું રિઝોલ્વર વાપર્યું તે તપાસો
રૂટ રિઝોલ્વરને સંબોધિત પેકેટોને નિયંત્રિત કરે છે. કયા નામ ત્યાં મોકલવા જોઈએ તે તે નક્કી કરતું નથી, અને એ પસંદગી અલગ પદ્ધતિ છે. Windows માં અસરકારક નામસ્થાન નિયમો દરેક ડોમેન માટે રિઝોલ્વર પસંદ કરી શકે છે, જ્યારે પ્રોફાઇલની DNS સેટિંગ્સ ડિફૉલ્ટ પૂરો પાડે છે. એ બે સ્તરો કોઈ ભૂલ ઉત્પન્ન કર્યા વિના અસહમત થઈ શકે છે, તેથી સીધી ક્વેરી ફક્ત અડધો પુરાવો છે.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
પહેલો આદેશ અમલમાં રહેલી નામસ્થાન નીતિ છાપે છે, અને બીજો ખાનગી રિઝોલ્વરને સીધું એપ્લિકેશનનું નામ પૂછે છે. સીધો જવાબ સાબિત કરે છે કે માર્ગ અને રિઝોલ્વર કામ કરે છે; તે સાબિત કરતું નથી કે એપ્લિકેશનનું પોતાનું લુકઅપ તે સર્વર પસંદ કર્યું હતું. તેની સરખામણી એ જ નામના સામાન્ય લુકઅપ સાથે અને એપ્લિકેશનને મળતા જવાબ સાથે કરો.
કેશ અને બ્રાઉઝર-સ્તરના સુરક્ષિત DNS ધ્યાનમાં લો, જે વપરાશકર્તાએ લખેલા નામો માટે સિસ્ટમ રિઝોલ્વરને સંપૂર્ણપણે છોડી શકે છે. સર્ચ સફિક્સ બીજું ભ્રામક સંકેત છે: તે ટૂંકા નામને સંપૂર્ણ લાયક નામમાં વિસ્તારે છે અને કયું સર્વર જવાબ આપે છે તેની સાથે કોઈ સંબંધ નથી.
અંતે ફરી જોડાઈને સામાન્ય લુકઅપનું પુનરાવર્તન કરો, પછી ખાતરી કરો કે સામાન્ય બ્રાઉઝિંગ હજી પણ તેની મંજૂર નીતિને અનુસરે છે. અસંબંધિત નામ ઉકેલાય તે માટે ખાનગી રિઝોલ્વરને સાર્વજનિક સાથે બદલવું સુધારો નથી, અને તે ખાનગી ક્વેરીઓને શાંતિથી એવી જગ્યાએ ખસેડે છે જ્યાં તેમણે ક્યારેય ન જવું હતું.