strongSwan дахь бүрэн тунель хоёр талд 0.0.0.0/0 шаардана

Бүрэн тунельд клиентийн remote_ts болон гарцын local_ts-д 0.0.0.0/0, мөн дамжуулалт, NAT, буцах зам шаардлагатай. Дөрвийг бүгдийг шалгана уу.

Нэг хувийн дэд сүлжээнд ажилладаг strongSwan холболт хэн нэгэн нэг мөр зассан учраас л интернетийн урсгалыг зөөхгүй. Бүрэн тунель гэдэг нь child SA ямар хаягийг хамгаалах тухай хоёр талын тохиролцоо бөгөөд тал бүр нөгөө талыг өөртөө харьцуулан нэрлэдэг. Нэг талыг зөв, нөгөөг буруу болговол child SA эсвэл босохгүй, эсвэл санаж байснаас нарийн босно. Доорх таван шалгалт энэ тохиролцоог клиентээс гарцаар дамжуулан интернет хүртэл дагана.

Эхлээд клиентийн селекторыг шалгана уу

Клиент алслагдсан талд юу хамгаалахыг remote_ts гэж тодорхойлдог бөгөөд илгээсэн бүхэн нь өөрт нь олгогдсон хаягаас гардаг. Интернетийн урсгалын хувьд энэ утга хэрэглэгчийн бодитоор хүрэх газруудыг хамарч, бодит байдал дээр бүх IPv4 огторгуйг илэрхийлнэ. Нэг дэд сүлжээг л жагсаасан клиент интерфейс дэх профайлын нэр юу ч байсан хуваагдсан тунелийг хүсч байна. Эх тал нь ихэвчлэн dynamic байдаг, учир нь хаяг холбогдох үед олгогддог. Тэнд бичсэн тогтмол эх хаягийн сан өөрчлөгдмөгц эвдэрдэг.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Энэ хэсэг нь бүрэн холболтын файл биш бөгөөд нэвтрүүлэлт, таних тэмдэг, виртуал хаягийн сан аль хэдийн тохируулагдсан гэж үздэг. Клиентийн эх селектор болон серверийн олгох хаяг хоёр талын хэний ч хүлээгээгүй хүрээтэй child SA босохгүйн тулд тохирох ёстой. Үүнийг swanctl --load-all ашиглан ачаад амжилт гэж үзэхийн өмнө гаралтыг уншина уу. Парслагддаг файл нь нөгөө талын саналтай давхцахгүй селекторын улмаас татгалзагдаж болно.

Гарцын селекторыг өөрийн талд нь шалгана уу

Гарц ижил ойлголтыг эсрэг чиглэлээс уншдаг. Интернетийн очих газрууд гарцад орон нутгийнх тул түүний local_ts нь өргөн нь, remote_ts нь клиентийн санг тодорхойлно. Энэ урвуулалт нь бүрэн-тунелийн тохиргоонд хамгийн түгээмэл алдаа бөгөөд хоёр мөр тус тусдаа үнэмшилтэй харагддаг учраас хяналтаас гардаг.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Клиентийн хэсгийг гарцын файл руу хуулах нь хоёр тал ижил үүргийг шаардах тул ямар ч ашигтай зүйлийг тодорхойлохгүй селекторын хос үүсгэдэг. strongSwan-ий дамжуулалтын гарын авлага клиент ба гарцын хослолыг тодорхой баримтжуулдаг бөгөөд үүнийг бүтэлгүйтлийн дараа биш, холболтын файлын хажууд унших нь зүйтэй. Гарцын файлд мөн remote_ts заасан сангийн тодорхойлолт хэрэгтэй. Байхгүй санг нэрлэсэн селектор гомдолгүй ачаалагдаж, холбогдох үед бүтэлгүйтдэг.

Хуучин ipsec.conf нь өөр түлхүүртэй зүүн, баруун үүргийг ашигладаг бөгөөд rightsubnet мөр нь swanctl утгын шууд орлуулалт биш юм. Хоёр синтаксийг нэгийг нөгөөд нь наахын оронд тусдаа файлд хадгална уу. Тэдгээрийг нэг хавтаст холих нь ажиллаж байсан холболт дахин ачаалалтын дараа чимээгүй буцах зам юм.

Файлыг биш, тохиролцсон child SA-г шалгана уу

