EC2 પર strongSwan: VPC ને કામનો ભાર રૂટ કરવા દો

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

પહેલા ચાર સરનામાં લખી લો

નીચેનું દરેક પગલું આનો સંદર્ભ લે છે, તેથી રૂટિંગ કોષ્ટકને સ્પર્શ કરતા પહેલા તમારા પોતાના ખાતા માટે તે ભરો.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

ઉદાહરણ મંજૂર, કાર્યરત નીતિ-આધારિત IPsec જોડાણ અને સ્રોત જાળવતા પ્રવાહને ધારે છે. આ NAT વાળું રિમોટ એક્સેસ ક્લાયન્ટ નથી જે એક ફાળવેલું સરનામું ઉધાર લે છે, અને એ ભેદ જ નક્કી કરે છે કે સિલેક્ટર બદલવા પડશે કે નહીં.

પગલું 1: કામના ભારની સબનેટને રૂટ આપો

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

AWS ની ઉપકરણ દ્વારા રૂટિંગ માર્ગદર્શિકા નેટવર્ક ઇન્ટરફેસના લક્ષ્યો અને ફોરવર્ડ કરતા ઇન્સ્ટન્સની સ્રોત/ગંતવ્ય ચકાસણીની જરૂરિયાત વર્ણવે છે. તે ચકાસણી ફેરફારને ગેટવેની ભૂમિકા સુધી મર્યાદિત કરો, અને સામાન્ય એપ્લિકેશન ઇન્સ્ટન્સને શાંતિમાં રહેવા દો.

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

પગલું 2: અતિથિ પર ફોરવર્ડિંગ ચાલુ કરો

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

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

પગલું 3: સિલેક્ટરને ખરા સ્રોતો સુધી વિસ્તારો

AWS બાજુ ફક્ત 10.60.1.10/32 આવરી લેતી નીતિ 10.60.2.20 આવર્યા વિના ગેટવેથી શરૂ થયેલી સફળતા સમજાવે છે. દૂરના ગંતવ્ય તરફનો રૂટ ટ્રાફિક સિલેક્ટર વિસ્તારતો નથી, અને એ જ આશ્ચર્યનો બીજો અડધો ભાગ છે.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

જો સંમત ડિઝાઇન આખા VPC ને સુરક્ષિત કરે છે, તો બંને પક્ષોએ 10.60.0.0/16 અને 10.90.0.0/24 સ્વીકારવા પડશે. જો તે એક કામનો ભાર સુરક્ષિત કરે છે, તો જાણી જોઈને તે સાંકડો પ્રિફિક્સ વાપરો. કોઈ પણ સ્થિતિમાં, સ્થાપિત CHILD-SA નીતિ તપાસો, કારણ કે તમે સંપાદિત કરેલું રૂપરેખાંકન અને જેણે તેને જુદી રીતે સાંકડું કર્યું તે પક્ષ એક જ કરાર નથી.

દૂરના સાઇટે પણ જાળવેલા VPC સ્રોતોના જવાબો ઇચ્છિત IPsec ગેટવે દ્વારા પાછા રૂટ કરવા જોઈએ. જ્યાં બીજા સ્રોત NAT નિયમો હોય ત્યાં સુરક્ષિત ટ્રાફિક માટે સમર્થિત NAT મુક્તિ રાખો; બિનમંજૂર કામના ભારને મંજૂર હોસ્ટ સરનામામાં અનુવાદિત કરવું એ બીજો ઓળખ કરાર છે, તમે ઇચ્છેલી ઍક્સેસનો શોર્ટકટ નથી.

પગલું 4: ચકાસો, પછી જરૂર હોય તો પાછું ફેરવો

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

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

પાછું ફેરવવું એ જ ક્રમ ઉલટાવે છે. કામના ભારની સબનેટનો રૂટ સૌથી છેલ્લે દૂર કરો, અગાઉના સિલેક્ટર પુનઃસ્થાપિત કર્યા પછી, જેથી એવી સબનેટ ન છોડો જે એવા ગેટવે તરફ નિર્દેશ કરે જે હવે તેના સ્રોતોનું રક્ષણ કરતું નથી. જ્યારે આ કરારો ટકે છે ત્યારે સ્વ-હોસ્ટિંગ ગેટવે હોસ્ટ કરતાં વધુ સેવા આપી શકે છે, અને AWS-સંચાલિત Site-to-Site VPN એ ભિન્ન કાર્યાત્મક મોડેલ છે જ્યાં strongSwan ગ્રાહક ગેટવેની બાજુએ બેસી શકે છે.