બે શાખાઓ વચ્ચેનો ટ્રાફિક Azure VPN ગેટવે દ્વારા રૂટ કરો
એક Azure VPN ગેટવે પરનાં બે સાઇટ-ટુ-સાઇટ કનેક્શન શાખાઓનો ટ્રાફિક પસાર કરી શકે છે, પણ ફક્ત ત્યારે જ જ્યારે બંને છેડા પ્રીફિક્સ શીખે અને LAN રિટર્ન પાથ અસ્તિત્વમાં હોય.
બે શાખાઓ તેમની વચ્ચે કોઈ સીધા ટનલ વિના Azure VPN ગેટવે દ્વારા ટ્રાફિકની આપલે કરી શકે છે. દરેક શાખા એ જ ગેટવે સાથે સાઇટ-ટુ-સાઇટ કનેક્શન ખોલે છે, અને ગેટવે શીખેલા પ્રીફિક્સને બે કનેક્શન વચ્ચે પસાર કરે છે. આ કામ કરે તે બીજી ટનલ નથી, પણ રૂટ વિનિમય છે: શાખા Aએ શાખા Bનું પ્રીફિક્સ શીખવું પડે, અને Bએ Aનું. નીચેની તપાસો ક્રમમાં કરો અને પ્રથમ નિષ્ફળ થતી તપાસ પર થોભો, કારણ કે દરેક પછીનું પગલું તેના પર આધાર રાખે છે.
કંઈપણ ગોઠવતા પહેલાં પૂર્વશરતો
ચાર શરતો નક્કી કરે છે કે આ ડિઝાઇન બિલકુલ કામ કરી શકે છે કે નહીં. ગેટવે રૂટ-આધારિત હોવું જોઈએ અને એવા SKU પર હોવું જોઈએ જે BGPને સપોર્ટ કરે, બંને કનેક્શન પર BGP સક્રિય હોવું જોઈએ, શાખાઓના સરનામા સ્થળો ઓવરલેપ ન થવા જોઈએ, અને કોઈપણ બાજુ પોતાનું વાસ્તવિક પ્રીફિક્સ છુપાવવા NAT પર આધાર રાખી ન શકે.
ASNનું ઇરાદાપૂર્વક આયોજન કરો. Azureનું દસ્તાવેજીકૃત ડિફોલ્ટ 65515 છે, અને દરેક શાખા રાઉટરને પોતાનું ખાનગી ASN જોઈએ જે ગેટવે કે બીજી શાખા સાથે અથડાય નહીં. હાલના ગેટવે કન્ફિગરેશનની તપાસ કર્યા વિના ડિફોલ્ટનો ફરી ઉપયોગ કરવો એ જ રીતે છે જે રીતે પછીથી AS પાથ નકારવામાં આવે છે.
એ પણ ખાતરી કરો કે તમે VNet પિયરિંગ વર્તનની અપેક્ષા રાખતા નથી. ગેટવે તમે ગોઠવેલા બે કનેક્શન વચ્ચે રૂટની આપલે કરે છે; તે મનસ્વી પિયરિંગને ટ્રાન્ઝિટિવ બનાવતું નથી. જો ત્રીજા નેટવર્કે બંને શાખાઓ સુધી પહોંચવું હોય, તો તેને પોતાનું કનેક્શન કે પોતાનો રૂટ પાથ જોઈએ, ગેટવે ટ્રાફિક વહેંચશે એવી ધારણા નહીં. પ્રથમ ફેરફાર વિન્ડો પહેલાં એ સીમા લખી રાખો, કારણ કે પછીથી સાઇટ ઉમેરાય ત્યારે લોકો એ જ ડિઝાઇન નિર્ણય પર પાછા ફરે છે.
આ ક્રમમાં ગોઠવો
દરેક પગલાનું અવલોકનપાત્ર પરિણામ છે, તેથી તે દેખાય ત્યાં સુધી આગળ ન વધો.
- વર્ચ્યુઅલ નેટવર્ક ગેટવે પર BGP સક્રિય કરો અને તેનું ASN અને પિયર સરનામું નોંધો.
- દરેક શાખા માટે એ શાખાના વાસ્તવિક સરનામા સ્થળ, તેના ASN અને તેના BGP પિયર સરનામા સાથે સ્થાનિક નેટવર્ક ગેટવે બનાવો.
- દરેક સાઇટ-ટુ-સાઇટ કનેક્શન બનાવો અને કનેક્શન પર જ BGP સક્રિય કરો.
- શાખા રાઉટરને Azureએ ફાળવેલા ગેટવે સરનામા સાથે પિયર કરવા ગોઠવો, ધારણા પર ગેટવેના જાહેર IKE એન્ડપોઇન્ટ સાથે નહીં.
ચોથું પગલું એ છે જ્યાં મોટાભાગના પ્રયાસો અટકે છે. Azure જે BGP પિયર સરનામું જણાવે છે તે શાખા રાઉટરે પડોશી તરીકે વાપરવાનું હોય છે, અને તે હંમેશા એ સરનામું નથી હોતું જેની લોકો ટનલ ડાયાગ્રામ પરથી અપેક્ષા રાખે છે.
શાખાનું પ્રીફિક્સ જાહેર કરો, ઉદાહરણ તરીકે A તરફથી 10.10.0.0/16 અને B તરફથી 10.20.0.0/16. ખૂટતા ચોક્કસ નેટવર્કને ઢાંકવા માટે ડિફોલ્ટ રૂટ કે પહોળું એગ્રિગેટ જાહેર ન કરો; અંતર પછીથી શાંત કાળા છિદ્ર તરીકે પાછું આવે છે.
બંને છેડે રૂટ વિનિમય ચકાસો
કનેક્શન સ્થિતિ એ તપાસ નથી. બંને કનેક્શન પર IPsec ચાલુ હોઈ શકે જ્યારે તેમની વચ્ચે કોઈ પ્રીફિક્સ ન પસાર થાય. ગેટવેના BGP પિયર અને તેના શીખેલા રૂટ વાંચો, પછી ખાતરી કરો કે બીજી શાખા તરફનો રૂટ ઉપયોગી માર્ગ તરીકે દેખાય છે.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP ટેબલમાં હાજર પ્રીફિક્સ હજી પણ સ્ટેટિક રૂટ કે વધુ ચોક્કસ પ્રીફિક્સ સામે ફોરવર્ડિંગ નિર્ણય ગુમાવી શકે છે. માત્ર પ્રાપ્ત રૂટ નહીં, પસંદ કરેલો રૂટ તપાસો.
LAN બાજુ પર રિટર્ન પાથ અનુસરો
આ એ ભાગ છે જે Azureમાં સાચો દેખાય છે અને સાઇટ પર નિષ્ફળ જાય છે. શાખા Aનું હોસ્ટ તેનું પેકેટ Aના VPN રાઉટરને ફક્ત ત્યારે મોકલે છે જ્યારે એ રાઉટર તેનું ડિફોલ્ટ ગેટવે હોય, અથવા હોસ્ટ કે તેના ગેટવે પાસે Bના પ્રીફિક્સ માટે રૂટ હોય. વિરુદ્ધ દિશામાં પણ એ જ સાચું હોવું જોઈએ.
જો અલગ કોર સ્વિચ LANનું ડિફોલ્ટ ગેટવે હોય, તો તેને બીજી શાખા તરફનો રૂટ VPN રાઉટર તરફ નિર્દેશિત કરવો પડે. તેના વિના વિનંતી આવે છે અને જવાબ ઇન્ટરનેટ માર્ગેથી નીકળે છે, અને વપરાશકર્તાને એવું કનેક્શન દેખાય છે જે ખૂલે છે અને પછી અટકી જાય છે.
આ સુધારવા માટે ગેટવે સબનેટ પર નેટવર્ક સિક્યુરિટી ગ્રુપ તરફ ન જાઓ. એ સબનેટની પોતાની જરૂરિયાતો છે અને ત્યાં NSG શાખા-બાજુની નીતિનો સપોર્ટેડ વિકલ્પ નથી. ફિલ્ટરિંગ શાખાઓના ફાયરવોલ અને વર્કલોડ પર જ હોવું જોઈએ, જ્યાં નિયમો તેમના માલિકો દ્વારા સમીક્ષા કરી શકાય. એ નિયમોને સબનેટ NSGમાં ખસેડવાથી આગલી ખામી ડિબગ કરનાર ટીમથી પણ તે છુપાય છે.
ઓપરેશનને મંજૂરી આપો, પછી નકારાયેલ પરીક્ષણથી સાબિત કરો
શીખેલો રૂટ પરવાનગી નથી. તમને ખરેખર જરૂરી સ્રોત, ગંતવ્ય અને સેવાને શાખાઓના ફાયરવોલ અને એન્ડપોઇન્ટ નીતિ દ્વારા મંજૂરી આપો, અને બાકીનું નકારાયેલું રાખો.
શાખા Aના સામાન્ય વર્કલોડથી શાખા Bની વાસ્તવિક સેવા સુધી પરીક્ષણ કરો, જવાબની ખાતરી કરો, પછી એવું ઓપરેશન કરવાનો પ્રયાસ કરો જે પ્રતિબંધિત રહેવું જોઈએ. VPN ઉપકરણ પોતે જે ટ્રાફિક ઉત્પન્ન કરે છે તે અલગ સ્રોત સરનામું વાપરી શકે અને LAN રૂટિંગ તબક્કો છોડી શકે, તેથી રાઉટરથી સફળ ping દેખાય તેના કરતાં ઓછું સાબિત કરે છે.
ચાર તથ્યો લખીને પૂરું કરો: બદલાયેલા પ્રીફિક્સ, વપરાતા ASN, દરેક બાજુનો LAN રિટર્ન પાથ, અને સેવાને મંજૂરી આપતી નીતિ. તેમાંથી એક પણ ખૂટે તો સેટઅપ પ્રથમ ફેરફાર સુધી કામ કરે છે, અને પછી કોઈ સમજાવી શકતું નથી કેમ.