AWS થી Azure સાઇટ VPN: પહેલાં પરત-માર્ગ લખો
બે ક્લાઉડ વચ્ચે જોડાયેલ ટનલ ત્યાં સુધી કંઈ સાબિત કરતી નથી જ્યાં સુધી દરેક વર્કલોડ સબનેટ દૂરના પ્રીફિક્સ તરફ રૂટ ન કરે. યોજના ક્રમમાં કરો, પછી સેવાનું પરીક્ષણ કરો.
ટનલ ઉપર આવશે. સામાન્ય રીતે એમ જ થાય છે, કારણ કે IKE ને ફક્ત મેળ ખાતા પ્રસ્તાવ અને પહોંચી શકાય એવું પીઅર સરનામું જોઈએ. પછી જે નિષ્ફળ જાય છે તે પરતનો માર્ગ છે: AWS વર્કલોડ પેકેટને ટનલમાં મોકલે છે, પણ Azure બાજુએ કોઈને ખબર નથી કે 10.10.0.0/16 ને કેવી રીતે જવાબ આપવો, અથવા Azure રૂટ એવા કોષ્ટકમાં છે જે વર્કલોડ સબનેટ વાપરતું નથી. કોઈપણ કન્સોલને અડકતા પહેલાં રૂટ યોજના લખો, અને ટનલ કામનો સૌથી ઓછો રસપ્રદ ભાગ બની જશે.
પગલું 1: સરનામા યોજના સ્થિર કરો
ચોક્કસ મૂલ્યો સાથે કામ કરો. AWS વર્કલોડ 10.10.0.0/16 ની અંદર 10.10.1.20 પર છે અને 10.20.0.0/16 ની અંદર 10.20.1.30 પરની Azure સેવા માટે TCP 443 જોઈએ. બંને શ્રેણીઓ ઓવરલેપ ન થવી જોઈએ, અને સ્વીકૃતિ પરીક્ષણ સેવા-જોડી છે, ટનલ નહીં.
બીજું કંઈ પણ કરતાં પહેલાં એ ચાર હકીકતો લખો, કારણ કે પછીનું દરેક પગલું તેમની સામે ચકાસાય છે.
પગલું 2: દરેક છેડાનો માલિક ગેટવે નામ આપો
AWS Site-to-Site VPN વર્ચ્યુઅલ પ્રાઇવેટ ગેટવે અથવા ટ્રાન્ઝિટ ગેટવે પર સમાપ્ત થઈ શકે છે, અને તે અલગ રૂટિંગ માલિકો છે. Azure તેનું મેનેજ્ડ VPN Gateway અને અલગથી ગ્રાહકો પોતે ચલાવતા VM-આધારિત ઉપકરણો આપે છે. તમારી પાસે કઈ જોડી છે તે નોંધો, કારણ કે દરેક સંયોજનમાં આગળનું હોપ અલગ હોય છે.
મેનેજ્ડ ગેટવે માટે, અનુમાનિત ખાનગી ઉપકરણ સરનામા તરફ જતો રૂટ કૉપી ન કરો. ઉપકરણ માટે, એવું ન માનો કે ક્લાઉડ રૂટ પ્રોપગેશન ગેસ્ટ ઓપરેટિંગ સિસ્ટમ ગોઠવે છે, કારણ કે તે એમ કરતું નથી.
આમાં ભૂલ કરવાથી એવી યોજના બને છે જે પૂર્ણ દેખાય છે અને પેકેટને એવા સરનામે મોકલે છે જે કદી જવાબ આપતું નથી.
પગલું 3: દરેક વર્કલોડ ખરેખર જે રૂટ વાપરે છે તે લખો
નીચેની દરેક સીમા અલગ શોધ છે, અને તેમાંથી એકમાંનો રૂટ પેકેટ માટે રૂટ નથી. ટનલ જીવંત થાય તે પહેલાં કોષ્ટક તમારા પોતાના મૂલ્યોથી ભરો.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS માં, વર્કલોડ સબનેટનું રૂટ કોષ્ટક BGP કે ટનલ સ્વસ્થ થયા પછી પણ તમારે અપડેટ કરવાનું છે; રૂટિંગ વિહંગાવલોકન તેને જોડાણનો ભાગ ગણે છે. Azure માં, વપરાશકર્તા-નિર્ધારિત રૂટ કોષ્ટક વર્ચ્યુઅલ નેટવર્ક સાથે નહીં, સબનેટ સાથે સંકળાય છે, તેથી અસરકારક રૂટ VNet બ્લેડમાં નહીં, વર્કલોડ NIC પર તપાસો.
મેનેજ્ડ Azure ગેટવે ગેટવે પ્રોપગેશન દ્વારા દૂરનું પ્રીફિક્સ શીખી શકે છે, અને UDR તે નિર્ણયને રદ કરી શકે છે. કારણ હોય ત્યારે UDR ઉમેરો, આદતવશ નહીં. જો ઉમેરો, તો ઉપકરણ સરનામું બનાવવાને બદલે ગેટવે VPN માર્ગ માટે જે આગળનું હોપ પ્રકાશિત કરે તેના તરફ નિર્દેશ કરો. પછી NIC પરના અસરકારક રૂટ ફરી વાંચો, કારણ કે નિર્ણય ખરેખર NIC પર જ લેવાય છે.
પગલું 4: વ્યાપ મેળવો
BGP માટે, દરેક બાજુ શું જાહેર કરે છે તેની સરખામણી બીજી બાજુએ ખરેખર શું શીખ્યું તેની સાથે કરો, પ્રીફિક્સ પ્રમાણે. સ્થિર રૂટિંગ માટે, ગોઠવેલી દૂરની શ્રેણીઓની સરખામણી પગલું 3 માં લખેલા વર્કલોડ રૂટ સાથે કરો.
ક્રિપ્ટોગ્રાફી પર સહમત IKE સંબંધ એ પુરાવો નથી કે કોઈ બાજુએ 10.10.0.0/16 અથવા 10.20.0.0/16 શીખ્યું છે. બે ટનલ ઉપર હોઈ શકે છે જ્યારે એક બાજુ તમે યોજેલા /16 ને બદલે એક જ /24 જાહેર કરે છે. પ્રીફિક્સ રૂટિંગ કોષ્ટકમાં તપાસો, ટનલ સ્થિતિમાં નહીં. અસંગતિ પછી એક કામ કરતા સબનેટ અને એક કદી જવાબ ન આપતા સબનેટ તરીકે દેખાય છે.
પગલું 5: સાચા સ્રોતથી સેવાનું પરીક્ષણ કરો
AWS સિક્યોરિટી ગ્રુપ અને નેટવર્ક ACL, Azure NSG અને માર્ગ પરના કોઈપણ ઉપકરણ ફિલ્ટરમાં ઇચ્છિત પ્રવાહને મંજૂરી આપો. પછી 10.10.1.20 થી મંજૂર સેવા સરનામા અને પોર્ટ પર એક જોડાણ ખોલો અને ખાતરી કરો કે જવાબ તે જ સ્રોત પર પાછો આવે છે.
ક્લાઉડ સિક્યોરિટી ગ્રુપ અને NSG બંને stateful છે, તેથી નકારાયેલ પરત પેકેટ રૂટિંગનું લક્ષણ છે, વિરુદ્ધ દિશામાં લખવાનું ભૂલી ગયેલો નિયમ નહીં.
કોઈપણ ગેટવેથી ping કંઈ નક્કી કરતું નથી. ગેટવે સરનામા પર ICMP કંટ્રોલ પ્લેન માર્ગ કસાવે છે, વર્કલોડને જરૂરી ફોરવર્ડ થયેલ TCP સેવા નહીં.
રોલબેક અને રેકોર્ડ
ટનલ ઓળખકર્તાની બાજુમાં રૂટ માલિકો નોંધો અને ફેરફાર પહેલાંના રૂટ કોષ્ટક સાચવો. જો ફેરફાર દૂર કરવો પડે, તો ટનલ તોડતા પહેલાં વર્કલોડ રૂટ દૂર કરો, જેથી કોઈ સબનેટ હવે અસ્તિત્વમાં ન હોય એવા આગળના હોપ તરફ ન જોતું રહે.
પછીના સબનેટ સ્થળાંતર કે spoke જોડાણ માટે પછી અપડેટ કરવાની એક નિશ્ચિત જગ્યા હોય છે, જે રૂટનો કદી માલિક ન હોય તેવા રૂટ માટે દોષ વહેતી ચાલુ ટનલને બદલે.