FortiGate Azure түлхүүр шинэчлэл: peer SA санал орон нутгийн бодлоготой тохирохгүй байна
Ажиллаж буй IKEv2 туннель ч солих CHILD SA-г татгалзаж болно. Шинэчлэл үнэхээр хэлэлцдэг саналыг харьцуулна уу, эхний ping ашигласан саналыг биш.
Туннель босч, урсгал урсаж, дараа нь лог дээр peer SA proposal not match local policy гэж гарна. Ихэнх хүмүүс энэ мөрийг хоёр тохиргоо хэзээ ч тохирч байгаагүйн баталгаа гэж уншдаг. Ихэвчлэн энэ нь илүү нарийн утгатай: тэд эхний CHILD SA-д тохирч, эхний шинэчлэлд тохирохоо больсон, учир нь эхний холбоос дараагийнхан хийдэг солилцоог хэзээ ч шаардаагүй. Яг энэ ялгаа нь хаанаас харахыг тодорхойлдог.
Эхний CHILD SA өвлөнө, дараагийнхан хэлэлцэнэ
IKEv2-д анхны CHILD SA нь IKE_AUTH үед үүсдэг бөгөөд түүний түлхүүрүүд IKE SA-ийн түлхүүрийн материалаас үүсдэг. Тэр мөчид тусдаа Diffie-Hellman солилцоо байхгүй тул нэг peer хүлээж авахгүй PFS бүлэг одоохондоо шалгагдахгүй. Туннель эрүүл харагдаж байгаа шалтгаан нь та дараа нь бүтэлгүйтэх шаардлага хэзээ ч шалгагдаж байгаагүй юм.
CHILD_SA түлхүүр шинэчлэл нь өөр мессежийн дараалал юм. PFS тохируулагдсан үед peer-үүд шинэ түлхүүр солилцоо хийдэг бөгөөд хоёр талын хүлээж авах бүлэг, мөн шинэ холбоосын ESP саналын талаар тохиролцох ёстой. Яг тэр мөчид зөрчил илэрдэг бөгөөд алдаа нь маршрут биш саналыг нэрлэдэг шалтгаан нь энэ юм.
Тиймээс «өчигдөр ажиллаж байсан» нь саналын талаар танд юу ч хэлэхгүй. Энэ нь анхны солилцоо амжилттай болсныг хэлнэ, үүнийг та аль хэдийн мэдэж байсан.
Бүтэлгүйтсэн солилцоог уншаарай, эхний ping-ийг биш
Ямар нэг зүйлийг өөрчлөхөөс өмнө хоёр талаас амжилттай IKE баталгаажуулалт, анхны CHILD SA, бүтэлгүйтсэн солилтыг цуглуул. Дараа нь үйлдлийг нарийн нэрлэ: IKE SA түлхүүр шинэчлэл, IKE дахин баталгаажуулалт, CHILD SA түлхүүр шинэчлэл нь гурван өөр үйл явдал бөгөөд «2-р үе» өдөр тутмын ярианд бүгдийг нь хамардаг.
Доорх талбаруудыг бүтэлгүйтсэн холболтын хувьд харьцуул, туннелийн хувьд ерөнхийдөө биш.
| Давхарга | Харьцуулах утгууд |
|---|---|
| IKE | Хувилбар, шифрлэлт ба бүрэн бүтэн байдал эсвэл PRF зохион байгуулалт, DH бүлэг |
| IPsec / CHILD | ESP шифрлэлт ба бүрэн бүтэн байдал, төлөвлөсөн PFS эсвэл түлхүүр солилцооны бүлэг |
| Хамгаалагдсан урсгал | Орон нутгийн болон алсын сонгогчид, мөн бодлогод суурилсан аливаа сонгогчийн тохиргоо |
FortiGate дээр тухайн туннелийн 2-р үеийн санал, PFS тохиргоо, хүлээн авсан DH бүлгүүдийг нээ. Өмнө нь үүссэн холболтоос таамаглахын оронд ачаалагдсан утгуудыг унш. GUI хуудасны дэлгэцийн зураг ажиллаж буй тохиргооноос сул нотолгоо, учир нь шинэчлэлтийн дараа хоёулаа зөрж болно. Өөрчилсөн хэсгээ экспортолж, тикеттэй хамт хадгал.
Azure-ийн өгөгдмөл бодлого ч бодлого хэвээр
Холболтод тохируулсан бодлого хавсаргаагүй нь Azure юу ч хэрэглэхгүй гэсэн үг биш. Холболт нь гарцын өгөгдмөл саналын багц руу буцдаг бөгөөд энэ нь таны FortiGate санал болгож буйгаас өргөн эсвэл нарийн байж болно. Хэрэв хоёр багц IKE-д давхцаж, PFS-тэй ESP-д давхцахгүй бол, яг энэ бүтэлгүйтлийн хэв маягийг авна.
Энэхүү зөвхөн унших харагдац нь нууцыг задлахгүйгээр бодитоор хавсаргасан бодлогыг харуулна:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesРесурсынхаа жинхэнэ нэрсийг ашигла. Тодорхой бодлого шаардлагатай үед холболтын нөөц дээр тавь. Энэ нь бүх гарцын унтраалга биш бөгөөд нэг гарц дээрх бусад туннельд чимээгүйгээр үйлчлэхгүй.
Портал дээр Configuration хуудас нь тухайн холболтын тохируулсан IPsec/IKE бодлого байрлах газар. Microsoft-ын тохируулсан бодлогын гарын авлага дэмжигдсэн параметрүүд болон SKU шаардлагыг жагсаана. Azure холболт бүрт нэг бүрэн хослол авдаг тул IKE талбар болон IPsec талбарыг хамт зааж өгнө, нэг нэгээр биш.
PFS бол шаардлага, эргүүлэх унтраалга биш
Хэрэв таны аюулгүй байдлын суурь шугам PFS шаарддаг бол шийдэл нь хоёр талд хоёр peer хүлээн авах бүлгийг тохирох бодлогоор илэрхийлэх явдал юм. Алдаа арилахын тулд PFS-ийг унтраах нь та хадгалахыг оролдож байсан аюулгүй байдлын шинж чанарыг өөрчилдөг бөгөөд энэ нь ихэвчлэн дараа нь өөр зөрчлийн хэлбэрээр буцаж ирдэг.
Azure-д онцгой нэг урхи: ESP-д GCM сонгохдоо шифрлэлт болон бүрэн бүтэн байдлын сонголтууд ижил GCM алгоритм, ижил түлхүүрийн уртыг нэрлэх ёстой. GCM шифрийг тусдаа бүрэн бүтэн байдлын алгоритмтай холих нь үйлчилгээний татгалздаг хослолыг үүсгэдэг бөгөөд бодлогыг анхааралтай уншиж дуустал энэ нь peer хоорондын зөрчил мэт харагддаг.
Хоёр төгсгөл дэмжиж, таны шаардлага зөвшөөрсөн хамгийн хүчтэй хослолыг сонгоод, өөрчлөлтийн бүртгэлд бич. Дараагийн хүн тэр бүртгэлтэй харьцуулна, ажиллаж байсан туннелийн дурсамжтай биш. Түүнд PFS бүлэг болон ESP саналыг оруул, зөвхөн бодлогын нэрийг биш. Дараа нь хэн нэгэн аудит яагаад бүтэлгүйтсэн, шинэчлэл яагаад удаан гэж асуухад тэр мөр хоёр асуултад хариулна.
Бүтэлгүйтсэн солилцоог баталгаажуул
Бодлогыг засах нь засаж байгаа туннелийг тасалдуулж болзошгүй тул өөрчлөлтийг сэргээх замтайгаар төлөвлө. Урсгал буцаж ирсний дараа CHILD_SA шинэчлэлийг хүлээ эсвэл өдөөж, шинэ холбоос төлөвлөсөн PFS бүлэгтэй үүссэнийг баталгаажуул. Дараа нь аппын урсгал түүгээр үргэлжилж байгааг баталгаажуул.
Хоёр хуурамч ул мөрийг нэрлэх нь зүйтэй. SA-ийн амьдрах хугацаа нь орон нутгийн үзүүлэлт тул тэгш бус утгууд хэвийн бөгөөд тэдгээрийг өөрчлөх нь асуудал хэзээ илрэхийг л зөөнө. DPD нь peer амьд эсэхийг илрүүлдэг; хугацааны хязгаарыг өсгөх нь ESP эсвэл PFS сонголтыг зэрэгцүүлэхгүй.
Өөрчлөлтийн дараах хэлэлцсэн үр дүн болон дараагийн үйл явдлыг бүртгэ. Хэрэв холболт одоо IKE баталгаажуулалт дуусахаас өмнө бүтэлгүйтвэл та дөнгөж зассан IKE тохиргоог харж байна, анхны CHILD шинэчлэлийн бүтэлгүйтлийг биш.