Kubernetes доторх VPN клиентийн IP: хадгалах уу эсвэл SNAT хийх үү?
Гурван нөхцөлд үндэслэн Kubernetes дотор VPN клиентийн жинхэнэ хаягийг хадгалах эсвэл эх үүсвэрийн NAT ашиглахыг сонгоод, буцах замыг болон подын солилцоог шалгана.
Туннел ба backend-ийн хооронд хаа нэгтээ клиентийн хаяг эсвэл амьд үлддэг, эсвэл солигддог бөгөөд хоёр үр дүн нь хамгаалагдах боломжтой. Сонголт нь хүлээн авах үйлчилгээний эзэнд хамаарах бөгөөд CNI-г суулгасан хүнд биш. Клиент тус бүрийн зөвшөөрөл, квот эсвэл аудитын бүртгэл чухал үед хаяг нь алхам бүрийг давах ёстой. Хамтарсан attributions хүлээн зөвшөөрөгдөх үед эх үүсвэрийн NAT нь өөрөөр мөнхөд хадгалах байсан чиглүүлэлтийн асуудлыг арилгадаг.
Клиентийн хаяг үнэхээр хаана алга болдог вэ
Алсын клиентийн пакет VPN под руу туннелийн хүрээ доторх дотоод эх үүсвэртэйгээр ирдэг, жишээ нь 10.90.0.42. Под энэ пакетыг ClusterIP эсвэл подын IP руу дамжуулахад гурван өөр механизм эх үүсвэрийг дахин бичиж болно. Зангилааны CNI-ийн masquerade дүрэм нь под клстерийн CIDR-ээс гадагш илгээдэг трафикийг хамардаг. Очих зангилаа дээрх kube-proxy-ийн conntrack бичлэг нь Service-ийн алхмыг өөрөө хамардаг. Холболтыг дуусгадаг прокси пакетыг огт дамжуулдаггүй тул эцэст нь харж буй эх үүсвэр нь проксид хамаарна.
Тэдгээр нь тус бүр өөр давхаргад амьдардаг тул Service-ийн нэг талбар бүх замыг бараг хэзээ ч засдаггүй.
VPN-ийн нийтийн Service дээрх externalTrafficPolicy нь зөвхөн гадаад холболтод юу тохиолдохыг шийддэг: Local нь алсын хаягийг хүлээн авсан зангилаа дээр үлдээдэг бол Cluster нь kube-proxy-д пакетыг өөр зангилаанд өгч, тэнд masquerade хийхийг зөвшөөрдөг. Энэ тохиргоо нь таны клиентүүд холбогддог listener-ийг удирддаг. Энэ нь таны VPN процесс дараа нь клстерт чиглүүлдэг тайлагдсан пакетын талаар юу ч хэлдэггүй.
Маргааныг шийддэг гурван нөхцөл
Энэ асуудал гарах бүрт би ижил гурван асуултыг ижил дарааллаар асуудаг, учир нь эхнийх нь ихэвчлэн хэлэлцүүлгийг дуусгадаг. Тэдэнд тодорхой ажлын ачаалалд хариул, бүх клстерийн хувьд биш. Нэг компанийн доторх хоёр клстер өөр хариултад хүрч, хоёулаа зөв байж болно.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Хэрэв backend эхний асуултад тийм, хоёр дахь асуултад үгүй гэж хариулбал танд манифест засах биш сүлжээний ажил байна. Гурав дахь мөр прокси гэж хэлбэл, хаяг хэзээ ч амьд үлдэхгүй байсан бөгөөд эсрэгээр нь хэлэх нь долоо хоногийн пакет барилтад хүргэдэг.
Preserve горим сүлжээнээс юу шаарддаг
Эх үүсвэрийг хадгалах гэдэг нь очих зангилаа трафикийг 10.90.0.42 руу идэвхтэй VPN гарцаар буцаах ёстой гэсэн үг. VPN-ийн сан нь клстерийн CIDR биш тул ямар ч CNI таны оронд өгөгдмөлөөр чиглүүлдэггүй. Та зам хөлийг өөрөө нэмж, дараа нь түүний зааж буй гарцын төгсгөлийн цэг дахин төлөвлөлтийг давахыг баталгаажуулна.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Тэр дараагийн алхам нь подын хаяг бөгөөд подын хаягууд шилждэг. Замыг Service-ийн VIP эсвэл байрандаа үлддэг зангилааны хаяг руу чиглүүл, эсвэл гаргах бүрийн дараа гарцыг мөшгихөө хүлээн зөвшөөр. Урвуу замын шүүлт нь нөгөө урхи: хатуу горим нь ирсэн интерфэйстэй нь тохирохгүй буцах замтай пакетуудыг хаядаг бөгөөд энэ нь яг хадгалагдсан VPN урсгалын хэлбэр юм.
Сул баталгаажуулалт нь ажилладаг буцах зам ба backend-ээс гарсны дараа алга болдог хариултуудын хоорондын ялгаа байх нь элбэг. VPN зангилааны masquerade дүрмүүд мөн туннелийн хүрээг хасах ёстой, эс бөгөөс дамжуулсан пакет ямар зам барьсанаас үл хамааран подын хаягтайгаар гарна. Энэ хасалтыг iptables-ийг гараар засахын оронд CNI-ийн өөрийн тохиргоонд илэрхийлэх нь дээр, учир нь агент дахин эхлэхдээ гинжээ дахин бичдэг бөгөөд таны гараар бичсэн дүрэм дараагийн шинэчлэлт хүртэл л амьдардаг.
NetworkPolicy нь нэвтрэх хяналт бөгөөд чиглүүлэлт биш. Бодлогыг чангатгах нь masquerade-ийн аль хэдийн сольсон хаягийг хэзээ ч сэргээхгүй.
SNAT нь юуны үнэтэй, үүнийг хэрхэн бичих вэ
Клстер рүү чиглэсэн эх үүсвэрийн NAT нь илүү хямд загвар бөгөөд энэ нь алдаа биш. Backend нь VPN под эсвэл зангилааны хаягийг хардаг, бүртгэлүүд хоорондоо нийцдэг, буцах зам байх шаардлагагүй. Таны алддаг зүйл бол хоёр клиентийг сүлжээний түвшинд ялгах чадвар тул квот, хориг, аудитын мөрүүд өөр газраас ирэх ёстой.
Ихэвчлэн тэр өөр газар нь аппликейшн: сессийн токен, гарын үсэгтэй header эсвэл таны хянадаг проксины бичсэн PROXY протоколын мөр. Эдгээр нь хүлээн авагчид зөвхөн прокси зам дээр байх үед, header-ийг клиентийн талаас тохируулах боломжгүй үед итгэж болох таних тэмдэг өгдөг. Runbook-д аль нь хамаарахыг тодорхой бич, учир нь дараагийн инженер бүртгэл дэх хаягийг клиент гэж таамаглана. Тийм биш бөгөөд нэг тохиолдол энэ таамаглалыг үнэтэй болгоход хангалттай.
Солилцоо нь бичигдсэн л бол шударга хэвээр байна.
Ажилладаг замыг азтай замаас ялгадаг шалгалтууд
Кэшлэсэн биш шинэ холболтоор турш, хоёр чиглэлд турш. Хэд хэдэн алдаа нь зөвхөн шинэ урсгалууд дахин бичигдсэн зам руу явдаг тул завсарлагатай мэт харагддаг.
Нэг зөвшөөрөгдсөн хүсэлтийн үеэр tuple-ийг гурван цэгт барь: тайлалтын дараа шууд, VPN подын гарах интерфэйс дээр, backend дээр. Хэрэв эх үүсвэр хоёр ба гурав дахь барилтын хооронд өөрчлөгдвөл шалтгаан подын доогуур байна. Хэрэв хоёр дахьаас өмнө өөрчлөгдвөл под өөрөө орчуулж байна.
Дараа нь VPN подыг устгаж, дахин төлөвлөгдөж байх үед тестийг давт. Гаргах үед эвдэрдэг хадгалагдсан зам нь дутуу бөгөөд байхгүй болсон хаягт бэхлэгдсэн NAT дүрэм ч мөн адил. Эцэст нь татгалзахыг хүлээж буй эх үүсвэрээс нэг хүсэлт илгээж, татгалзал нь дутуу замаас биш бодлогоос ирж буйг батал.