Azure VPN પ્રીફિક્સ ઉમેરવાથી કનેક્શન કેમ તૂટે છે

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

ત્રણ ઑબ્જેક્ટ, જેમાંથી એક પ્રીફિક્સ રાખે છે

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

એક ત્રીજી આરક્ષણ છે જે ધ્યાનમાં રાખવી જોઈએ. GatewaySubnet મેનેજ થયેલા ગેટવે ઇન્સ્ટન્સ હોસ્ટ કરે છે, બરાબર એ જ નામ ધરાવવું જોઈએ, અને બિન-Basic SKU માટે તે ઓછામાં ઓછું /27 હોવાની અપેક્ષા છે.

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

કનેક્શન જ કેમ દૂર કરવામાં આવે છે

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

તે કાઢી નાખવું એ જ વિક્ષેપ છે, તેથી તેને ઝડપી સંપાદનને બદલે શરૂઆત અને અપેક્ષિત અંત સાથેનો આયોજિત ફેરફાર ગણો. PowerShellમાં ક્રમ ટૂંકો છે: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, પછી Set-AzLocalNetworkGateway નવા -AddressPrefix એરે સાથે, પછી New-AzVirtualNetworkGatewayConnection તે જ -SharedKey અને તે જ ગેટવે સાથે. કીનો ફરી ઉપયોગ મહત્વપૂર્ણ છે, કારણ કે દૂરની બાજુ ફરી રૂપરેખાંકિત થતી નથી અને નવી કીનો અર્થ દૂરના ઉપકરણના માલિક સાથે સંકલન છે. જો બીજી ટીમ તે ઉપકરણ ચલાવે છે, તો કંઈ પણ દૂર કરતા પહેલા તેમની સાથે સમયગાળો નક્કી કરો.

ગેટવે પોતે ક્યારે ફરી બાંધવો પડે

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

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

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

સ્થિતિ વાંચો, પોર્ટલનું બેજ નહીં

પોર્ટલના બેજને બદલે સંસાધનમાંથી સ્થિતિ વાંચો. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 પરત આપે છે ConnectionStatus ઇનગ્રેસ અને એગ્રેસ બાઇટ કાઉન્ટર સાથે, અને કાઉન્ટર જ જોડાયેલું પણ કંઈ ન વહન કરતું ટનલ અને ક્યારેય સ્થપાયું ન હોય તેવા ટનલને અલગ પાડે છે.

જે કાઉન્ટર ટ્રાન્સફરની વચ્ચે વધવાનું બંધ કરે છે, તે પ્રમાણીકરણને બદલે માર્ગ તરફ ઇશારો કરે છે. જે કાઉન્ટર બિલકુલ ખસતું નથી તે પ્રીફિક્સ સેટ કે વહેંચાયેલી કી તરફ ઇશારો કરે છે.

ટાઇમર VPNને ખોટી રીતે આરોપાયેલા ડિસ્કનેક્શનના એક વર્ગને સમજાવે છે. Azureનું લોડ બેલેન્સર તેના રૂપરેખાંકિત સમયગાળા પછી નિષ્ક્રિય ફ્લો બંધ કરે છે, આ નોંધ લખાઈ ત્યારે મૂળભૂત રીતે ચાર મિનિટ અને ઉપર તરફ ગોઠવી શકાય છે, તેથી keepalive વગરની VM પરનો OpenVPN સર્વર દર થોડી મિનિટે પડી શકે છે જ્યારે બાકીનું બધું સ્વસ્થ દેખાય છે. પ્લેટફોર્મ જે ગેટવેને ચક્રીય રીતે ફરી ચાલુ કરે છે તે પણ VNet કનેક્શનને Web App સાથે અવરોધી શકે છે, અને તે નિષ્ફળતા ક્લાયન્ટ રૂપરેખામાં નહીં, પ્લેટફોર્મની બાજુએ છે. સંકેત એ છે કે ડિસ્કનેક્શન નિશ્ચિત અંતરાલને અનુસરે છે કે તમે કરેલા ફેરફારને.

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

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