NAT илрүүлэлт нэг асуултад хариулдаг: замд хаяг эсвэл портууд өөрчлөгдсөн үү? Галт хана IP 50 протоколыг зөвшөөрөх эсэхэд хариулдаггүй. Ямар ч хөрвүүлэлтгүй сайтын гарцууд native ESP-г хаядаг бодлогын ард байж болох бөгөөд энэ шаардлагыг илрүүлэхийн оронд тохируулах ёстой. Механизм нь ESP-in-UDP бөгөөд энэ нь өөрөө гарч ирдэг нөөц хувилбар биш, шийдвэр юм.

Илрүүлэлт нь хаяг дээрх арифметик, галт хананы шалгалт биш

IKEv2 нь NAT илрүүлэлтийн ачааг дамжуулдаг бөгөөд эх болон очих хаяг, портын хэшийг агуулна. Тал бүр хүлээн авснаа локалд харж буйтай харьцуулж, зөрүү нь пакетыг ямар нэг зүйл хөрвүүлснийг хэлнэ. Тэр солилцоонд дундах маршрутлагч 50 протоколыг дамжуулах эсэхийг шалгах зүйл байхгүй.

Практик үр дагаврыг шууд хэлэх нь зүйтэй. native ESP-тэй ажиллаж байсан туннель шинэ хязгаарлалттай галт ханыг өөрөө илрүүлэхгүй бөгөөд IKE үргэлжлүүлэн амжилттай байх үед дараагийн оролдлого нь өгөгдлийн шатанд бүтэлгүйтнэ. Та тогтоосон IKE аюулгүй байдлын холбоог харах бөгөөд хамгаалагдсан урсгал байхгүй, энэ нь утсан дээр барих хүртэл маршрутлалтын алдаа мэт харагдана.

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

encap солилцоог хэрхэн өөрчлөх

Орчин үеийн strongSwan байршуулалтад, үүнийг swanctl.conf -ээр удирддаг, холболт дээрх encap = yes тохиргоо нь NAT илрүүлэлтийн солилцоонд нөлөөлж, хоёр тал ESP-д UDP инкапсуляци ашиглана. Хамгаалагдсан пакетууд дараа нь UDP дотор, ихэвчлэн 4500 порт дээр явж, хоёр төгсгөл энэ зохицуулалтад санал нэгдэх ёстой.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Тэр хэсэг нь бодит холболтын тодорхойлолт дотор хамаарах бөгөөд бүрэн сайтын профайл биш. Таны аль хэдийн ажиллуулж буй пээрийн хаяг, баталгаажуулалт, child урсгалын сонгогчийг хадгал; нэмсэн ганц түлхүүр нь хамгаалагдсан өгөгдөл хэрхэн боогдохыг өөрчилдөг, юунаас хамгаалахыг биш.

strongSwan-ы NAT-traversal гарын авлага энэ зан төлөвийг тайлбарладаг, MOBIKE ашиглах үед портын хөвөлттэй харилцан үйлчлэлийг оруулан.

Өөрийн backend-т хамаарах тохиргоог ашигла

strongSwan нь хоёр тохиргооны backend-тай бөгөөд түлхүүр нь тэдгээрийн хооронд ялгаатай. swanctl.conf холболт encap авдаг бол хуучин ipsec.conf холболт forceencaps авдаг. Нэг backend-ийн түлхүүр үгийг нөгөөд хийх нь гомдолгүй ачаалагдаж, юу ч өөрчлөхгүй тохиргоог үүсгэдэг бөгөөд энэ нь алдаанаас ч дор.

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

Өөрчлөлтийг холболтын эзэмшигчээр дамжуулан хэрэглэж, ассоциацийг хяналттай цонхонд дахин тогтоо. Аль хэдийн суулгасан child солигдох хүртэл одоогийн инкапсуляцаа хадгалдаг тул зөвхөн файл засах нь шинэ зохицуулалт ашиглагдаж байгааг нотлохгүй.

Боосон өгөгдлийг шалга, зөвхөн портыг биш

Хамгаалагдсан урсгал урсаж байх үед гарц дээр барьж, дараа нь strongSwan-ы өөрийн харагдацатай харьцуул:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP нь IP 50 протокол хэлбэрээр гарч, UDP-тэй огт төстэй биш. Боосон ESP нь 4500 дээр UDP датаграм хэлбэрээр гарч, тэдгээрийн ачаа IKE биш. Мөн порт дээрх IKE урсгал нь инкапсуляцийн баталгаа биш, учир нь MOBIKE IKE-г тэнд зөөж болох ба өгөгдлийн зам native хэвээр үлддэг, тиймээс портын дугаарыг биш ачааг унш.

Замын MTU-г ч сана. Бүрхүүл нэмэлт зардал нэмж, native ESP зөөж байсан зам пакетууд өсөхөд тохируулга шаардаж болно. Шаардлагатай ICMP боловсруулалт дизайны нэг хэсэг байх ёстой; инкапсуляци тэр хамаарлыг арилгахгүй.

Туннель доторх шинэ аппликейшн урсгал хоёр төгсгөлд боосон ESP хэлбэрээр барилтад харагдаж, дотоод үйлчилгээ болон түүний буцах зам ажиллаж байгаа үед өөрчлөлтийг хүлээн ав. Үүнээс бага нь файлд зөв харагдах тохиргоо юм.

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