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, прив'язане до адреси, якої більше немає. Нарешті, надішліть один запит із джерела, яке, як ви очікуєте, буде відхилено, і підтвердьте, що відмова походить від політики, а не від відсутнього маршруту.