Wat staan in 'n IPsec-voorstel? IKE- en ESP-velde

IKE begin, beide eweknieë adverteer AES, en die tonnel misluk steeds met NO_PROPOSAL_CHOSEN. Die log noem die voorstel maar nie die veld wat nie gepas het nie. 'n Voorstel is 'n volledige aanbod, en een onversoenbare veld maak die hele kombinasie ongeldig eerder as net daardie reël. Om dit as 'n sak onafhanklike algoritme-keuses te lees, is die gewone rede waarom die wanpassing onsigbaar bly.

Twee onderhandelinge met afsonderlike voorstel-lyste

IKEv2 bou twee sekuriteitsassosiasies. Die eerste is die IKE SA, wat die beheersuitruiling self beskerm, en die tweede is die CHILD SA, wat jou verkeer deur ESP dra. Elkeen het sy eie voorstel-lys, en 'n eweknie kan een aanvaar en die ander verwerp.

Daardie splitsing verduidelik 'n algemene verwarring: 'n werkende IKE SA bewys net dat die beheerkanaal-algoritmes gepas het. As die CHILD-voorstel misluk, dra die tonnel nooit 'n pakket nie, selfs al is fase een voltooi en lyk die logs heel bo gesond.

Die volgorde binne elke lys maak ook saak. Die respondent kies uit die inisieerder se geordende aanbiedinge, so om 'n breed aanvaarbare inskrywing bo 'n eng een te skuif, verander watter suite geïnstalleer word sonder om enige algoritme-naam te verander. Pen daardie volgorde in die konfigurasie vas eerder as om op verstekke te vertrou. 'n Stabiele volgorde maak ook logvergeliking tussen terreine betekenisvol.

Watter velde aan watter voorstel behoort

Die veldstel is klein, maar dit is nie tussen die twee onderhandelinge identiek nie. Lees die tabel ry vir ry, want 'n veld in een kolom kan in die ander ontbreek. Sintaks verskil per implementering; strongSwan se voorstel-dokumentasie is een konkrete verwysing.

Enkripsie noem die syfer en, in meeste sintakse, sy sleutellengte. Integriteit noem die hash wat gebruik word om die syferteks te verifieer, en die PRF noem die funksie wat sleutelmateriaal vir die IKE SA aflei. Die DH-groep vestig vars gedeelde geheime materiaal, wat die rede is waarom dit aan beide kante verskyn maar vir verskillende doeleindes.

Uitgebreide volgordenommers behoort net aan die datapad. Hulle verbreed die volgorde-ruimte en word as deel van die CHILD-voorstel onderhandel, so 'n wanpassing daar verwerp 'n CHILD-aanbod terwyl die IKE SA onaangeraak bly.

Hoe een volledige aanbod gekies word

Elke voorstel is 'n stel, en die respondent soek 'n stel waar elke vereiste veld aanvaarbaar is. Twee lyste kan albei AES en SHA-256 bevat en steeds geen versoenbare inskrywing hê nie, want die sleutellengte, die PRF of die DH-groep verskil. Die vergelyking gebeur per voorstel, nie per algoritme nie.

Wanneer niks pas nie, stuur die respondent NO_PROPOSAL_CHOSEN met die SA-tipe wat gefaal het. Lees na watter voorstel-lys die kennisgewing verwys voordat jy die konfigurasie wysig; om die ESP-algoritmes te verander wanneer die IKE-voorstel verwerp is, mors 'n ontfoutingsiklus.

Seleksiegedrag is die moeite werd om te ken wanneer jy 'n profiel instel. Sommige implementerings verkies die inisieerder se volgorde, ander herrangskik volgens plaaslike beleid, so 'n suite wat tussen twee verskaffers werk, kan verdwyn wanneer jy omkeer watter kant die verbinding begin.

AEAD verwyder 'n veld eerder as om een by te voeg

AES-GCM en ChaCha20-Poly1305 verifieer en enkripteer in een bewerking. Wanneer enige van hulle vir ESP gekies word, word die integriteitsalgoritme nie afsonderlik onderhandel nie, want die AEAD-konstruksie dek dit reeds. 'n Voorstel wat AES-GCM met SHA-256 paar, is dus op sy beste oortollig en op sy slegste verwerp.

Die PRF bly steeds apart aan die IKE-kant, want dit lei sleutels vir die beheerkanaal af eerder as om vragte te beskerm. Dit is waarom 'n IKE-voorstel wettig 'n AEAD-syfer met 'n PRF en 'n DH-groep kan kombineer, terwyl die ooreenstemmende ESP-voorstel net die AEAD-syfer en die opsionele PFS-groep lys.

Sleutellengte is deel van die enkripsietoken, so AES-128-GCM en AES-256-GCM is verskillende aanbiedinge. 'n Profiel wat uit 'n gids gekopieer is wat 256-bit sleutels aanvaar het, sal nie pas by 'n eindpunt wat vir 128-bit s'n gekonfigureer is nie, selfs al sê albei reëls AES-GCM. Twee eweknies kan oor die syferfamilie saamstem en mekaar steeds verwerp oor die nommer ná die streep.

Lees die geïnstalleerde SA, nie die konfigurasie nie

Die gekonfigureerde voorstel-lys is 'n aanbod; die geïnstalleerde SA is die resultaat. Op strongSwan en 'n Linux-kern is albei aansigte beskikbaar:

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

swanctl --list-sas druk die onderhandelde algoritmes per SA, insluitend of die CHILD AEAD gebruik. ip xfrm state wys wat die kern werklik geïnstalleer het, wat die plek is om te bevestig dat 'n herstelute nie na 'n ander suite teruggeval het as die een wat jy gedokumenteer het nie.

Stoor daardie uitset langs die konfigurasie ná 'n regstelling. Wanneer 'n kliëntopdatering sy verstekke verander, gee die opgetekende suite jou 'n basislyn om teen te vergelyk, en die vergelyking wys na die veld wat geskuif het in plaas daarvan om die ondersoek van voor af te begin.