Azure P2S: VNet ફેરફાર પછી એક Windows ક્લાયન્ટની રૂટ ખોવાઈ
જ્યારે એક Windows P2S ક્લાયન્ટ નવી VNet સુધી પહોંચી શકતું નથી, ત્યારે તેની પસંદ કરેલી રૂટની સરખામણી કરો અને TTL સેટિંગ્સને સ્પર્શ કરતા પહેલા ગેટવે પેકેજ ફરી બનાવો.
બે લેપટોપ એક જ Azure point-to-site ગેટવે પર પ્રમાણિત થાય છે, અને ફક્ત એક જ નવા જોડાયેલા VNet સુધી પહોંચે છે. બંને Connected દર્શાવે છે, તેથી પ્રમાણીકરણ એ ભેદ નથી; ભેદ એ છે કે તેઓ કઈ ગંતવ્ય રૂટ રાખે છે. જે ક્લાયન્ટ નિષ્ફળ જાય તેનાથી શરૂ કરો, એક ગંતવ્યની સરખામણી કરો, અને પછી જ નક્કી કરો કે ખાલીપો ગેટવે પેકેજનો છે કે સ્થાનિક રૂટ ટેબલનો.
ગેટવેથી નહીં, જે ક્લાયન્ટ નિષ્ફળ જાય તેનાથી શરૂ કરો
લેપટોપને દોષ આપતા પહેલા ટોપોલોજીની પુષ્ટિ કરો. કઈ VNet ગેટવેની VNet સાથે જોડાયેલી છે અને નવું નેટવર્ક સીધું પિઅર થયેલું છે કે અલગ site-to-site ટનલ દ્વારા પહોંચે છે તે તપાસો. જો નવી VNet ગેટવેની VNet સાથે જ જોડાયેલી ન હોય, તો કોઈ પણ ક્લાયન્ટ પેકેજ ત્યાં રૂટ કરી શકતું નથી, અને જે લેપટોપ કામ કરે છે તે જ સમજાવવાની જરૂરી અસામાન્યતા છે. જવાબ લખી રાખો, કારણ કે તે નક્કી કરે છે કે તમે ક્લાયન્ટ ડિબગ કરો છો કે ગેટવે.
ટોપોલોજી સાચી હોય ત્યારે બે લેપટોપ સાથે રાખો. એક જ ગેટવે, એક જ સરનામા પૂલ, એક જ પ્રોટોકોલ અને એક જ ક્લાયન્ટ બિલ્ડ એ તમે ઈચ્છો છો તે સરખામણી છે; બાકીનું બધું બીજું ચલ છે જે પછી દૂર કરવું પડશે.
route print વડે એક ગંતવ્યની સરખામણી કરો
મંજૂર કરેલ સંસાધન IP પસંદ કરો અને બંને લેપટોપની બે વાર સરખામણી કરો: ડિસ્કનેક્ટ સ્થિતિમાં, પછી કનેક્ટ સ્થિતિમાં. Windows માં route print -4 IPv4 રૂટને ગંતવ્ય પ્રીફિક્સ, ઇન્ટરફેસ, આગળના હોપ અને મેટ્રિક સાથે યાદી કરે છે. VPN શબ્દ ધરાવતી એન્ટ્રી ગણવાને બદલે તે ગંતવ્ય માટે ખરેખર જીતશે તે પંક્તિ નોંધો.
પસંદગી પહેલા સૌથી લાંબા પ્રીફિક્સ પ્રમાણે, પછી મેટ્રિક પ્રમાણે થાય છે, તેથી વધુ ચોક્કસ સ્થાનિક રૂટ ખોટી દેખાયા વિના ટનલ રૂટને હરાવી શકે છે. જો ઈચ્છિત ગંતવ્ય 10.24.0.0/16 ની અંદર હોય, તો સ્વસ્થ ક્લાયન્ટ VPN ઇન્ટરફેસ પર મેળ ખાતી રૂટ દર્શાવે છે, જ્યારે નિષ્ફળ ક્લાયન્ટ એ જ સરનામું પોતાના ડિફોલ્ટ ગેટવે પર મોકલે છે.
સંઘર્ષકારી સ્થાનિક પ્રીફિક્સ એ જ લક્ષણ પેદા કરી શકે છે. કંઈ પણ ઉમેરતા પહેલા નક્કી કરો કે તમારી પાસે બેમાંથી કયો કિસ્સો છે: બિલકુલ ટનલ રૂટ નથી, કે ટનલ રૂટ વધુ ચોક્કસ રૂટ સામે હારે છે.
TTL expired એ રૂટ વિતરણનો દોષ નથી
TTL expired in transit પરત આપતું ping કહે છે કે પેકેટે તેનો હોપ ક્વોટા વાપરી નાખ્યો, જેનો અર્થ સામાન્ય રીતે ફોરવર્ડિંગ લૂપ છે, તૂટેલો VPN ડ્રાઇવર નહીં. Windows ping 255 સુધીનું TTL સ્વીકારે છે, અને મૂલ્ય વધારવાથી લૂપ સુધરતું નથી; તે ફક્ત એ જ ભૂલને મોડી કરે છે. સંદેશને માર્ગનું લક્ષણ ગણો, રૂટ વિતરણ વિશેનો પુરાવો નહીં.
માર્ગ ક્યાં પુનરાવર્તન થાય છે તે જોવા tracert -4 10.24.1.10 વાપરો. જો એ જ બે હોપ વારંવાર દેખાય, તો એવી રૂટ શોધો જે ટનલ તરફનો ટ્રાફિક ફરી ટનલમાં અથવા તેને પાછું મોકલતા સ્થાનિક રાઉટરમાં મોકલે છે.
જે ગેટવે તેનો માલિક છે ત્યાં જ પેકેજ ફરી બનાવો
Microsoft દસ્તાવેજ કરે છે કે સંબંધિત ટોપોલોજી ફેરફારો પછી Windows ક્લાયન્ટ પેકેજ ફરી ડાઉનલોડ અને ઇન્સ્ટોલ કરવા પડે. આ પ્રોફાઇલ સેવા આપતા Azure ગેટવેથી વર્તમાન પેકેજ મેળવો, પછી તે ક્લાયન્ટ માટે સમર્થિત પ્રક્રિયા સાથે લાગુ કરો. અસંબંધિત VPN એપ્લિકેશનની એક્ઝિક્યુટેબલ ફાઇલ બદલવી એ ગેટવે-વિશિષ્ટ સેટિંગ્સ ફરી બનાવવાની સમાન ક્રિયા નથી. પેકેજ ફરી ડાઉનલોડ કરવું સસ્તું છે; સ્થાનિક રૂટ વિશે અનુમાન કરવું નહીં.
ફરી કનેક્ટ થઈને મૂળ ગંતવ્યની રૂટ ફરી વાંચો. ફેરફારના રેકોર્ડ સાથે પહેલા અને પછીની પંક્તિઓ રાખો, જેથી પરિણામ મેં ક્લાયન્ટ ફરી ઇન્સ્ટોલ કર્યું તેના કરતાં વધુ સચોટ હોય.
Azure P2S રૂટિંગ પરિસ્થિતિઓ સીધા પિઅર થયેલી VNetને બીજી ટનલ દ્વારા પહોંચાતા નેટવર્કથી અલગ કરે છે, અને નવું પેકેજ પિઅરિંગને ટ્રાન્ઝિટિવ બનાવી શકતું નથી. કેટલીક Windows site-to-site કે BGP પરિસ્થિતિઓને હાથે રૂપરેખાંકિત રિમોટ રૂટ પણ જોઈએ, તેથી પેકેજ રિફ્રેશ એ સાર્વત્રિક રૂટ વિતરણ પદ્ધતિ નથી.
કામચલાઉ રૂટને કામચલાઉ રાખો
મેન્યુઅલ રૂટ ગુમ થયેલી ક્લાયન્ટ રૂટને અલગ કરી શકે છે, પણ તેને વાસ્તવિક ડિઝાઇનમાંથી બનાવો: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, પર્સિસ્ટન્ટ ફ્લેગ વગર, જેથી રીબૂટ પર તે અદૃશ્ય થાય. ઇન્ટરફેસ ઇન્ડેક્સ અને આગળનો હોપ કનેક્ટેડ VPN એડેપ્ટરમાંથી પસંદ કરો, અનુમાનમાંથી નહીં.
પ્રયોગાત્મક રૂટને કાયમી હરીફ માલિક તરીકે છોડશો નહીં. ભવિષ્યના પ્રોફાઇલ અપડેટ સમાન પ્રીફિક્સ અલગ મેટ્રિક સાથે ઉમેરી શકે છે, અને પછી મેન્યુઅલ એન્ટ્રી શાંતિથી નક્કી કરે છે કે કયો માર્ગ જીતશે. દૂર કરવાનું પગલું ફેરફારમાં નોંધો.
સાચી રૂટ સક્રિય થાય પછી ping નહીં, લક્ષ્ય એપ્લિકેશનની કસોટી કરો. જો પેકેટ Azure સુધી પહોંચે પણ સેવા હજી નિષ્ફળ જાય, તો નેટવર્ક સિક્યુરિટી ગ્રુપ અને પરત માર્ગ તપાસો, કારણ કે તે લેપટોપે પ્રીફિક્સ શીખ્યું છે કે નહીં તેનાથી અલગ છે.