Kubernetes ішіндегі VPN клиентінің IP: оны сақтаймыз ба әлде SNAT жасаймыз ба?
Kubernetes ішінде VPN клиентінің нақты мекенжайын сақтау мен бастапқы NAT арасында үш шарт бойынша таңдаңыз, содан кейін қайтару жолын және под ауысуын тексеріңіз.
Туннель мен backend арасындағы бір жерде клиент мекенжайы не аман қалады, не алмастырылады, және екі нәтиже де қорғауға болады. Таңдау қабылдаушы қызметтің иесіне тиесілі, CNI орнатқан адамға емес. Әр клиент бойынша авторизация, квоталар немесе аудит жазбалары маңызды болғанда, мекенжай әрбір секіруден өтуі керек. Ортақ телу қолайлы болғанда, бастапқы 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 режимі желіден не талап етеді
Көзді сақтау мақсатты түйін трафикті белсенді VPN шлюзі арқылы 10.90.0.42-ге қайтаруы керек дегенді білдіреді. 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 подының немесе түйіннің мекенжайын көреді, журналдар бір-бірімен сәйкеседі және ешқандай қайтару маршруты болуы міндетті емес. Сіз жоғалтатын нәрсе — екі клиентті желі қабатында ажырату қабілеті, сондықтан квоталар, тыйымдар және аудит іздері басқа жерден келуі керек.
Әдетте ол басқа жер — қосымша: сессия токені, қол қойылған тақырыпша немесе сіз басқаратын прокси жазатын PROXY протоколының жолы. Бұлар қабылдаушыға прокси жолда болғанда және тақырыпшаны клиент жағынан орнату мүмкін болмағанда ғана сенуге болатын сәйкестілік береді. Runbook-та қайсысы қолданылатынын нақты жазыңыз, өйткені келесі инженер журналдағы мекенжайды клиент деп ойлайды. Олай емес, және бір оқиға бұл болжамды қымбат етуге жетеді.
Айырбас жазылған күйде адал болып қалады.
Жұмыс істейтін жолды сәтті жолдан ажырататын тексерулер
Кэштелген қосылыммен емес, жаңа қосылыммен сынаңыз және екі бағытта да сынаңыз. Бірнеше ақау тек жаңа ағындар қайта жазылған жолмен жүргендіктен үзілісті болып көрінеді.
Бір рұқсат етілген сұраныс кезінде tuple-ды үш нүктеде ұстаңыз: дешифрлеуден кейін бірден, VPN подының шығу интерфейсінде және backend-те. Егер көз екінші мен үшінші ұстау арасында өзгерсе, себебі подтан төменде. Егер екіншіден бұрын өзгерсе, подтың өзі аударып жатыр.
Содан кейін VPN подты жойыңыз және қайта жоспарлау кезінде тестті қайталаңыз. Шығарып жіберу кезінде сынатын сақталған жол аяқталмаған, енді жоқ мекенжайға бекітілген NAT ережесі де солай. Соңында, бас тартылуын күтетін көзден бір сұраныс жіберіңіз және бас тарту жетіспейтін маршруттан емес, саясаттан келетінін растаңыз.