GKE pod-тары VPN арқылы жергілікті хосттарға неге жетпейді

Ping тораптан жұмыс істейді, pod-тан істемейді, және жергілікті жаққа ештеңе жетпейді. Туннель мен маршрут дұрыс; сымдағы бастау көзінің мекенжайы дұрыс емес. Бұл екі жағдайдың айырмашылығы — пакет кластерден шыққанда өзін кім деп таныстыратынында, және GKE-тің бұл туралы өз пікірі бар. Механизм — masquerade ерекшеліктерінің тізімі, оны оқуға бір команда жетеді.

Бірдеңені өзгертуден бұрын қолданыстағы тізімді оқыңыз

GKE әр меже диапазоны бойынша pod трафигі шығу кезінде торап мекенжайына қайта жазыла ма, соны шешетін агентті жеткізеді. Оның әдепкі конфигурациясы үш RFC1918 блогын, 10.0.0.0/8, 172.16.0.0/12 және 192.168.0.0/16, ерекшелік межелері ретінде атайды. Сондықтан pod-тан жергілікті 10.x хостқа жібергеннің бәрі тораптан pod-тың өз мекенжайымен шығады. Тораптың өз трафигі қайта жазылмайды, дәл сондықтан оның ping-і жұмыс істейді.

Көзделген конфигурация мен орнатылған ережелерді оқыңыз, өйткені олар сәйкес келмеуі мүмкін. kubectl -n kube-system get configmap ip-masq-agent -o yaml агентке не айтылғанын көрсетеді, ал kubectl -n kube-system get pods -l k8s-app=ip-masq-agent оны қолдану үшін бірдеңе жұмыс істеп тұр ма, соны көрсетеді. Торапта iptables-save | grep -i masq ядрода шын мәнінде бар ережелерді көрсетеді. ConfigMap бір нәрсе, ережелер басқа нәрсе десе, күдікті — желі емес, агент.

Бастау көзінің мекенжайын түсірумен растаңыз

Тізімді өзгертуден бұрын түсіру жасаңыз. Бір межеге сүзгі шығысты оқылатын күйде ұстайды: tcpdump -ni any host 10.20.30.40.

Мұны қарсы жақ хабарлағанмен салыстырыңыз. Жергілікті жерде pod мекенжайын көрсететін және жауабы жоқ түсіру шеңберді жабады: ерекшеліктер тізімі асимметрияны туннель ақауынсыз түсіндіреді. Бір бастау көзі мекенжайының екі байқауы CNI туралы болжауды доғаруға жетеді.

Ерекшелікті pod CIDR-іне тарылтыңыз

Қолдау көрсетілетін түзету ерекшелікті жоюдың орнына тарылтады: pod CIDR-ін ерекшелік күйінде қалдырып, 10.x кеңістігінің қалғанын алып тастаңыз. Бұл тізім агенттің ConfigMap-інде nonMasqueradeCIDRs астында тұрады, оны өзгерту — өңдеу, одан кейін шығару. Кең жазбаны кластердің нақты pod диапазонымен алмастырыңыз, кластер ішіндегі трафик әлі қажет болса, басқа жеке блоктарды қалдырыңыз, және себебіңіз болмаса resyncInterval-ке тиіспеңіз. Қолданыңыз, агент pod-тары қайта іске қосылғанын және ядро ережелері өзгергенін растаңыз.

Бұл нақты әсер радиусы бар бүкіл кластерге арналған өзгеріс. Ол күшіне енгеннен кейін бұрын pod бастау көзін сақтаған трафик енді торапқа қайта жазылып келеді, сондықтан сол pod мекенжайларына байланғанның бәрі басқа жіберушіні көреді. Құрбандар — pod мекенжайларын атайтын журналдар, рұқсат тізімдері және жергілікті firewall ережелері, және олар үнсіз істен шығады. Өзгерісті түзету ретінде емес, мінез-құлық өзгерісі ретінде жариялаңыз.

Бірнеше торап пулы бар кластерде агент зардап шеккен pod-тар шын мәнінде жұмыс істейтін тораптарға жоспарланғанын тексеріңіз. DaemonSet жоқ пул өзінің ескі ережелерін сақтайды, және ConfigMap-те мұны ештеңе көрсетпейді.

Балама және оның құны

Басқа нұсқа pod мекенжайларын бүлінбей сақтайды және жолға оларды үйретеді. Pod CIDR-і Cloud VPN трафик селекторларына кіреді, ал жергілікті жаққа жауаптар қайда барарын білуі үшін оған қайтару маршруты керек. Бұл кейбір қауіпсіздік модельдері қалайтын pod бірегейлігін сақтайды және қарсы жақ қабылдауы керек маршруттау мен firewall ауқымын кеңейтеді.

Айырбас — оқылымдылық пен ауқым. Аудару жергілікті жаққа торап сайын бір мекенжай көрсетеді, оны рұқсат тізіміне қосу оңай және қай pod нені жібергенін жасырады. Аудармаса, pod мекенжайы ұшынан ұшына сақталады, бұл атрибуция үшін жақсы, ал жаңа диапазонды үйренуі керек жолдағы әр құрылғы үшін нашар. Екі нұсқа да Docker немесе CNI ақауы емес; екеуі де операциялық шоты бар маршруттау шешімдері. Командаңыз төлей алатын шоты бар нұсқаны таңдаңыз және себебін жазыңыз.

Тексеріңіз және қайтарыңыз

Сол түсіруді қайта іске қосыңыз. Өңдеуіңізден кейін әлі де pod мекенжайын басып шығаратын торап деңгейіндегі түсіру ережелердің ешқашан өзгермегенін білдіреді, ConfigMap не десе де. Факт — сым; қалғанының бәрі қорытынды.

Содан кейін кері бағытты тексеріңіз, өйткені бұл өзгерістердің жартысы тек сыртқа қарай тексеріледі. Жауап сұранысты жіберген торапқа немесе pod-қа жететінін және қолданбаның тек SYN алып қана қоймай аяқталғанын растаңыз. Жауапсыз сұранысты көрсететін түсіру — қарсы жақтағы маршруттау мәселесі, бұл жақтағы masquerade мәселесі емес.

Қайтару — алдыңғы ConfigMap, сол әдіспен қолданылған, агенттің қайта іске қосылғаны және ережелердің өзгергені туралы сол растаумен. Өзгеріс жазбасында бір белгілі сұраныстың бастау көзі мекенжайын дейін және кейін сақтаңыз, өйткені дәл сол бір жол өзгерістің айтқаныңызды жасағанын дәлелдейді. GKE IP masquerade агентінің нұсқаулығы әдепкі мәндерді және ConfigMap өрістерін құжаттайды. Егер шығарылғаннан кейін бастау көзі мекенжайы өзгермесе, агент сол торапта жұмыс істемейді және YAML-ды қанша өңдесеңіз де түзелмейді.