strongSwan ESP-in-UDP: wakati hakuna NAT ya kutambua

Utambuzi wa NAT hupata tafsiri ya anwani, si sera ya firewall. Muunganisho wa tovuti bila NAT bado unaweza kuhitaji chaguo bayana la ESP-in-UDP.

Utambuzi wa NAT hujibu swali moja: je, anwani au bandari zimebadilika njiani? Hujibu kama firewall inaruhusu itifaki ya IP 50. Malango ya tovuti yasiyokuwa na tafsiri yoyote bado yanaweza kuwa nyuma ya sera inayotupa native ESP, na hitaji hilo linapaswa kusanidiwa badala ya kugunduliwa. Utaratibu ni ESP-in-UDP, na ni uamuzi, si njia mbadala inayojitokeza yenyewe.

Utambuzi ni hesabu kwenye anwani, si uchunguzi wa firewall

IKEv2 hubeba mizigo ya utambuzi wa NAT yenye hashi za anwani na bandari za chanzo na lengwa. Kila upande hulinganisha kilichopokelewa na kile kinachokiona kienyeji, na kutokulingana humwambia kuwa kitu kilitafsiri pakiti. Hakuna kitu katika mabadilishano hayo kinachojaribu kama kipanga njia kilicho katikati kinasambaza itifaki 50.

Matokeo ya kivitendo yanafaa kusemwa moja kwa moja. Handaki iliyofanya kazi na native ESP haitagundua firewall mpya yenye vikwazo yenyewe, na jaribio lake lifuatalo litashindikana katika hatua ya data wakati IKE inaendelea kufanikiwa. Utaona vyama vya usalama vya IKE vilivyoanzishwa na hakuna trafiki iliyolindwa, jambo ambalo linaonekana kama hitilafu ya uelekezaji hadi unapokamata kwenye waya.

Kwa hiyo ufungashaji ni sifa ya muunganisho unaosanisha, si matokeo ambayo pande hujadiliana kutokana na tabia ya mtandao.

Jinsi encap inavyobadilisha mabadilishano

Katika usambazaji wa kisasa wa strongSwan unaosimamiwa kupitia swanctl.conf, mpangilio encap = yes kwenye muunganisho huathiri mabadilishano ya utambuzi wa NAT ili pande zote mbili zitumie ufungashaji wa UDP kwa ESP. Pakiti zilizolindwa kisha husafiri ndani ya UDP, kwa kawaida kwenye bandari 4500, na ncha zote mbili lazima zikubaliane na mpangilio huo.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Kipande hicho ni cha ndani ya ufafanuzi halisi wa muunganisho na si wasifu kamili wa tovuti. Weka anwani za mwenzako, uthibitishaji na vichaguzi vya trafiki child unavyoendesha tayari; ufunguo mmoja ulioongezwa hubadilisha jinsi data iliyolindwa inavyofungwa, si kile inacholinda.

Mwongozo wa strongSwan wa NAT-traversal unaeleza tabia hii, ikiwa ni pamoja na mwingiliano na bandari inayoelea wakati MOBIKE inatumiwa.

Tumia mpangilio ambao ni wa backend yako

strongSwan ina backend mbili za usanidi, na ufunguo unatofautiana kati yao. swanctl.conf muunganisho huchukua encap, wakati wa zamani ipsec.conf muunganisho huchukua forceencaps. Kuweka neno la ufunguo la backend moja ndani ya lingine hutoa usanidi unaopakiwa bila malalamiko na haubadilishi chochote, jambo ambalo ni baya kuliko hitilafu.

Angalia ni daemon gani inaendesha kweli kabla ya kuhariri chochote. Katika usambazaji wengi faili zote mbili zipo kwa sababu moja ni mabaki ya uhamishaji wa awali, na inayotumika ni ile ambayo kitengo cha huduma huanzisha. Soma kitengo hicho badala ya kukisia kutokana na mihuri ya muda ya faili. Ukaguzi wa sekunde tano hapa huzuia saa nyingi za kujaribu mpangilio ambao hakuna kitu kilipakia.

Tumia mabadiliko kupitia mmiliki wa muunganisho na uanzishe tena muungano katika dirisha linalodhibitiwa. Child iliyowekwa tayari huhifadhi ufungashaji wake wa sasa hadi ibadilishwe, kwa hiyo kuhariri faili pekee hakuthibitishi kuwa mpangilio mpya unatumika.

Thibitisha data iliyofungwa, si bandari pekee

Kamata kwenye lango wakati trafiki iliyolindwa inapita, kisha linganisha na mtazamo wa strongSwan wenyewe:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP inaonekana kama itifaki ya IP 50 na haifanani kabisa na UDP. ESP iliyofungwa inaonekana kama datagramu za UDP kwenye 4500 ambazo mzigo wake si IKE. Trafiki ya IKE kwenye bandari hiyo hiyo si uthibitisho wa ufungashaji, kwa sababu MOBIKE inaweza kuhamisha IKE hapo wakati njia ya data inabaki native, kwa hiyo soma mzigo, si namba ya bandari.

Kumbuka pia MTU ya njia. Kifuniko huongeza gharama ya ziada, na njia iliyobeba native ESP inaweza kuhitaji marekebisho pakiti zinapokua. Utunzaji wa ICMP unaohitajika unapaswa kuwa sehemu ya muundo tayari; ufungashaji hauondoi utegemezi huo.

Kubali mabadiliko wakati trafiki mpya ya programu ndani ya handaki inaonekana kwenye kamata kama ESP iliyofungwa katika ncha zote mbili, na wakati huduma ya ndani na njia yake ya kurudi bado zinafanya kazi. Kitu chochote kidogo ni usanidi unaoonekana sawa kwenye faili.

Makala zinazohusiana