strongSwan-ийн trap горим: IPsec туннель яагаад трафикийг хүлээдэг вэ

Хүсэлтийн дагуу идэвхгүй IPsec туннель пакет түүний trap бодлоготой тохирох хүртэл CHILD SA харуулахгүй. Төлөвийг уншиж, триггерийг шалгаж, start хэзээ тохирохыг мэдээрэй.

Төлөвийн гаралтад CHILD SA гарч ирэхгүй, туннель үхсэн мэт харагдаад дараа нь алслагдсан дэд сүлжээ рүү ping түүнийг өргөдөг. Хүсэлтийн дагуу IPsec тохиргоонд энэ дараалал нь загвар, гэмтэл биш. trap бодлого селектор суулгаад хүлээдэг бөгөөд түүнтэй тохирох эхний пакет IKE болон CHILD SA хэлэлцээрийг эхлүүлдэг.

Төөрөгдлийн нэг хэсэг нь үг хэллэг: «up» хоёр өөр төлөвт хэрэглэгддэг. Тохиргоо ачаалагдсан бөгөөд цөмийн бодлого байна, харин өгөгдлийн холбоо байхгүй. Зөвхөн идэвхтэй SA-г тоолдог монитор нь хэн ч түүн рүү трафик илгээхгүй л бол эрүүл сайтыг унтарсан гэж мэдээлнэ.

Хүсэлтийн дагуу идэвхгүй туннель харуулах CHILD SA байхгүй

trap бичлэг өөрөө юу ч баталгаажуулахгүй. Энэ нь цөмөөс сонгосон трафикийн бодлогыг барих, пакет тухайн бодлогыг шаардах үед acquisition өргөхийг хүсдэг. Демон acquisition-ыг хүлээн авч, child-ийн тодорхойлолттой тааруулж, тэндээс хэлэлцээр хийнэ. Тэр хүртэл харуулах IKE SA ч байхгүй, тиймээс хоёр жагсаалт зэрэг хоосон байж болно.

Энэ дараалал логыг уншигдахуйц болгодог. Эхлээд acquisition ирнэ, дараа нь IKE_SA_INIT ба IKE_AUTH, дараа нь CHILD SA. Лог acquisition-ын дараа шууд дуусвал триггер ажилласан. Хэлэлцээр бүтэлгүйтсэн бөгөөд дараагийн асуулт нь trap биш, бүртгэлийн мэдээлэл, саналууд эсвэл хүртээмжийн тухай юм.

Linux цөмийн backend-ээр та ямар ч SA үүсэхээс өмнө бодлогыг харж болно. Ажиллуулна уу: ip xfrm policy ба out чиглэл, холболт руу заасан загвартай селекторыг хайна уу. Тэр бичлэг бол хүсэлтийн дагуу төлөв бөгөөд түүний оршихуй нь хамгийн түрүүнд баталгаажуулах зүйл юм.

start_action ямар нэг зүйл хүлээх эсэхийг шийддэг

Бүх child swanctl.conf файлд start_action. start тохиргоо ачаалагдах үед эхэлдэг, trap бодлогыг суулгаад хүлээдэг, none эхлэлийг өөр зүйлд үлдээдэг. Зөвхөн trap дээр дурдсан «ping — тэгээд тэр өргөгдөнө» зан төлөвийг үүсгэдэг.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Хоёр трафикийн селектор юу сонирхолтойд тооцогдохыг тодорхойлдог, эдгээр префиксээс гадуур хостноос ирсэн пакет trap-ыг өдөөхгүй; тэр ердийнхөөрөө маршрутлагдана. Триггерийг илүү сонирхолтой болгохын тулд селекторуудыг өргөтгөх нь туннель өөрийгөө хамгаална гэж мэдэгддэг хүрээг ч өргөтгөдөг тул тэдгээрийг та үнэхээр шифрлэхийг хүсч буй трафикаас гарга.

