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