Хадгалсан тохиргоо нь зорилгыг л баталж, өөр юу ч биш. Нөгөө тал хүссэнийг нарийсгаж болох бөгөөд одоо байгаа child SA нь доорх файл өөрчлөгдсөн учраас л солигдохгүй. Өөр юу ч өөрчлөхийн өмнө бодитоор юу суулгасан болохыг батална уу.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Эхний команд нь демон юу ачаалсныг, хоёр дахь нь тогтоосон child SA-г, гурав дахь нь цөм хэрэглэх бодлогуудыг харуулна. Хэрэв файл 0.0.0.0/0 гэж хэлж, жагсаалт нэг дэд сүлжээ харуулбал хэлэлцээр хүрээг нарийсгасан бөгөөд файлыг дахин унших нь үүнийг тайлбарлахгүй. child-г зогсоож, дахин эхлүүлж, гурван гаралтыг дахин харьцуулна уу. Ижил нарийн хүрээтэй буцаж ирсэн child нь орон нутгийн файлаар биш, алслагдсан талаар нарийсдаг бөгөөд энэ нь орон нутгийн засвар биш, нөгөө администратортой хийх яриа юм.

Бодлогын жагсаалтад хоёр чиглэлийг уншина уу, учир нь нэг чиглэлийг суулгаж нөгөөг суулгадаггүй тунель нь тохиргооны хувцастай маршрутлалтын асуудал юм. Урагш ба буцах бодлогууд ижил селекторын хосыг толин тусгал хэлбэрээр нэрлэх ёстой бөгөөд дутуу толь нь селекторын текстэд биш, демон эсвэл саналд гарсан алдаа.

Дамжуулалт ба буцах замыг шалгана уу

Селектор урсгалыг гарц руу нэвтрүүлдэг боловч гарцыг тэр урсгалыг цааш маршрутлахыг албаддаггүй. Дамжуулалт идэвхтэй байх, галын хана урсгалыг зөвшөөрөх, хариулт клиентийн сан руу буцах замаа олох ёстой. Эдгээр нь гурван тусдаа шаардлага бөгөөд тус бүр өөр шинж тэмдгээр бүтэлгүйтдэг. Дутуу дамжуулалтын дүрэм хар нүх шиг аашилдаг бол дутуу буцах маршрут нэг чиглэлийн тунель шиг.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Хувийн клиентийн хаягууд ихэвчлэн нийтийн интерфейсээс гарахын өмнө зориудын эх орчуулга шаарддаг бол тодорхой маршрутлагдсан хуваарилалт өөр харьцаа шаарддаг. Хэрэв NAT оролцож байгаа бол хэрэгжүүлэлтийн дэмждэг үл хамаарах зүйлсийг хадгалж, аюулгүй байдлын бодлого шалгах ёстой урсгал түүний хажуугаар орчуулагдахгүй байх ёстой. Өөр гарцаас хуулсан өргөн masquerade дүрэм зохиогчийн санаж байснаас хамаагүй илүү урсгалыг өөрчилдөг. Дүрмийг зөвхөн клиентийн санд зориулж бичээд, яагаад байгааг тайлбарласан тайлбар үлдээнэ үү.

Клиент дээр таамагласан маршрутуудыг биш, backend-ийн суулгасан маршрутуудыг батална уу. Маршрут суулгах нь идэвхгүй менежерт гараар арчилдаг маршрутлалтын загвар хэрэгтэй бөгөөд тунель өөрчлөгдөх бүрт тэр загварыг шинэчлэх ёстой. Маршрутлалтын хүснэгтийг дахин холбогдсоны дараа шалгана уу, зөвхөн шинэ ачаалалтын дараа биш.

Тунель одоо ч юу хамрахгүй байгааг шалгана уу

Селекторын хос IPv4-г л хамардаг, өөр юу ч биш. IPv6, DNS болон аливаа програмын түвшний бодлого нь өргөн IPv4 селекторын чимээгүй үл тоомсорлодог тусдаа шийдвэрүүд юм. IPv4 пакет бүрийг зөөдөг тунель ч нэр бүрийн хайлтыг алдаж болно.

Зорьсон DNS замыг тодорхой зааж өгнө үү, учир нь нэрийг орон нутгийн шийдэгчээр шийдсээр байгаа бүрэн тунель асуултуудыг тунелиас гадагш алдаж, хувийн нэрсийг эвддэг. Хэрэв клиентэд IPv6 хаяг олгогдвол тэр хаягийн бүлэгт ижил харьцаа хэрэгтэй, эс бөгөөс хост тунелийн хамгаалдаггүй замд давуу эрх өгнө. Зөвхөн хувийн тал хариулж чадах нэрээр туршиж, нийтийн хариултыг алдагдал гэж үзнэ үү.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Дээрх жагсаалтаас тохиролцсон селекторуудын хамт эдгээр хоёр командаар гинжийг батална уу. Хэрэв traceroute орон нутгийн маршрутлагчийг эхний үсрэлт гэж харуулбал селекторууд юу ч гэсэн урсгал тунелийг ашиглахгүй байна. Интернетийн хандалт нь сонгосон урсгал зохион бүтээсэн гарцаар нэвтрэгдэж, дамжуулагдаж, буцаж ирсэн үед л бүрэн болно. Профайлаас 0.0.0.0/0 олдох нь тэр гинжийн эхлэл бөгөөд түүний баталгаа биш.

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