VGW કે TGW? AWS Site-to-Site નો IPsec ટનલ ક્યાં પૂરો થાય છે

લોકો પૂછે છે કે AWS Site-to-Site VPN પેકેટને સુરક્ષિત કરવાનું ક્યાં બંધ કરે છે અને એક જ જવાબની અપેક્ષા રાખે છે: ગેટવે પર. એ જવાબનું ઉપયોગી સંસ્કરણ કહે છે કે કયો ગેટવે, કારણ કે વર્ચ્યુઅલ પ્રાઇવેટ ગેટવે અને ટ્રાન્ઝિટ ગેટવે અલગ એટેચમેન્ટ ઑબ્જેક્ટ સાથેના અલગ ગોઠવણો છે, અને ખોટી ગોઠવણ ધારી લેનાર સમીક્ષક બાકીનું મૂલ્યાંકન એવા ડાયાગ્રામ પર ઊભું કરે છે જે અસ્તિત્વમાં નથી. નીચેની ત્રણ તપાસ ક્રમમાં કરો. દરેક કાં તો સીમાની પુષ્ટિ કરે છે અથવા કહે છે કે અગાઉનો જવાબ બીજા સંસાધન વિશે હતો.

કંઈપણ મૂલ્યાંકન કરતા પહેલાં ત્રણ એન્ડપોઇન્ટના નામ આપો

આ માર્ગની એન્ક્રિપ્શન સમીક્ષાને ત્રણ નામ આપેલી વસ્તુઓની જરૂર છે: ગ્રાહક ગેટવે, IPsec સમાપ્ત કરતું AWS VPN લક્ષ્ય, અને આંતરિક પેકેટ મેળવતો એપ્લિકેશન એન્ડપોઇન્ટ. એક પણ કન્સોલ પૃષ્ઠ ખોલતા પહેલાં તેમને તેમના સંસાધન ઓળખકર્તા સાથે લખો, કારણ કે આ બિંદુ પછીનું બધું તે ત્રણમાંથી એક વિશેનું વિધાન છે.

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

તપાસ 1: કયો ગેટવે ખરેખર ટનલ સમાપ્ત કરે છે

બંને ગોઠવણો સમર્થિત છે અને Site-to-Site VPN આર્કિટેક્ચર માર્ગદર્શિકા તેમને સાથે સાથે વર્ણવે છે, તેથી ઘણી વાર એક વર્ષ જૂનું હોય તેવા ડાયાગ્રામને બદલે APIને પૂછો. એક કનેક્શન પરની ફક્ત-વાંચન ક્વેરી VPN લક્ષ્ય ક્ષેત્રો પરત કરે છે:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

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

ત્યાં હોવ ત્યારે ટનલ પણ તપાસો. કનેક્શન રિડન્ડન્સી માટે બે IPsec ટનલ વહન કરે છે, અને જે કનેક્શનની બીજી ટનલ ક્યારેય ઊભી નથી થઈ તે ઉપલબ્ધતા માટે ખરેખર એક શોધ છે, ભલે તે એન્ક્રિપ્શન સીમા વિશે કંઈ બદલતી નથી:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

તપાસ 2: આંતરિક પેકેટ હજી શું વહન કરે છે

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

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

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

તપાસ 3: ગેટવે પાછળ TLS કઈ વસ્તુ સમાપ્ત કરે છે

સરનામા નહીં, શ્રોતાને અનુસરો. જો લોડ બેલેન્સર અથવા પ્રોક્સી TLS સમાપ્ત કરે છે, તો તમારા ક્લાયન્ટ પાસેનું કનેક્શન ત્યાં જ પૂરું થાય છે, અને પ્રોક્સી બેકએન્ડ સાથે બીજું કનેક્શન ખોલે છે જે સાદું ટેક્સ્ટ હોઈ શકે અથવા અલગ વિશ્વાસ સાંકળ સાથેનું TLS હોઈ શકે. ખાનગી IP સરનામું અને મેળ ખાતો માર્ગ તે બીજા કનેક્શન વિશે પુરાવો નથી.

તમને ખરેખર મહત્વનું હોય તે એન્ડપોઇન્ટને VPCની અંદરથી ચકાસો, એપ્લિકેશન જે નામ વાપરે તે નામ સાથે, એક વાર ઉકેલેલા IP સાથે નહીં:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

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

પરિણામને ચુકાદા તરીકે નહીં, સેગમેન્ટ તરીકે નોંધો

આ ચેકલિસ્ટનું પરિણામ એક નાનું કોષ્ટક છે જેમાં દરેક સેગમેન્ટ માટે એક પંક્તિ હોય: ગ્રાહક ગેટવેથી AWS VPN લક્ષ્ય સુધી, ગેટવેથી વર્કલોડ સુધી, વર્કલોડથી ડેટા સ્ટોર સુધી, અને વચ્ચેનું કોઈપણ પ્રોક્સી હોપ. દરેક પંક્તિ કહે છે કે તેને શું સુરક્ષિત કરે છે અને તે સુરક્ષા શેના પર આધારિત છે. પદ્ધતિ અને એન્ડપોઇન્ટ વિનાનું "એન્ક્રિપ્ટેડ" પંક્તિ નથી.

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

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