IP VPN-кліента ў Kubernetes: захаваць ці зрабіць SNAT?

Дзесьці паміж тунелем і бэкендам адрас кліента альбо выжывае, альбо замяняецца, і абодва вынікі можна абараніць. Выбар належыць уладальніку прымаючага сэрвісу, а не таму, хто ўсталяваў CNI. Калі важныя аўтарызацыя па кожным кліенце, квоты або аўдытарскія запісы, адрас павінен выжыць на кожным кроку. Калі супольнае прыпісванне прымальнае, NAT крыніцы выдаляе праблему маршрутызацыі, якую інакш вы б падтрымлівалі вечна.

Дзе адрас кліента насамрэч знікае

Пакет аддаленага кліента прыбывае ў под VPN з унутранай крыніцай у дыяпазоне тунеля, скажам 10.90.0.42. Калі под перасылае гэты пакет да ClusterIP або IP пода, тры розныя механізмы могуць перапісаць крыніцу. Правіла masquerade CNI вузла пакрывае трафік, які под адпраўляе за межы CIDR кластара. Запіс conntrack kube-proxy на мэтавым вузле пакрывае сам крок да Service. Проксі, якое завяршае злучэнне, зусім не перасылае пакет, таму крыніца, якую вы ў рэшце бачыце, належыць проксі.

Кожны з іх жыве ў розным пласце, таму адно поле Service амаль ніколі не выпраўляе ўвесь шлях.

externalTrafficPolicy на публічным Service VPN вырашае толькі тое, што адбываецца з вонкавым злучэннем: Local захоўвае аддалены адрас на вузле, які яго атрымаў, а Cluster дазваляе kube-proxy перадаць пакет іншаму вузлу і замаскаваць яго там. Гэтая налада кіруе слухачом, да якога падключаюцца вашыя кліенты. Яна нічога не кажа пра дэшыфраваны пакет, які ваш VPN-працэс потым накіроўвае ў кластар.

Тры ўмовы, якія вырашаюць спрэчку

Я задаю тыя ж тры пытанні ў тым жа парадку кожны раз, калі гэта ўзнікае, бо першае звычайна завяршае размову. Адказвайце на іх для канкрэтнай нагрузкі, а не для кластара ў цэлым. Два кластары ў адной кампаніі могуць прыйсці да розных адказаў, і абодва могуць быць правільнымі.

Калі бэкенд адказвае так на першае пытанне і не на другое, у вас ёсць сеткавая праца, а не маніфест для рэдагавання. Калі трэці радок кажа проксі, адрас ніколі не павінен быў выжыць, а выдаваць супрацьлеглае каштуе тыдзень захопу пакетаў.

Што патрабуе рэжым 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

Наступны крок — гэта адрас пода, а адрасы подаў перамяшчаюцца. Накіруйце маршрут на VIP Service або на адрас вузла, які застаецца на месцы, або прызнайце, што будзеце ганяцца за шлюзам пасля кожнага высялення. Фільтраванне зваротнага шляху — іншая пастка: строгі рэжым адкідае пакеты, зваротны шлях якіх не супадае з інтэрфейсам, на які яны прыбылі, і гэта дакладна форма захаванага VPN-плыні.

Слабая валідацыя часта з'яўляецца розніцай паміж працоўным зваротным шляхам і адказамі, якія знікаюць пасля выхаду з бэкенда. Правілы masquerade на вузле VPN таксама павінны выключаць дыяпазон тунеля, інакш перасланы пакет выходзіць з адрасам пода, незалежна ад таго, які маршрут вы пабудавалі. Лепш выказвайце гэта выключэнне ў уласнай канфігурацыі CNI, чым рэдагуйце iptables уручную, бо агент перапісвае свае ланцугі пры перазапуску, і ваша напісанае ўручную правіла жыве дакладна да наступнага абнаўлення.

NetworkPolicy — гэта кантроль доступу, а не маршрутызацыя. Узмацненне палітыкі ніколі не аднавіць адрас, які masquerade ужо замяніў.

Колькі каштуе SNAT і як гэта запісаць

NAT крыніцы да кластара — больш танны дызайн, і гэта не памылка. Бэкенд бачыць адрас пода або вузла VPN, запісы ўзгадняюцца паміж сабой, і зваротны маршрут не павінен існаваць. Тое, што вы губляеце, — гэта здольнасць адрозніць двух кліентаў на сеткавым узроўні, таму квоты, забароны і аўдытарскія сляды павінны прыходзіць аднекуль іншага.

Звычайна гэта «аднекуль іншага» — праграма: токен сесіі, падпісаны загаловак або радок пратакола PROXY, напісаны проксі, якім вы кіруеце. Яны даюць атрымальніку ідэнтычнасць, якой ён можа давяраць толькі тады, калі проксі знаходзіцца на шляху і загаловак нельга ўставіць з боку кліента. Будзьце пэўныя ў runbook, які з іх прымяняецца, бо наступны інжынер будзе меркаваць, што адрас у запісе — гэта кліент. Гэта не так, і аднаго інцыдэнту дастаткова, каб зрабіць гэта дапушчэнне дарагім.

Абмен застаецца сумленным, пакуль ён запісаны.

Праверкі, якія аддзяляюць працоўны шлях ад удачлівага

Тэстуйце з новым злучэннем, а не з кэшаваным, і тэстуйце ў абодвух напрамках. Некалькі збояў выглядаюць перарывістымі толькі таму, што новыя плыні ідуць перапісаным шляхам.

Злавіце tuple у трох пунктах падчас аднаго аўтарызаванага запыту: адразу пасля дэкапсуляцыі, на выхадным інтэрфейсе пода VPN і на бэкендзе. Калі крыніца змяняецца паміж другім і трэцім захопам, прычына ніжэй па плыні ад пода. Калі змяняецца перад другім, сам под перакладае.

Затым выдаліце под VPN і паўтарыце тэст, пакуль ён перапланоўваецца. Захаваны шлях, які ламаецца пры высяленні, незавершаны, і гэтак жа правіла NAT, прывязанае да адраса, якога больш не існуе. Нарэшце, адпраўце адзін запыт з крыніцы, якую чакаеце адхіліць, і пацвердзіце, што адмова ідзе ад палітыкі, а не ад адсутнага маршруту.