એક નવું spoke VNet દેખાય છે, હબ પાસે પહેલેથી જ કાર્યરત site-to-site ગેટવે છે, અને સ્વાભાવિક પ્રશ્ન એ છે કે શું તમારે બીજા ગેટવે માટે ચૂકવવું પડશે. સામાન્ય રીતે નહીં: ગેટવે ટ્રાન્ઝિટ spoke ને પીઅરિંગ દ્વારા હબના ગેટવેનો ઉપયોગ કરવા દે છે. ત્રણ શરતો નક્કી કરે છે કે તે કામ કરશે કે નહીં, અને તેમાંથી એક પણ પીઅરિંગ સ્થિતિ બેજ પરથી દેખાતી નથી. પીઅરિંગ કનેક્ટિવિટી અને બીજાના ગેટવેનો ઉપયોગ કરવાની પરવાનગી અલગ સેટિંગ્સ છે, તેથી એકબીજાને ping કરી શકતા બે VM VPN પાથ વિશે કંઈ સાબિત કરતા નથી.

પ્રથમ શરત: ગેટવે, અને spoke માં તેની ગેરહાજરી

Azure Basic સિવાયના VPN Gateway SKU માટે ગેટવે ટ્રાન્ઝિટને સમર્થન આપે છે, અને પ્રાદેશિક અને વૈશ્વિક પીઅરિંગ બંને તેને વહન કરી શકે છે. spoke એવા ગેટવેનો ઉપયોગ કરે છે જે તેનો પોતાનો નથી, તેથી તેનો પોતાનો હોઈ શકતો નથી: જો spoke માં પહેલેથી જ ગેટવે હોય, અથવા રિમોટ ગેટવે વિકલ્પ પહેલેથી પસંદ થયેલો હોય, તો તમે ઈચ્છો છો તે ટ્રાન્ઝિટ સેટિંગ અનુપલબ્ધ અથવા બિનઅસરકારક રહેશે. કંઈપણ ડિબગ કરવા પહેલાં તે તપાસો, કારણ કે નિષ્ક્રિય ચેકબોક્સ એ લક્ષણ છે, ખામી નહીં. પહેલા SKU અને હાલનું ગેટવે વાંચો, પછી પીઅરિંગ સેટિંગ્સ જુઓ.

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

બીજી શરત: દરેક પીઅરિંગ દિશામાં એક સેટિંગ

પીઅરિંગ બે ઑબ્જેક્ટ છે, દરેક VNet પર એક, અને ટ્રાન્ઝિટ સેટિંગ્સ તે જોડીની અલગ બાજુઓ પર રહે છે. હબનું spoke તરફનું પીઅરિંગ હબ ગેટવેને spoke ની સેવા કરવાની પરવાનગી આપવી જોઈએ; spoke નું હબ તરફનું પીઅરિંગ હબના ગેટવેને સ્વીકારવું જોઈએ. Microsoft ની ગેટવે-ટ્રાન્ઝિટ માર્ગદર્શિકા દિશા પ્રમાણે તેમને નામ આપે છે, અને તેમને સાચા રાખવાનો આ એકમાત્ર રસ્તો છે:

Peering directionWhat to enable
Hub → spokeAllow gateway transit on the hub's peering
Spoke → hubUse remote gateways on the spoke's peering

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

ત્રીજી શરત: સરનામાની જગ્યા અને પરવાનગીની સીમાઓ

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

ફેરફાર પહેલાં શ્રેણીઓ અને માલિકો લખો. બંનેમાંથી કોઈપણમાં અનુમાન કરવાથી એવું પીઅરિંગ બને છે જે જોડાય છે અને કંઈપણ રૂટ કરતું નથી.

પીઅરિંગ સ્થિતિથી નહીં, અસરકારક રૂટથી ચકાસો

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

spoke વર્કલોડમાંથી એક સેવાનું પરીક્ષણ કરો અને જવાબને અનુસરો. VPN ગેટવે અથવા હબ VM થી પરીક્ષણ અલગ સ્રોત પ્રીફિક્સ અને અલગ પાથનો ઉપયોગ કરે છે.

જો ટોપોલોજી point-to-site ક્લાયન્ટ્સને પણ સેવા આપે છે, તો તેમના સ્થાપિત રૂટ અલગથી ચકાસો. ટોપોલોજી ફેરફાર પછી Windows ક્લાયન્ટ પેકેજને ફરીથી જનરેટ કરવાની જરૂર પડી શકે છે, અને તે ગેટવે શેરિંગ નિષ્ફળ ગયું હોવાનો પુરાવો નહીં, પરંતુ ક્લાયન્ટ રૂટિંગનું કાર્ય છે.

ગેટવે શેર કરવાથી શું મળતું નથી

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

પીઅરિંગ પણ લોકો જેમ આશા રાખે છે તેમ પારગમ્ય નથી. બીજું spoke અથવા ખાનગી એન્ડપોઇન્ટ ઉમેરવાથી તેની પોતાની રૂટિંગ અને ઍક્સેસ આવશ્યકતાઓ આવે છે જે હાલની ટ્રાન્ઝિટ સેટિંગ આવરી લેતી નથી.

સંબંધિત લેખો