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 наредбе. Ако нова поставка не обнови повратни смер, враћање тог излаза је бржи повратак од поновне изградње тунела по сећању и одржава поређење поштеним.