Kutoka strongSwan hadi AWS Site-to-Site: kwa nini Child SA haichagui kitu
Tunnel ya IKE inaweza kuwa juu wakati muungano wa mtoto unaondoa subnet zako. Linganisha kwanza CIDR ya ndani na ya mbali ya AWS na leftsubnet na rightsubnet.
Konsoli inaonyesha up, strongSwan inaripoti muungano wa IKE ulioimarishwa, na pakiti bado hazifiki. Kitu kinachofuata kulinganishwa si ufunguo ulioshirikiwa mapema, bali jozi ya viambishi ambavyo kila upande unadhani tunnel inavilinda. Pitia ukaguzi ulio hapa chini kwa mpangilio, kwa sababu mawili ya kwanza yanaamua kama tunnel inaweza kubeba trafiki yako kabisa.
Tafsiri majina ya AWS kuwa istilahi za strongSwan
AWS inaeleza muunganisho kutoka upande wa mteja: anwani ya lango la mteja na CIDR ya ndani ni zako, na CIDR ya mbali ni ya VPC. strongSwan inaita ncha mbili left na right, kiambishi chako kiko kwenye leftsubnet na kiambishi cha VPC kiko kwenye rightsubnet. Kubadilisha jozi moja huzalisha tunnel inayojadili na kuchagua trafiki isiyo sahihi.
Pakua usanidi ambao AWS huzalisha kwa muunganisho na uuchukue kama rejeleo la muunganisho huo hasa, ukiwemo anwani na viambishi vya tunnel. Ukiacha sehemu zote mbili za CIDR tupu wakati wa kuunda, huduma hutumia 0.0.0.0/0 chaguo-msingi kwa kila upande. Kipanga njia kilichosanidiwa na kiambishi chembamba hakiwezi kamwe kulingana nacho, kwa hiyo ama jaza sehemu hizo au panua kichaguzi kwa makusudi.
Kutokulingana hapa kunaonekana kama kushindwa kwa uelekezaji na si hivyo.
Imarisha anwani ambayo AWS inaiona kweli
Kipanga njia nyuma ya NAT kinaweza kutuma IKE kutoka kiolesura ambacho upande wa pili haujawahi kujua. Anwani ya lango iliyorekodiwa katika AWS lazima iwe ile ambayo AWS inaiona kwenye mtandao, na kipanga njia lazima kifungwe kwenye anwani hiyo hiyo ya ndani badala ya kufuata njia yake chaguo-msingi.
conn %default
local_addrs = 203.0.113.10
Katika strongSwan local_addrs huchagua anwani ya chanzo kwa IKE, na usanidi wa zamani wa OpenSwan huandika wazo hilo kama left. Ielekeze kwenye kiolesura kilicho na anwani ya umma, kisha hakikisha kwenye kifaa cha NAT chenyewe kwamba UDP 500 na 4500 zinafika kwa mwenyeji huyo, kwa sababu kanuni iliyobaki kutoka kipanga njia cha awali hu zitupa kimya. Jozi sahihi ya vichaguzi na anwani isiyo sahihi ya chanzo bado inashindwa, na kumbukumbu italaumu pendekezo. Upotoshaji huo ndio sababu anwani ya chanzo inastahili ukaguzi wake.
Thibitisha kanuni ya upelekaji badala ya kuichukulia, kwa sababu kanuni iliyokuwa sahihi kwa kipanga njia kilichopita mara nyingi hubaki.
Shughulikia awamu ya 1 na awamu ya 2 kwa mbali
AWS inaonyesha chaguo za IKE na ESP kama orodha tofauti. Seti ya IKE ambayo pande zote zinakubali haisemi kitu kuhusu pendekezo la ESP, kwa sababu orodha hizo mbili ni huru. Soma zote mbili kutoka usanidi uliozalishwa na uzilinganishe moja baada ya nyingine.
conn aws
ike = aes256-sha1-modp1024
esp = aes256gcm16
Sintaksia haisafiri kati ya utekelezaji. Jozi inayofanya kazi katika OpenSwan, kwa mfano phase2alg=aes_gcm pamoja na ike=aes256-sha1;modp1024, inahitaji kutafsiriwa kuwa umbo la esp= na ike= la strongSwan, na majina ya algoriti yanatofautiana. Kwa kuwa GCM huthibitisha wakati inasimbia, haihitaji mabadiliko tofauti ya uadilifu, tofauti na seti ya CBC iliyounganishwa na SHA. Mstari wa awamu ya 2 uliobandikwa kutoka daemon moja hadi nyingine bila tafsiri huzalisha kataa linalosomwa kama kutokulingana kwa vichaguzi.
Kagua muungano wa mtoto, si kiashiria cha tunnel
Ikiwa muunganisho unapakiwa lakini hakuna muungano wa mtoto unaotokea, ama pendekezo au vichaguzi vilikataliwa. Ikiwa mtoto anatokea na vichaguzi vyake vinaondoa viambishi vyako, pakiti huchujwa kabla ya kufika kwenye tunnel. Kiashiria cha konsoli kinashughulikia kiwango cha IKE pekee, kwa hiyo hakiwezi kukuambia ni kipi kati ya mawili kilitokea.
ipsec statusall
Tafuta muungano wa usalama wa mtoto na soma vichaguzi vya trafiki vilivyochapishwa kando yake, kisha vilinganishe na viambishi kutoka usanidi uliozalishwa.
Jaribu kutoka mwenyeji ndani ya kiambishi cha ndani hadi mwenyeji ndani ya kiambishi cha VPC, na kagua njia ya kurudi pamoja na kundi lolote la usalama au ACL ya mtandao upande wa AWS. Vichaguzi sahihi havilindi pakiti dhidi ya kutupwa baadaye.
Wakati bado inashindwa baada ya vichaguzi kulingana
Thibitisha kwamba njia ya pande zote mbili inaelekea kwenye tunnel, kisha thibitisha kwamba kifaa cha NAT hakiandiki upya trafiki kwa namna ambayo sera haitarajii. Tunnel inayotegemea sera hulinganisha anwani za pakiti, kwa hiyo tafsiri inayotumika baada ya uamuzi wa sera hubadilisha matokeo.
Rekodi pakiti moja inayoingia na moja inayotoka kwa kila upande kabla ya kubadilisha pendekezo lingine.
Andika vichaguzi, mapendekezo ya awamu ya 1 na awamu ya 2 na anwani ya chanzo kwenye tiketi. Thamani hizi nne zinaeleza kushindwa kwingi kwa site-to-site bila simu.