IPsec з некалькімі падсеткамі губіць зваротны трафік? Падлічыце reqid

Трафік пакідае адну пляцоўку і ніколі не вяртаецца, абодва шлюзы паведамляюць пра завершанае ўзгадненне, а адзіная зачэпка — куча выходных пакетаў без адказаў. На канчатковай кропцы Linux звычайная прычына — не трываласць шыфравання, MTU ці табліца маршрутызацыі. Гэта гранулярнасць запісаў палітыкі і нумар, які звязвае кожную палітыку з асацыяцыяй бяспекі. Прыведзеная ніжэй працэдура чытае гэтыя дзве базы, перш чым кранаць што-небудзь яшчэ.

Падзяліце сімптом, перш чым нешта мяняць

Аднабаковы збой з завершаным узгадненнем IKE звужае праблему да шляху даных. Або выходная палітыка супала і адказ адкінулі, або адказ зусім не прыйшоў, бо ў іншага боку не было чым яго адправіць. Для праграмы абодва выпадкі выглядаюць аднолькава, а базы xfrm іх адрозніваюць.

Не пачынайце з MTU. Няправільны MTU дае заміранні і сімптомы фрагментацыі, а не чыстае раздзяленне напрамкаў з растучымі лічыльнікамі выходных пакетаў.

Прачытайце базу палітык і базу станаў

У Linux шыфраванне вызначаюць запісы палітыкі, таму адпаведная палітыка, а не маршрут, уводзіць пакет у тунэль. Запусціце ip xfrm policy, каб убачыць селектары, напрамак, прыярытэт і шаблон кожнага запісу, і ip xfrm state, каб убачыць усталяваныя асацыяцыі з іх reqid. Палітыка і асацыяцыя злучаны гэтым reqid.

Паглядзіце на ўсе тры напрамкі. Выходны і ўваходны ахопліваюць трафік да гэтага вузла і ад яго; напрамак перасылкі важны, калі вузел маршрутызуе за іншых. Адсутны або няўзгоднены запіс у адным напрамку тлумачыць аднабаковы вынік без любой крыптаграфічнай памылкі.

Класічная асіметрыя: адзін reqid на некалькі падсетак

Частая памылка паходзіць ад партнёра, які ўсталёўвае палітыкі для ўсіх узгодненых падсетак пад адным reqid, што бывае з generate_policy require у racoon. Трафік тады выходзіць праз асацыяцыю, усталяваную апошняй, а іншы бок трымае асобную асацыяцыю на кожную падсетку. Адказы прыходзяць на асацыяцыю, чый reqid не ўказвае на палітыку, якая мусіла б іх прыняць, і ядро адкідвае іх пасля расшыфроўкі.

Выпраўленне — гэта змена канфігурацыі, а не правіла міжсеткавага экрана: generate_policy unique; дае кожнай палітыцы ўласны reqid, так што асацыяцыі партнёра на кожную палітыку маюць адпаведных партнёраў. Прымяніце гэта, узгадніце нанова і падлічыце розныя reqid для чаканых падсетак, перш чым абвясціць поспех.

Калі дзве падсеткі ўсё яшчэ дзеляць адзін reqid, а іншы бок чакае два, вы знайшлі асіметрыю. Запішыце адпаведнасць, бо гэта доказ таго, што наступная змена яе выправіла ці захавала.

Селектары паходзяць з узгаднення, а не з вашай канфігурацыі

Абароненыя дыяпазоны — гэта тое, пра што дамовіліся абодва бакі, а не тое, што запытаў адзін з іх. Кліент, які прапануе пару вузлоў супраць шырокага выдаленага дыяпазону, атрымлівае звужаную версію шлюза і не можа яе пашырыць. Чытайце ўсталяваныя селектары, а не тыя, што ў вашым лакальным файле.

Калі мэта адваротная — пакінуць адно прызначэнне па-за тунэлем, дадайце палітыку абыходу з меншым нумарам прыярытэту, каб яна перамагла аўтаматычна ўсталяваны запіс. Палітыка без шаблону дазваляе адкрыты тэкст, што робіць яе ўсвядомленым выключэннем для журнала змен, а не крокам адладкі.

Правярайце ў гэтым парадку і ведайце, як адкаціцца

Пералічыце палітыкі для кожнай падсеткі ў абодвух напрамках, уключаючы перасылку, калі вузел маршрутызуе. Падлічыце розныя reqid і пацвердзіце па адным на палітыку на тым баку, які яго чакае. Параўнайце ўсталяваныя селектары з узгодненымі. Пасля абнаўлення ключа перачытайце лічыльнікі па асацыяцыях, бо правераная асацыяцыя магла ўжо знікнуть. Маршруты правярайце апошнімі, бо адсутны маршрут да выдаленай падсеткі дае падобны аднабаковы сімптом з чыстымі лічыльнікамі палітыкі.

Перад змяненнем партнёра захавайце бягучы вывад абедзвюх каманд xfrm. Калі новы параметр не верне зваротны напрамак, аднаўленне гэтага вываду — хутчэйшы адкат, чым перазборка тунэля з памяці, і яно захоўвае сумленнае параўнанне.