Kio eniras IPsec-proponon? Kampoj de IKE kaj ESP

IKE ekas, ambaŭ partneroj anoncas AES, kaj la tunelo tamen malsukcesas per NO_PROPOSAL_CHOSEN. La protokolo nomas la proponon sed ne la kampon, kiu ne kongruis. Propono estas unu kompleta oferto, kaj unu nekompatibla kampo malvalidigas la tutan kombinaĵon, ne nur tiun linion. Legi ĝin kiel sako da sendependaj elektoj de algoritmoj estas la kutima kialo, ke la malkongruo restas nevidebla.

Du intertraktadoj kun apartaj listoj de proponoj

IKEv2 konstruas du sekurecajn asociojn. La unua estas la IKE SA, kiu protektas la kontrolinterŝanĝon mem, kaj la dua estas la CHILD SA, kiu portas vian trafikon tra ESP. Ĉiu havas sian propran liston de proponoj, kaj partnero povas akcepti unu kaj malakcepti la alian.

Tiu disiĝo klarigas oftan konfuzon: funkcianta IKE SA pruvas nur, ke la algoritmoj de la kontrola kanalo kongruis. Se la propono CHILD malsukcesas, la tunelo portas neniun paketon, eĉ kiam la unua fazo finiĝis kaj la protokoloj supre aspektas sanaj.

Ankaŭ la ordo ene de ĉiu listo gravas. La respondanto elektas el la ordigitaj ofertoj de la iniciatinto, do movi larĝe kongruan eron super mallarĝa ŝanĝas, kiun aron oni instalos, sen ŝanĝi iun ajn algoritman nomon. Fiksu tiun ordon en la agordo anstataŭ fidi al la defaŭltoj. Stabila ordo ankaŭ igas senca la komparadon de protokoloj inter retejoj.

Kiuj kampoj apartenas al kiu propono

La kampoaro estas malgranda, sed ĝi ne estas identa en la du intertraktadoj. Legu la tabelon linio post linio, ĉar kampo en unu kolumno povas manki en la alia. La sintakso varias laŭ la efektivigo; la propona dokumentaro de strongSwan estas unu konkreta referenco.

La kampo pri ĉifrado nomas la ĉifron kaj, en la plej multaj sintaksoj, ĝian ŝlosillongon. La kampo pri integreco nomas la haketon uzatan por aŭtentigi la ĉifrotekston, kaj la PRF nomas la funkcion, kiu derivas ŝlosilmaterialon por la IKE SA. La DH-grupo establas freŝan komunan sekretan materialon, kaj tial ĝi aperas ambaŭflanke sed por malsamaj celoj.

Etenditaj sinsekvaj numeroj apartenas nur al la datenvojo. Ili larĝigas la sinsekvan spacon kaj estas intertraktataj kiel parto de la propono CHILD, do malkongruo tie malakceptas oferton CHILD dum la IKE SA restas netuŝita.

Kiel unu kompleta oferto estas elektata

Ĉiu propono estas aro, kaj la respondanto serĉas aron, en kiu ĉiu postulata kampo estas akceptebla. Du listoj povas ambaŭ enhavi AES kaj SHA-256 kaj tamen havi neniun kongruan eron, ĉar la ŝlosillongo, la PRF aŭ la DH-grupo diferencas. La komparo okazas po propono, ne po algoritmo.

Kiam nenio kongruas, la respondanto sendas NO_PROPOSAL_CHOSEN kun la SA-tipo, kiu malsukcesis. Legu, al kiu proponolisto la sciigo rilatas, antaŭ ol redakti la agordon; ŝanĝi la algoritmojn de ESP kiam la propono IKE estis malakceptita malŝparas ciklon de sencimigado.

Valoras scii la elektan konduton kiam vi agordas profilon. Kelkaj efektivigoj preferas la ordon de la iniciatinto, aliaj reordigas laŭ loka politiko, do aro, kiu funkcias inter du vendistoj, povas malaperi kiam vi inversigas, kiu flanko komencas la konekton.

AEAD forigas kampon anstataŭ aldoni unu

AES-GCM kaj ChaCha20-Poly1305 aŭtentigas kaj ĉifras en unu operacio. Kiam iu el ili estas elektita por ESP, la integreca algoritmo ne estas intertraktata aparte, ĉar la konstruaĵo AEAD jam kovras ĝin. Propono, kiu kunigas AES-GCM kun SHA-256, estas do plejbone superflua kaj plejmalbone malakceptita.

La PRF restas aparta ĉe la flanko de IKE, ĉar ĝi derivas ŝlosilojn por la kontrola kanalo anstataŭ protekti utilajn ŝarĝojn. Tial propono IKE povas laŭleĝe kombini AEAD-ĉifron kun PRF kaj DH-grupo, dum la responda propono ESP listigas nur la AEAD-ĉifron kaj la laŭvolan PFS-grupon.

Ŝlosillongo estas parto de la ĉifrada ĵetono, do AES-128-GCM kaj AES-256-GCM estas malsamaj ofertoj. Profilo kopiita el gvidilo, kiu supozis 256-bit ŝlosilojn, ne kongruos kun finpunkto agordita por 128-bit, eĉ kiam ambaŭ linioj diras AES-GCM. Du partneroj povas interkonsenti pri la ĉifra familio kaj tamen malakcepti unu la alian pro la numero post la streketo.

Legu la instalitan SA, ne la agordon

La agordita listo de proponoj estas oferto; la instalita SA estas la rezulto. Sur strongSwan kaj Linux-kerno, ambaŭ vidpunktoj haveblas:

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

swanctl --list-sas presas la intertraktatajn algoritmojn po SA, inkluzive ĉu la CHILD uzas AEAD. ip xfrm state montras, kion la kerno efektive instalis, kaj tio estas la loko por konfirmi, ke ŝlosilrenovigo ne refalis al alia aro ol tiu, kiun vi dokumentis.

Konservu tiun eligon apud la agordo post riparo. Kiam klienta ĝisdatigo ŝanĝas siajn defaŭltojn, la registrita aro donas al vi bazlinion por kompari, kaj la komparo montras la kampon, kiu moviĝis, anstataŭ rekomenci la esploron de la komenco.