Jūsų IKEv2 SA veikia, bet vaikinės SA nėra: perskaitykite mainus

IKE sako, kad tunelis veikia, vaikinės SA nėra, ir abu teiginiai gali būti teisingi tuo pačiu metu. Nustatytas valdymo ryšys nėra duomenų asociacija, ir abu objektai turi atskirus gyvavimo laikus, derybas ir gedimo režimus. Pirmąjį pranešti kaip ryšį yra kelias, kuriuo bilietas galiausiai tvirtina, kad tunelis veikia, o niekas neveikia. Skaitykite asociacijų sąrašą, o ne jungties suvestinę etiketę, nes tas sąrašas yra vienintelė vieta, kur trūkstamas objektas matomas. Toliau pateikiama tvarka, kuria sąrašas įgyja prasmę.

Dvi asociacijos, du darbai

IKE SA neša valdymo kanalą: tapatybes, raktus ir pasiūlymus pačiam valdymo mainui. Vaikinė SA neša ESP apsaugą su savo algoritmais ir savo srauto parinkikliais. Autentifikacija ir vaikinės SA kūrimas paprastai eina kartu, nes pirmoji vaikinė SA deramasi IKE_AUTH viduje, ir būtent šis sujungimas stebina žmones dėl atskyrimo.

Tai taip pat paaiškina dvi gedimų formas, su kuriomis susidursite. Pradinių mainų metu atmesta vaikinė SA paprastai nusitraukia ir IKE SA, todėl jokio nustatyto valdymo kanalo nematote. Vieniša IKE SA dažniau reiškia, kad pirmoji vaikinė SA pavyko, o vėlesnis bandymas sukurti vaikinę SA nepavyko, pavyzdžiui, raktų atnaujinimo metu. Laiko žymos tuos atvejus atskiria greičiau nei bet kokia konfigūracijos peržiūra.

Kuris sluoksnis atsisakė

Kai vaikinė SA atmetama, pranešimas įvardija sluoksnį. Pasiūlymo atmetimas reiškia, kad šalys nesusitarė dėl algoritmų, dažnai todėl, kad viena reikalauja kitos tobulo persiuntimo slaptumo grupės arba šifro, kurio kita nepriims. Parinkiklio atmetimas reiškia, kad srauto rinkinys buvo atmestas tiesiogiai, ir tai yra aprėpties argumentas, o ne kriptografinis.

Kartais vaikinės SA nebuvimas yra pats dizainas. IKE SA be vaikinės SA yra apibrėžtas plėtinys, naudojamas ten, kur duomenų asociacija turi būti sukuriama pagal poreikį, todėl nebuvimas yra teisingas, o vaikinė SA atsiranda, kai atvyksta atitinkamas srautas. strongSwan pastabos apie IKEv2 apima ir poreikio stilių, ir pasiūlymo nustatymus, kurie lemia pirmąjį atvejį.

Prieš diagnozuodami gedimą patikrinkite, ar nėra poreikio ar spąstų konfigūracijos. Jei vaikinės SA kuriamos tingiai, vaikinės SA nebuvimas ramybėje yra laukiama būsena, ir tikrasis bandymas yra tai, ar srautas pakelia vieną. Šis bandymas taip pat atskiria tingų dizainą nuo tylaus gedimo, nes nepavykęs kūrimas palieka trigerį be atsakymo, o ne tiesiog ramybėje.

Tada klauskite apie duomenų kelią

Kai vaikinė SA egzistuoja, į kitą klausimą atsako skaitikliai. ip -s xfrm state praneša paketų ir baitų skaičių kiekvienai asociacijai, ir vaikinė SA, kuri nieko neneša, kai generuojate srautą, rodo derinimą ar maršrutizavimą, o ne į trūkstamą asociaciją. swanctl --list-sas išspausdina vaikinės SA parinkiklius šalia tų skaitiklių, ir būtent tai patvirtina, kad paketas yra priimtame rinkinyje.

Laikykite ataskaitoje atskirai sėkmingą autentifikaciją ir nepavykusius vaikinės SA mainus. Ataskaita, kuri sako, kad autentifikacija nepavyko, siunčia kitą inžinierių į sertifikatų saugyklą, o tikslus sakinys yra daug trumpesnis: IKE SA pakilo, o šio srauto vaikinė SA niekada nebuvo priimta.

Suderinkite abu galus

Jei serverį administruojate patys, paimkite tos pačios mainų sesijos kliento ir vartų žurnalus, o ne lyginkite du prisijungimo bandymus su valandos skirtumu. Pranešimai turėtų sutapti abiejose pusėse, o ten, kur nesutampa, radote neteisingai sukonfigūruotą pusę.

Ištaisykite vaikinės SA derybas, tada dar kartą išbandykite su srautu numatytame parinkiklyje. Tai vienintelis bandymas, įrodantis, kad trūkstamas objektas dabar yra, nes ramybėje atnaujintas asociacijų sąrašas gali atrodyti vienodai prieš pataisymą ir po jo.