strongSwan થી AWS Site-to-Site: Child SA કેમ કંઈ પણ પસંદ કરતું નથી

કન્સોલ સ્થિતિ up બતાવે છે, strongSwan સ્થાપિત IKE એસોસિએશનની જાણ કરે છે, અને પેકેટ હજી પણ પહોંચતા નથી. હવે સરખાવવાની વાત પ્રી-શેર્ડ કી નથી, પણ એ પ્રીફિક્સની જોડી છે જે દરેક બાજુ માને છે કે ટનલ તેમને રક્ષે છે. નીચેની ચકાસણીઓ ક્રમમાં કરો, કારણ કે પહેલી બે નક્કી કરે છે કે ટનલ તમારો ટ્રાફિક બિલકુલ વહન કરી શકે છે કે નહીં.

AWS ના નામોને strongSwan ના શબ્દોમાં અનુવાદિત કરો

AWS ગ્રાહકની બાજુથી કનેક્શનનું વર્ણન કરે છે: ગ્રાહક ગેટવેનું સરનામું અને લોકલ CIDR તમારા છે, અને રિમોટ CIDR VPC નું છે. strongSwan બે છેડાને left અને right કહે છે, તમારો પ્રીફિક્સ leftsubnet માં અને VPC નો પ્રીફિક્સ rightsubnet માં હોય છે. એક જોડી ઉલટાવવાથી એવી ટનલ બને છે જે ખોટા ટ્રાફિકની વાટાઘાટ કરે છે અને તેને પસંદ કરે છે.

AWS કનેક્શન માટે જે કન્ફિગરેશન બનાવે છે તે ડાઉનલોડ કરો અને તેને તે જ કનેક્શન માટે સંદર્ભ ગણો, જેમાં ટનલના સરનામાં અને પ્રીફિક્સનો સમાવેશ થાય છે. બનાવતી વખતે બંને CIDR ક્ષેત્રો ખાલી છોડો તો સેવા દરેક બાજુ 0.0.0.0/0 ડિફોલ્ટ વાપરે છે. સાંકડા પ્રીફિક્સ સાથે ગોઠવાયેલ રાઉટર પછી તેની સાથે ક્યારેય મેળ ખાશે નહીં, તેથી ક્ષેત્રો ભરો અથવા સિલેક્ટરને જાણી જોઈને પહોળો કરો.

અહીંની અસંગતિ રાઉટિંગ નિષ્ફળતા જેવી લાગે છે અને તે નથી.

AWS ખરેખર જે સરનામું જુએ છે તેને પિન કરો

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

conn %default
    local_addrs = 203.0.113.10

strongSwan માં local_addrs IKE માટે સ્રોત સરનામું પસંદ કરે છે, અને જૂની OpenSwan કન્ફિગરેશન એ જ વિચારને left તરીકે લખે છે. તેને જાહેર સરનામું ધરાવતા ઇન્ટરફેસ તરફ નિર્દેશ કરો, પછી NAT ઉપકરણ પર જ ચકાસો કે UDP 500 અને 4500 તે હોસ્ટ સુધી પહોંચે છે, કારણ કે અગાઉના રાઉટરથી બચેલો નિયમ તેમને ચૂપચાપ કાઢી નાખે છે. સાચી સિલેક્ટર જોડી ખોટા સ્રોત સરનામા સાથે પણ નિષ્ફળ જાય છે, અને લોગ દોષ પ્રસ્તાવ પર નાખશે. એ ભ્રમ જ કારણ છે કે સ્રોત સરનામાને પોતાની ચકાસણી જરૂરી છે.

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

ફેઝ 1 અને ફેઝ 2 અલગ રીતે સંભાળો

AWS IKE અને ESP વિકલ્પોને અલગ યાદી તરીકે દર્શાવે છે. બંને બાજુ સ્વીકારે એવો IKE સમૂહ ESP પ્રસ્તાવ વિશે કંઈ કહેતો નથી, કારણ કે બંને યાદીઓ સ્વતંત્ર છે. બંનેને બનાવેલ કન્ફિગરેશનમાંથી વાંચો અને એક પછી એક સરખાવો.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

સિન્ટેક્સ અમલીકરણો વચ્ચે પસાર થતું નથી. OpenSwan માં કામ કરતી જોડી, જેમ કે phase2alg=aes_gcm સાથે ike=aes256-sha1;modp1024, strongSwan ના esp= અને ike= સ્વરૂપમાં અનુવાદિત કરવી પડે છે, અને અલ્ગોરિધમના નામ અલગ છે. GCM એન્ક્રિપ્ટ કરતી વખતે જ અધિકૃત કરે છે, તેથી તેને અલગ ઇન્ટિગ્રિટી ટ્રાન્સફોર્મની જરૂર નથી, SHA સાથે જોડાયેલ CBC સમૂહથી વિપરીત. એક ડિમનમાંથી બીજામાં અનુવાદ વિના પેસ્ટ કરેલી ફેઝ 2 લાઇન સિલેક્ટર અસંગતિ જેવો ભાસતો અસ્વીકાર ઉત્પન્ન કરે છે.

ટનલ ઇન્ડિકેટર નહીં, ચાઇલ્ડ એસોસિએશન તપાસો

જો કનેક્શન લોડ થાય પણ કોઈ ચાઇલ્ડ એસોસિએશન ન ઊભું થાય, તો કાં પ્રસ્તાવ કાં સિલેક્ટર નકારાયા છે. જો ચાઇલ્ડ ઊભું થાય અને તેના સિલેક્ટર તમારા પ્રીફિક્સને બાકાત રાખે, તો પેકેટ ટનલ સુધી પહોંચતા પહેલા ફિલ્ટર થાય છે. કન્સોલનું ઇન્ડિકેટર ફક્ત IKE સ્તરને આવરે છે, તેથી તે કહી શકતું નથી કે બેમાંથી કઈ ઘટના બની.

ipsec statusall

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

લોકલ પ્રીફિક્સની અંદરના હોસ્ટથી VPC પ્રીફિક્સની અંદરના હોસ્ટ સુધી પરીક્ષણ કરો અને પરત માર્ગ તથા AWS બાજુની કોઈ પણ સુરક્ષા જૂથ કે નેટવર્ક ACL ચકાસો. સાચા સિલેક્ટર પેકેટને પછીથી નાખી દેવાથી બચાવતા નથી.

સિલેક્ટર મેળ ખાધા પછી પણ નિષ્ફળ જાય ત્યારે

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

બીજો પ્રસ્તાવ બદલતા પહેલા દરેક બાજુએ એક આવતું અને એક જતું પેકેટ લોગ કરો.

નોંધો સિલેક્ટર, ફેઝ 1 અને ફેઝ 2 ના પ્રસ્તાવો અને સ્રોત સરનામું ટિકિટમાં. આ ચાર મૂલ્યો કૉલ વિના મોટાભાગની site-to-site નિષ્ફળતાઓ સમજાવે છે.