Ano ang nilalaman ng isang panukalang IPsec? Mga field ng IKE at ESP

Nagsisimula ang IKE, inaanunsyo ng dalawang panig ang AES, at nabigo pa rin ang tunnel sa NO_PROPOSAL_CHOSEN. Pinapangalanan ng log ang panukala ngunit hindi ang field na hindi tumugma. Ang panukala ay isang buong alok, at isang hindi tugmang field ang nagpapawalang-bisa sa buong kombinasyon, hindi lang sa linyang iyon. Ang pagbasa nito bilang sako ng mga malayang pagpili ng algorithm ang karaniwang dahilan kung bakit nananatiling hindi nakikita ang hindi pagtutugma.

Dalawang negosasyon na may hiwalay na listahan ng panukala

Bumubuo ang IKEv2 ng dalawang samahang panseguridad. Ang una ay IKE SA, na nagpoprotekta sa palitan ng kontrol mismo, at ang pangalawa ay CHILD SA, na nagdadala ng iyong trapiko sa pamamagitan ng ESP. Bawat isa ay may sariling listahan ng panukala, at maaaring tanggapin ng isang panig ang isa at tanggihan ang isa.

Ipinapaliwanag ng paghahating iyon ang karaniwang kalituhan: ang gumaganang IKE SA ay nagpapatunay lamang na tumugma ang mga algorithm ng control channel. Kung nabigo ang panukalang CHILD, walang dalang pakete ang tunnel kahit natapos ang unang yugto at mukhang malusog ang mga log sa itaas.

Mahalaga rin ang pagkakasunod-sunod sa loob ng bawat listahan. Pumipili ang tumutugon mula sa mga nakaayos na alok ng nagpasimula, kaya ang paglipat ng malawak na tugmang entry sa itaas ng makitid ay nagbabago kung aling suite ang maiinstall nang hindi binabago ang kahit isang pangalan ng algorithm. I-pin ang ayos na iyon sa configuration sa halip na umasa sa mga default. Ginagawa rin ng matatag na ayos na makabuluhan ang paghahambing ng log sa pagitan ng mga site.

Aling mga field ang kabilang sa aling panukala

Maliit ang set ng mga field, ngunit hindi ito magkapareho sa dalawang negosasyon. Basahin ang talahanayan nang hilera-hilera, dahil ang field sa isang hanay ay maaaring wala sa isa. Nag-iiba ang sintaks depende sa implementasyon; ang dokumentasyon ng mga panukala ng strongSwan ay isang konkretong sanggunian.

Pinapangalanan ng field ng encryption ang cipher at, sa karamihan ng sintaks, ang haba ng key nito. Pinapangalanan ng field ng integridad ang hash na ginagamit upang patunayan ang naka-encrypt na teksto, at pinapangalanan ng PRF ang function na kumukuha ng key material para sa IKE SA. Nagtatatag ang DH group ng sariwang shared secret material, kaya lumilitaw ito sa magkabilang panig ngunit para sa magkaibang layunin.

Ang mga pinalawak na sequence number ay kabilang lamang sa data path. Pinapalawak nila ang sequence space at nakikipagnegosasyon bilang bahagi ng panukalang CHILD, kaya ang hindi pagtutugma doon ay tumatanggi sa isang alok na CHILD habang nananatiling hindi ginalaw ang IKE SA.

Paano pinipili ang isang buong alok

Ang bawat panukala ay isang set, at hinahanap ng tumutugon ang set kung saan katanggap-tanggap ang bawat kinakailangang field. Maaaring kapwa naglalaman ng AES at SHA-256 ang dalawang listahan at wala pa ring tugmang entry, dahil magkaiba ang haba ng key, PRF o DH group. Nagaganap ang paghahambing kada panukala, hindi kada algorithm.

Kapag walang tumugma, nagpapadala ang tumutugon ng NO_PROPOSAL_CHOSEN kasama ang uri ng SA na nabigo. Basahin kung aling listahan ng panukala ang tinutukoy ng abiso bago i-edit ang configuration; ang pagpapalit ng mga algorithm ng ESP kapag tinanggihan ang panukalang IKE ay nag-aaksaya ng isang siklo ng pag-debug.

Sulit malaman ang pag-uugali ng pagpili kapag nag-tune ka ng profile. Mas gusto ng ilang implementasyon ang ayos ng nagpasimula, ang iba ay muling nag-aayos ayon sa lokal na patakaran, kaya ang suite na gumagana sa pagitan ng dalawang vendor ay maaaring mawala kapag binaligtad mo kung aling panig ang nagsisimula ng koneksyon.

Tinatanggal ng AEAD ang isang field sa halip na magdagdag ng isa

Pinatutunayan at naka-encrypt ng AES-GCM at ChaCha20-Poly1305 sa isang operasyon. Kapag napili ang alinman sa kanila para sa ESP, hindi hiwalay na nakikipagnegosasyon ang algorithm ng integridad, dahil sakop na ito ng AEAD construction. Kaya ang panukalang nagsasama ng AES-GCM sa SHA-256 ay kalabisan sa pinakamabuti at tinatanggihan sa pinakamasama.

Nananatiling hiwalay ang PRF sa panig ng IKE, dahil kumukuha ito ng mga key para sa control channel sa halip na protektahan ang mga payload. Ito ang dahilan kung bakit maaaring legal na pagsamahin ng isang panukalang IKE ang AEAD cipher sa PRF at DH group, habang ang katumbas na panukalang ESP ay naglilista lamang ng AEAD cipher at opsyonal na PFS group.

Bahagi ng encryption token ang haba ng key, kaya magkaibang alok ang AES-128-GCM at AES-256-GCM. Ang profile na kinopya mula sa gabay na nagpapalagay ng 256-bit na key ay hindi tutugma sa endpoint na naka-configure para sa 128-bit, kahit parehong sinasabi ng dalawang linya ang AES-GCM. Maaaring magkasundo ang dalawang panig sa pamilya ng cipher at tanggihan pa rin ang isa't isa dahil sa numero pagkatapos ng gitling.

Basahin ang naka-install na SA, hindi ang configuration

Ang naka-configure na listahan ng panukala ay alok; ang naka-install na SA ay resulta. Sa strongSwan at Linux kernel, available ang dalawang view:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas ipinapakita ang mga na-negotiate na algorithm kada SA, kasama kung gumagamit ang CHILD ng AEAD. ip xfrm state ipinapakita kung ano talaga ang in-install ng kernel, at doon mo kinukumpirma na ang pag-renew ng key ay hindi bumagsak sa ibang suite kaysa sa naidokumento mo.

I-save ang output na iyon sa tabi ng configuration pagkatapos ng pagwawasto. Kapag binago ng update ng client ang mga default nito, binibigyan ka ng naitalang suite ng baseline para ihambing, at itinuturo ng paghahambing ang field na gumalaw sa halip na simulan muli ang imbestigasyon.