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, закачено за адрес, който вече не съществува. Накрая изпратете една заявка от източник, който очаквате да бъде отказан, и потвърдете, че отказът идва от политика, а не от липсващ маршрут.