AWS Site-to-Site VPN થી NAT Gateway: VGW વિરુદ્ધ Transit Gateway

પહેલી વાર બધા એ જ ડાયાગ્રામ દોરે છે: VPCમાં VPN, પછી NAT gateway થઈને ઇન્ટરનેટ, પૂરું. પણ VPN જ્યારે virtual private gateway પર પૂરું થાય ત્યારે AWS એ માર્ગને ટેકો આપતું નથી, અને નિષ્ફળતા એટલી શાંત છે કે ટીમો તેને એક કરતાં વધુ વાર ફરી બનાવે છે. જે ડિઝાઇન કામ કરે છે તેને transit gateway જોઈએ, જે બંને બાજુએ gateway અને route tables બદલે છે. કંઈ દોરતા પહેલાં બંને આકાર સરખાવો.

જે ટોપોલોજી સ્પષ્ટ લાગે છે અને ટેકો નથી ધરાવતી

AWSનું NAT gateway દસ્તાવેજીકરણ એવી રેખા દોરે છે જે ફક્ત એક જ VPCની ડિઝાઇન બનાવનારને આશ્ચર્યમાં મૂકે છે: Site-to-Site VPN કનેક્શનનો ટ્રાફિક virtual private gateway દ્વારા NAT gateway તરફ route કરી શકાતો નથી. VPN કયા પ્રકારના gateway પર પૂરો થાય છે તે નક્કી કરે છે કે અનુવાદનો માર્ગ છે કે નહીં. ભૂલ ટકી રહે છે કારણ કે ટનલની સ્થિતિ UP છે અને એ જ subnetનું EC2 instance મુશ્કેલી વિના ઇન્ટરનેટ સુધી પહોંચે છે. આમાંનું કોઈ પણ અવલોકન તૂટેલી દિશા ચકાસતું નથી.

વ્યવહારમાં પેકેટ ઓન-પ્રેમિસ નેટવર્કના સ્રોત સરનામા સાથે આવે છે અને તેનો અનુવાદ કરે એવું કોઈ ટેકાવાળું આગળનું hop મળતું નથી. ટેબલ પ્રમાણે તે egress સીમા પર નાખી દેવાય છે, અને ટનલ UP રહેતી હોવાથી તથા એ જ subnetનું instance ઇન્ટરનેટ સુધી પહોંચતું હોવાથી નિષ્ફળતા ઓન-પ્રેમિસ firewall સમસ્યા તરીકે નોંધાય છે.

Virtual private gateway વિરુદ્ધ transit gateway

એક virtual private gateway એક VPCનું હોય છે. તે VPN પૂરું કરે છે, એ VPCની route tablesમાં routes મૂકે છે અને ત્યાં જ અટકે છે. તેનું attachment મોડેલ નથી, તેથી તે બીજા VPCને કે વહેંચાયેલા egress સેગમેન્ટને ટ્રાફિક આપી શકતું નથી. એક જ VPCનું આ ક્ષેત્ર એ જ આખી મર્યાદા છે, અને VPCમાં ઉમેરેલો કોઈ route તેને બદલતો નથી.

Transit gateway પ્રાદેશિક કેન્દ્ર છે જ્યાં VPN, દરેક spoke VPC અને વહેંચાયેલી સેવાઓનું VPC બધાં attachment તરીકે દેખાય છે. તેની પોતાની route tables છે, જે નક્કી કરે છે કે કયું attachment આપેલું prefix મેળવશે.

એ જ કેન્દ્ર કેન્દ્રિત egress શક્ય બનાવે છે: VPN એક attachment તરીકે ઊતરે છે, egress VPC બીજા તરીકે, અને transit gatewayની route table ઇન્ટરનેટ તરફના prefixesને પહેલાથી બીજા તરફ મોકલે છે. virtual private gateway સાથે મોકલવા માટે બીજું attachment હોતું નથી, તેથી ડિઝાઇન પછીથી પેચ કરીને બનાવી શકાતી નથી.

ટેકાવાળો egress માર્ગ, પગલે પગલે

સંદર્ભ ડિઝાઇનમાં પાંચ hops છે અને દરેક તીર એ route નિર્ણય છે જે તમારે ગોઠવવો પડે. ટ્રાફિક ઓન-પ્રેમિસ નેટવર્કમાંથી Site-to-Site VPN attachmentમાં નીકળે છે, transit gatewayની route table તેને egress VPC attachment તરફ મોકલે છે, જ્યાં subnet table તેને public NAT gateway પર મોકલે છે. NAT gateway સ્રોતનો અનુવાદ કરે છે અને internet gateway પેકેટને બહાર લઈ જાય છે.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

