Kubernetes ичиндеги VPN кардарынын IP: аны сактайбызбы же SNAT жасайбызбы?
Kubernetes ичинде VPN кардарынын чыныгы дарегин сактоо менен баштапкы NAT ортосунда үч шарттын негизинде тандаңыз, анан кайтуу жолун жана под алмашуусун текшериңиз.
Туннель менен backend ортосундагы бир жерде кардар дареги же аман калат, же алмаштырылат, жана эки натыйжа тең коргоого болот. Тандоо кабыл алуучу кызматтын ээсине таандык, CNI орноткон адамга эмес. Ар бир кардар боюнча авторизация, квоталар же аудит жазуулары маанилүү болгондо, дарек ар бир секирүүдөн өтүшү керек. Жалпы таандык болуу кабыл алынар болсо, баштапкы NAT болбосо түбөлүк сактай турган маршруттоо маселесин жок кылат.
Кардар дареги чындыгында кайда жоголот
Алыскы кардардын пакети VPN подуна туннель диапазонундагы ички булак менен жетет, айталы, 10.90.0.42. Под бул пакетти ClusterIP же под IP тарапка жибергенде, үч башка механизм булакты кайра жаза алат. Түйүндүн CNI masquerade эрежеси под кластер CIDR-инин сыртына жиберген трафикти камтыйт. Максаттуу түйүндөгү kube-proxy conntrack жазуусу Service секирүүсүнүн өзүн камтыйт. Байланышты токтоткон прокси пакетти такыр жибербейт, ошондуктан акырында көргөн булак проксиге таандык.
Алардын ар бири башка катмарда жашайт, ошондуктан бир Service талаасы бүт жолду дээрлик эч качан оңдобойт.
VPN дин коомдук Service-индеги externalTrafficPolicy сырткы байланышка эмне болорун гана чечет: Local алыскы даректи аны кабыл алган түйүндө кармайт, ал эми Cluster kube-proxy ге пакетти башка түйүнгө берүүгө жана ошол жерде masquerade жасоого уруксат берет. Бул жөндөө кардарларыңыз туташкан listener-ди башкарат. VPN процессиңиз кийин кластерге багыттаган шифры ачылган пакет жөнүндө ал эч нерсе айтпайт.
Талашты чечкен үч шарт
Бул маселе көтөрүлгөндө мен ошол эле үч суроону ошол эле тартипте берем, анткени биринчиси адатта талкууну бүтүрөт. Аларга конкреттүү жумуш жүгү үчүн жооп бериңиз, бүт кластер үчүн эмес. Бир компаниянын ичиндеги эки кластер ар башка жоопторго келиши мүмкүн жана экөө тең туура болушу мүмкүн.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Эгер backend биринчи суроого ооба, экинчисине жок деп жооп берсе, сизде manifest оңдоо эмес, тармак иши бар. Эгер үчүнчү сап прокси десе, дарек эч качан аман калмак эмес, жана тескерисин айтуу бир жума пакет кармоого туура келет.
preserve режими тармактан эмнени талап кылат
Булакты сактоо максаттуу түйүн трафикти активдүү VPN шлюзу аркылуу 10.90.0.42 ге кайтарышы керек дегенди билдирет. 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Кийинки секирүү — под дареги, ал эми под даректери орун которот. Маршрутту Service VIP же ордунда калган түйүн дарегине буруңуз, же ар бир чыгарып жиберүүдөн кийин шлюздун артынан жүгүрөөрүңүздү моюнга алыңыз. Кайтуу жолун чыпкалоо — башка тузак: катуу режим келген интерфейске дал келбеген кайтуу жолу бар пакеттерди таштайт, жана бул сакталган VPN агымынын так формасы.
Бош текшерүү көбүнчө иштеген кайтуу жолу менен backend тен чыккандан кийин жоголгон жооптор ортосундагы айырма. VPN түйүнүндөгү masquerade эрежелери туннель диапазонун да чыгарып салышы керек, болбосо жиберилген пакет кандай маршрут курганыңызга карабастан под дареги менен чыгат. Бул өзгөчөлүктү iptables ти кол менен оңдоонун ордуна CNI нин өз конфигурациясында билдирүүнү артык көрүңүз, анткени агент кайра иштегенде чынжырларын кайра жазат жана кол менен жазган эрежеңиз так кийинки жаңыртууга чейин жашайт.
NetworkPolicy — кирүүнү көзөмөлдөө, маршруттоо эмес. Саясатты катуулатуу masquerade буга чейин алмаштырган даректи эч качан калыбына келтирбейт.
SNAT канча турат жана аны кантип жазуу керек
Кластерге карай баштапкы NAT — арзаныраак долбоор, жана бул ката эмес. Backend VPN подунун же түйүндүн дарегин көрөт, журналдар бири-бирине дал келет жана эч кандай кайтуу маршруту болушу шарт эмес. Сиз жоготкон нерсе — эки кардарды тармак катмарында ажыратуу жөндөмү, ошондуктан квоталар, тыюулар жана аудит изилдери башка жерден келиши керек.
Адатта ошол башка жер — колдонмо: сессия токени, кол коюлган аталыш же сиз көзөмөлдөгөн прокси жаза турган PROXY протоколунун сабы. Булар кабыл алуучуга прокси жолдо турганда жана аталышты кардар тараптан коюу мүмкүн болбогондо гана ишенүүгө боло турган инсандыкты берет. Runbook та кайсынысы колдонулаарын так жазыңыз, анткени кийинки инженер журналдагы даректи кардар деп ойлойт. Андай эмес, жана бир окуя бул божомолду кымбат кылууга жетишет.
Алмашуу жазылган бойдон ынсаптуу бойдон калат.
Иштеген жолду ийгиликтүү жолдон ажырата турган текшерүүлөр
Кэштелген байланыш менен эмес, жаңы байланыш менен сынаңыз жана эки багытта тең сынаңыз. Бир нече ката жаңы агымдар кайра жазылган жол менен жүргөндүктөн гана үзгүлтүктүү көрүнөт.
Бир уруксат берилген сурам учурунда tuple ды үч чекитте кармаңыз: дешифрлөөдөн кийин дароо, VPN подунун чыгуу интерфейсинде жана backend те. Эгер булак экинчи жана үчүнчү кармоонун ортосунда өзгөрсө, себеби поддон төмөн. Эгер экинчиден мурун өзгөрсө, под өзү которуп жатат.
Анан VPN подду жок кылыңыз жана кайра пландаштыруу учурунда тестти кайталаңыз. Чыгарып жиберүүдө сынган сакталган жол бүтө элек, эми жок дарекке бекитилген NAT эрежеси да ошондой. Акырында, баш тартылат деп күткөн булактан бир сурам жибериңиз жана баш тартуу жетишпеген маршруттан эмес, саясаттан келерин ырастаңыз.