AWS VPN માં સ્થાનિક સબનેટ ઉમેરો: VGW વિરુદ્ધ Transit Gateway

હાલનું Site-to-Site VPN 10.60.0.0/16 વહન કરે છે, તે જ સ્થાનિક ગેટવે પાછળ 10.70.0.0/16 તરીકે નવું સેવા નેટવર્ક દેખાય છે, અને કોઈ પૂછે છે કે પ્રોક્સી જરૂરી છે કે નહીં. સામાન્ય રીતે નહીં: રાઉટેડ માર્ગ પ્રીફિક્સ વહન કરી શકે છે, પરંતુ ફક્ત ત્યારે જ જ્યારે ત્રણ વસ્તુઓ મળે, અને કઈ ત્રણ તે તમે પહેલેથી ચલાવો છો તે AWS આર્કિટેક્ચર પર આધાર રાખે છે. વર્ચ્યુઅલ ખાનગી ગેટવેની એક રૂટ-ટેબલ સીમા હોય છે; ટ્રાન્ઝિટ ગેટવે બીજી ઉમેરે છે. જાહેરાત સાચી અને ટેબલ ખોટું હોય તો એવું સત્ર બને છે જે સ્વસ્થ લાગે છે અને કંઈ પહોંચાડતું નથી.

એવો પ્રીફિક્સ પ્રકાશિત કરો જે ગેટવે ખરેખર પહોંચાડી શકે

કોઈપણ જાહેરાત અર્થપૂર્ણ થાય તે પહેલાં સ્થાનિક ગેટવેને નવા નેટવર્ક તરફ આગળનો માર્ગ જોઈએ. BGP દ્વારા 10.70.0.0/16 ની જાહેરાત AWS ને કહે છે કે તે શ્રેણીના પેકેટ ક્યાં મોકલવા; તે સ્થાનિક ફોરવર્ડિંગ માર્ગ બનાવતું નથી જે શ્રેણીને બીજા છેડે પહોંચી શકાય તેવી બનાવે. ખાતરી કરો કે ગેટવે પાસે પ્રીફિક્સ માટે માર્ગ છે જે તેને ધરાવતા ઉપકરણ તરફ નિર્દેશ કરે છે, અને ઉપકરણ તે સરનામાંઓ માટે જવાબ આપવા રૂપરેખાંકિત છે. નિકાસ નીતિ અને સ્વીકૃત પ્રીફિક્સ મર્યાદા આગળની મર્યાદા છે, કારણ કે સત્ર જે પ્રીફિક્સ ફિલ્ટર કરે છે તે AWS સુધી પહોંચતું જ નથી.

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

માર્ગ એક: વર્ચ્યુઅલ ખાનગી ગેટવેની સીમા

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

સ્વસ્થ BGP સત્ર સાબિત કરે છે કે ચેનલ અસ્તિત્વમાં છે. તે એ કહેતું નથી કે આપેલું સબનેટ ટેબલ રૂટનો ઉપયોગ કર્યો છે કે નહીં.

માર્ગ બે: ટ્રાન્ઝિટ ગેટવે એક ટેબલ ઉમેરે છે

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

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

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

પરત માર્ગ પોતે એક નીતિ નિર્ણય છે

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

સરનામાં ઓવરલેપ બીજી જાળ છે. અલગ, સ્પષ્ટ માલિકીની શ્રેણીઓ આને સરળ રાખે છે; ઓવરલેપિંગ શ્રેણીઓનો અર્થ અનુવાદ અથવા પુનઃરચના છે, અને બંનેમાંથી કોઈ એક જ રેસીપીનો બદલી શકાય તેવો પ્રકાર નથી.

નવા નેટવર્કમાં સ્રોત અને એપ્લિકેશન સબનેટમાં ગંતવ્ય સાથે પરીક્ષણ કરો, પછી બીજી દિશામાં પુનરાવર્તન કરો. એકદિશ પરીક્ષણ ફક્ત એક દિશા સાબિત કરે છે.

ક્યારે પ્રોક્સી ખરેખર વધુ સારી સીમા છે

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

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