Энд swanctl.conf лавлагаа хүлээн зөвшөөрөгдөх утгуудыг, мөн SA үүссэний дараа юу болохыг зохицуулдаг тусдаа close ба DPD үйлдлүүдийг жагсаав.

Триггер ерөөсөө ажилласан эсэхийг олж мэдээрэй

Эндээс эхэл: swanctl --list-conns ба child таны зорьсон үйлдлээр ачаалагдсаныг баталгаажуулна уу. Дараа нь local_ts дотор байгаа хостноос remote_ts дотор байгаа хаяг руу нэг пакет илгээж, swanctl --list-sas ажиглана уу. Гаралт өөрчлөгдөхгүй бол демонд нэг ч acquisition хүрээгүй.

Чимээгүй trap-ын хоёр түгээмэл шалтгаан: пакет бодлогод хүрэхээс өмнө source-NAT-д орсон бөгөөд одоо local_ts-тай тохирохгүй байна, эсвэл холболт синтаксийн эсвэл бүртгэлийн алдаанаас болж огт ачаалагдаагүй. Селекторуудад хүрэхээс өмнө swanctl --load-all-ыг дахин ажиллуулж, гаралтыг нь уншаарай. Ачаалагдаагүй холболт ямар ч бодлого суулгахгүй тул трафикийн өдөөх зүйл байхгүй.

Чиглэл ч чухал: гадагш чиглэсэн трафикийн trap нь дотогш ирсэн пакет дээр эхлэхгүй. Хэрэв алслагдсан тал туннелийг өргөх ёстой бол түүнд өөрийн trap хэрэгтэй, эсвэл энэ талд start.

Эхний пакетыг хүлээх нь үргэлж зөв солилцоо биш

Интерактив сессүүд тохируулгын зардлыг мэдэрдэг. Эхний хүсэлт IKE солилцоо болон CHILD хэлэлцээрийн төлбөрийг төлдөг бөгөөд богино хугацаатай клиент SA үүсэхээс өмнө бууж өгч болно. Проактив start тэр эхний пакетын саатыг арилгана. Гэхдээ хэзээ ч ирэхгүй байж болох трафикийн төлөө туннелийг өргөсөн байлгана.

Гурван баримт сонголтыг шийднэ: зам хэр олон удаа хэрэглэгддэг, эхний хүсэлтэд чанга хугацаа байгаа эсэх, ачаалах үед peer хүртээмжтэй эсэх. Хааяа багц трафик болон ачаалах үед офлайн байж болох peer хоёулаа trap-ыг дэмждэг. Хоцролтод мэдрэмтгий клиент болон үргэлж хүртээмжтэй peer start-ыг дэмждэг. Хоёр тал эхэлж чадвал давхар хэлэлцээрээс зайлсхийхийн тулд триггер хэнд хамаарахыг тохиролцоорой.

Суулгасан бодлого нь алдагдалаас хамгаалсан баталгаа биш. Хэрэв шаардлага fail-closed бол галт хана SA-гүй трафикийг хаях ёстой бөгөөд тэр дүрэм child-ийн тодорхойлолтоос гадна амьдардаг.

Дараагийн маргааныг дуусгах гурван мөрийг бичээрэй

Селекторууд, эхлүүлэх үйлдэл, SA-гүйгээр бодлого байгааг харуулсан командын гаралтыг бичнэ үү. Тэр гурван мөр дараагийн удаа хэн нэгэн туннелийг унтарсан гэж мэдээлэхэд «хүсэлтийн дагуу ба идэвхгүй» ба «ачаалагдахгүй» хоёрыг ялгана. Бичихэд нэг минут хангалттай. Тэдгээргүйгээр мөнөөх шалгалт тэгээс эхэлнэ.

Селекторын дотор үнэхээр байгаа хостноос туршина уу. Роутероос өөрөөс нь хийсэн ping ихэвчлэн өөр замаар явдаг бөгөөд түүний ард байгаа дэд сүлжээг хамгаалж буй бодлогын талаар юу ч батлахгүй.

Холбоотой нийтлэлүүд