Выяўленне мёртвага партнёра ў IKEv2 не правярае вашу праграму

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

Чытайце два віды доказаў асобна, перш чым мяняць таймер.

Што насамрэч пытае праверка жыццяздольнасці

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

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

Чытайце асацыяцыі бяспекі раней за браўзер

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

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

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

Збой маршруту выглядае гэтак жа, як мёртвы партнёр

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

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

Трымайце таймеры па-за дыягназам

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

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

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