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 закачено за адреса што повеќе не постои. На крајот испратете едно барање од извор за кој очекувате да биде одбиен и потврдете дека одбивањето доаѓа од политика, а не од рута што недостасува.