છેલ્લા hops કામ કરશે કે નહીં તે બે વિગતો નક્કી કરે છે. NAT gateway public હોવું જોઈએ, elastic IP અને internet gateway તરફના route સાથે, કારણ કે private NAT gateway નેટવર્ક વચ્ચે અનુવાદ કરે છે અને કદી ઇન્ટરનેટ નિકાસ બનતું નથી.

તમે સેવા આપવા માંગતા દરેક Availability Zone માટે એક NAT gatewayનું આયોજન કરો અને દરેક subnet table સ્થાનિક તરફ દોરે. તમારી નોંધમાં transit gatewayની table અને VPCની tablesને અલગ વસ્તુઓ તરીકે રાખો, કારણ કે એક attachment પસંદ કરે છે અને બીજી VPCની અંદરનું સ્રોત. ફક્ત એકમાં default route હોય તો અડધો માર્ગ અવ્યાખ્યાયિત રહે છે અને એ આંશિક નિષ્ફળતાઓ ઊભી થાય છે જે ઓળખવી સૌથી કઠિન છે.

આ ડિઝાઇન પરત માર્ગ પર જ નિષ્ફળ જાય છે

NAT gateway પહેલેથી જોયેલા flows માટે stateful છે, તેથી બહાર જતા કનેક્શનના જવાબ નવા inbound નિયમ વિના પાછા આવે છે. એ ગુણધર્મ ઓન-પ્રેમિસ સેવાને ઇન્ટરનેટ પર પ્રકાશિત કરતું નથી, અને એમ માનવું એ છે કે ટીમ એવા કનેક્શનને ડિબગ કરવામાં દિવસ ખર્ચે જે કદી બનવાનું જ નહોતું. ક્લાયન્ટથી શરૂ થતા ટ્રાફિક માટે ચાર routes સંમત થવા જોઈએ: ઓન-પ્રેમિસ નીતિ, transit gatewayની table, egress subnet table અને NAT subnet table. છેલ્લી ચૂકી જાઓ તો વિનંતી ઇમારત છોડે છે જ્યારે જવાબ AWSની અંદર મરી જાય છે.

VPN પાછળના સાચા ક્લાયન્ટ સાથે ચકાસો અને તે કયું public સ્રોત સરનામું રજૂ કરે છે તે જુઓ. જો એ NAT gatewayનું elastic IP હોય તો અનુવાદ થઈ રહ્યો છે; બીજું કંઈ હોય તો તમે અલગ egress માપી રહ્યા છો.

આ નિષ્ફળતાનું અસમમિત સ્વરૂપ વહેલું ઓળખવા જેવું છે. જ્યારે એક Availability Zoneની NAT subnet tableમાં ક્લાયન્ટ prefix તરફ પરત route હોય અને બીજીમાં ન હોય, ત્યારે નવા કનેક્શન flow કયા ઝોનમાં પડે છે તેના આધારે સફળ કે નિષ્ફળ થાય છે, અને એ પેટર્નને ખોટી રીતે અસ્થિર ઇન્ટરનેટ તરીકે વાંચવામાં આવે છે. ટિકિટ ખૂલી હતી તે ઝોન સુધારવાને બદલે તમે સેવા આપતા દરેક ઝોનની subnet tables સરખાવો, કારણ કે ખૂટતો route એ આખો દોષ છે અને સામેની બાજુએ કંઈ બદલવાની જરૂર નથી.

ક્યારે સ્પષ્ટ proxy વધુ સારી ડિઝાઇન છે

egress VPCના instance પર HTTP proxy કાયદેસર વિકલ્પ છે અને ઘણી વાર સસ્તું પણ. ક્લાયન્ટ તેને વાપરવા ગોઠવાય છે, proxy પોતાનું કનેક્શન બહાર ખોલે છે, અને પરત માર્ગ સમમિત routingનું કોયડું નહીં પણ proxyની સમસ્યા બને છે. થોડી એપ્લિકેશનો માટે એ transit gatewayનું મોટા ભાગનું કામ દૂર કરે છે. તે વપરાશકર્તા-આધારિત લોગ પણ આપે છે જે NAT gateway આપી શકતું નથી.

જો કે તે પારદર્શક નથી. proxy સેટિંગ્સ અવગણતું કંઈ પણ, અને HTTP ન હોય એવું દરેક પ્રોટોકોલ, એ માર્ગે નહીં જાય.

પસંદગી એના પર છે કે તમારી એપ્લિકેશનો ખરેખર શું બોલે છે અને લોગમાં કેટલી ઓળખ જોઈએ છે. જ્યાં તે HTTP બોલે છે ત્યાં proxy પોતાનું સ્થાન સંપાદિત કરે છે; જ્યાં મનસ્વી પ્રોટોકોલ માટે સામાન્ય egress જોઈએ છે ત્યાં AWS ટેકો આપતી ડિઝાઇન transit gatewayની છે. અગાઉથી એ નક્કી કરવું route tables બન્યા પછી શોધવા કરતાં સસ્તું છે.