Pse tuneli juaj IPsec funksionon deri në rinovimin e parë të çelësit CHILD SA

Tuneli u ngrit, ping-u u përgjigj dhe të gjithë firmosën. Katër orë më vonë sesioni bie, palët regjistrojnë një gabim propozimi ose shkëmbimi çelësash, dhe hamendja e parë është se diçka ndryshoi në rrjet. Asgjë nuk ndryshoi. Një tunel që transporton trafik ka vërtetuar se dy palët bien dakord si të autentikohen dhe si të mbrojnë shoqatën e parë bijë, dhe nuk ka vërtetuar asgjë për shkëmbimin e çelësave që do të kërkojnë në rinovim. Mospërputhja qëndron në boshllëkun midis këtyre dy ngjarjeve.

I lidhur nuk do të thotë që cilësimet PFS përputhen

Me IKEv2, shoqata e parë bijë krijohet gjatë shkëmbimit të autentikimit, dhe çelësat e saj nxirren nga materiali që shoqata IKE ka prodhuar tashmë. Për atë bijë nuk ndodh një shkëmbim i veçantë Diffie-Hellman, prandaj një politikë që kërkon një të tillë në rinovim nuk provohet në ngritje.

Rinovimi është një shkëmbim tjetër. Kur çelësi i një shoqate bijë rinovohet, palët mund të kryejnë një shkëmbim të ri çelësash me grupin e përmendur në propozimet e tyre, dhe ai është momenti i parë kur cilësimet e grupit krahasohen. Prandaj dy palë që nuk bien dakord mund të autentikohen, të instalojnë një shoqatë bijë dhe të kalojnë trafikun, dhe më pas të dështojnë në rinovim.

Ku fshihet mospërputhja në vargun e propozimit

Në strongSwan grupi i shtohet propozimit bijë, prandaj një varg si aes256gcm16-prfsha256-ecp256 duket si zgjedhje kriptimi por mbart edhe një kërkesë për shkëmbim çelësash. Një palë që ofron vetëm aes256gcm16-prfsha256 nuk ka një kërkesë të tillë, dhe dy listat priten në kriptim por ndryshojnë në shkëmbim.

Lexoni propozimin bijë dhe propozimin IKE si lista të veçanta. Një grup që shfaqet në listën IKE nuk thotë asgjë për listën bijë, dhe redaktimi i njërës ndërsa lexoni tjetrën është mënyra e zakonshme si kjo humbet.

Lexoni dështimin, jo skedarin që redaktuat

Gjeni notify-in që përfundoi shkëmbimin. Riçelësimi bijë që kthen «asnjë propozim i pranueshëm» tregon listat e propozimeve; kërkesa për rinovim që nuk merr kurrë përgjigje tregon rrugën ose një palë që ndaloi së dëgjuari. Këto dy kërkojnë rregullime të ndryshme, dhe formulimi i rreshtit të logut i ndan.

Konfirmoni konfigurimin që po ekzekutohet, jo atë në disk. Një skedar i ruajtur por i palexuar, ose një lidhje e rilexuar nga një include tjetër, do të prodhojnë një mospërputhje që asnjë redaktim i skedarit të dukshëm nuk mund ta rregullojë.

Tre ngjarje që të gjithë i quajnë rinovim çelësi

Rinovimi i çelësit të shoqatës IKE, riautentikimi IKE dhe rinovimi i çelësit të shoqatës bijë janë operacione të veçanta me rregulla propozimi të veçanta. Një dështim i raportuar në njërën prej tyre nuk thotë asgjë drejtpërdrejt për të tjerat, dhe një log që i përzie ka lexohet si një defekt i vetëm i përsëritur kur janë tre.

Vini re cilën ngjarje përmend pala, pastaj kontrolloni propozimet vetëm për atë ngjarje. Ndryshoni një listë, riloadoni dhe detyroni sërish të njëjtën ngjarje. Nëse logu përmend një riautentikim, propozimi IKE është ai që duhet lexuar. Nëse përmend një rinovim çelësi bijë, propozimi bijë mbart grupin që ka rëndësi.

Fikja e rinovimit nuk është rregullim

Vendosja e kohës së rinovimit në zero shtyp shkëmbimin që dështon, dhe tuneli më pas mbijeton derisa të çmontohet ose pala të rindizet. Ajo që keni blerë është një çelës më jetëgjatë dhe një mospërputhje që do t'ju gjejë sërish gjatë një migrimi, një auditimi ose një përditësimi nga furnizuesi. E njëjta gjë vlen për jetëgjatësitë e zgjatura shumë përtej politikës që pret pala tjetër.

Në vend të kësaj, rreshtoni propozimet. Zgjidhni një grup që të dy palët e implementojnë, vendoseni në propozimin bijë në të dy skajet, dhe mbani politikën e rinovimit brenda intervalit që organizata kërkon vërtet.

Vërtetojeni me shkëmbimin që dështoi

Shkurtoni kohën e rinovimit të çelësit bijë në një dritare mirëmbajtjeje që ngjarja të vijë në minuta e jo në orë, ose nisni një rinovim manual. Më pas vëzhgoni një rinovim të suksesshëm dhe konfirmoni që trafiku vazhdon përmes tij, sepse një shtrëngim duarsh i ri që instalon një shoqatë bijë por hedh poshtë rrjedhën e aplikacionit është një defekt tjetër.

Më pas rikthejeni jetëgjatësinë normale dhe ruani të dy regjistrimet e ngjarjeve, atë të dështuar dhe atë të suksesshëm. Prova që dëshironi është se lidhja i mbijeton ciklit të vetë jetës, jo se i mbijetoi një ping.