Kubernetes'теги OpenVPN поду эч нерсени өткөрбөйбү? ip_forward текшериңиз

Кардарлар VPN подуна ping жөнөтөт, андан ары эч нерсе жок. Namespace'те өткөрүү өчүк, ал эми оңдоо admission, кайра баштоолор жана кайтуу жолунан өтүшү керек.

Ноутбугуңуз жашыл туннель көрсөтөт, кардар журналы маршруттар жөнөтүлгөнүн билдирет, ал эми жооп берген жалгыз дарек — VPN серверинин өзүнүн туннель IP. Анын артындагы ping'дер кайда багыттасаңыз да өлөт, ал ClusterIP болобу, башка поддун дарегиби же коомдук хост аталышыбы. Бул айкалыш бүдөмүк эмес, диагностикалык: декапсуляция иштейт, ал эми экинчи секирик иштебейт.

Мен буга chart аркылуу орнотулган OpenVPN образы иштеп жаткан Debian түйүнүндө туш болдум, ал эми туннель жеңил бөлүгү болчу. Кардар 10.8.0.x ижара алып, 10.8.0.1 жооп берди, ал эми 10.96.0.10, кластердин DNS кызматы, убакыт боюнча бүттү. Сервер журналында эч нерсе оорулуу көрүнгөн жок, ошондуктан адамдар эч качан кармабашы керек болгон iptables эрежелерин кайра жаза башташат.

VPN поду — маршрутизатор, жана муну ачык айтууга татыктуу. Шифрленген пакеттер келип, поддун өзүнүн тармактык namespace'инде ачылат, анан башка интерфейс аркылуу чыгышы керек. Linux бул экинчи кадамды ошол эле namespace'дин ичинде өткөрүү күйгүзүлмөйүнчө четке кагат.

Кардар эмнеге жете алат жана эмнеге жете албайт

Жооп берген дарек туннелдин акыркы чекитине таандык, ал эми VPN процесси аны жергиликтүү түрдө ээлейт, ошондуктан өткөрүү такыр катышпайт. Калгандын баары, анын ичинде башка под, кызматтын VIP'и же интернет, ядродон пакетти tun0 ден eth0 ге жылдырууну талап кылат. Бул жылдыруу четке кагылганда, симптом четке кагуу эмес, бирдей тынчтык, анткени туннелден артка ICMP катасын эч нерсе жаратпайт. Сиз тайм-ауттарды аласыз, жеткиликсиздик билдирүүлөрүн эмес, жана бул эч ким такыр маршруттабай турганынын белгиси.

Эки мүнөт классификация катмарды тарытат. Эгер DNS аттары ийгиликсиз болуп, кызмат IP'ине чийки ping'дер ийгиликтүү болсо, маселе өткөрүүдө эмес, DNS түтүктөрүндө. Эгер peer дарегинен ары карай ар бир багыттай жер тайм-аутка түшсө, жылаңач IP'ди кошкондо, namespace'тен баштаңыз.

Параметрди namespace'дин ичинен окуңуз

Ар бир под өзүнүн тармактык namespace'ин алат, ал эми net.ipv4.ip_forward ар бир namespace үчүн sysctl болуп саналат. Аны түйүндө өзгөртүү контейнер жөнүндө эч нерсе айтпайт, жана бул түштөн кийинки убакытты туура эмес машинада өткөрүүнүн ишенимдүү жолу.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

Нөл диагнозду ырастайт. Маани түйүндүн аткаруу конфигурациясынан да мурасталбайт: контейнер түзүлгөн сайын ал образдын демейки маанисинен башталат. Ошондуктан kubectl exec ... sysctl -w аркылуу кол менен колдонулган оңдоо кийинки кайра баштоодо жоголот жана үзүл-үзүл көрүнгөн кемтик катары кайтат.

Манифест сакташы үчүн аны күйгүзүү

Туруктуу вариант — ошол эле pod sandbox'та иштеген жана VPN контейнери башталганга чейин маанини жазуучу init контейнери. Pod ичиндеги контейнерлер тармактык namespace'ди бөлүшөт, ошондуктан жөндөө негизги контейнерге өтөт.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

Так privileged: true — сынчылар каршы чыккан сап, жана алар туура. sysctl жазуу үчүн же артыкчылык, же тар чөйрөдөгү жөндөмдүүлүк керек, ал эми чектелген Pod Security Standard менен иштеген кластер артыкчылыгы бар init контейнерин таптакыр четке кагышы мүмкүн. Эгер admission подду четке какса, муну түзүү убагында билесиз, бул жок дегенде чынчыл жана окууга жеңил.

Тазараак альтернатива — под деңгээлиндеги securityContext.sysctls тизмеси, ал kubelet'ке эч бир контейнерге артыкчылык бербей эле namespace'дик sysctl'дерди колдонууга мүмкүндүк берет. Ал кластердин уруксат тизмесиндеги аттарды гана камтыйт. net.ipv4.ip_forward ошол тизмедеби же жокпу — kubelet кантип конфигурацияланганына байланыштуу, ал эми андан тышкаркы sysctl сураган под admission'до четке кагылат же sandbox кайра каралганга чейин CreateContainerConfigError де илинип калат. Талааны бузулган деп ойлоодон мурун уруксат тизмесин текшериңиз.

Эки ыкманын бирин кол менен куруудан мурун, chart которуштуруучуну мурунтан эле сунуштап турабы, караңыз, көбүнчө ipForwardInitContainer: true сыяктуу нерсе түрүндө. Chart маанисин колдонуу override файлыңызды кичине кармайт жана кийинки жаңыртуудан өтөт, ал эми кол менен жамалган Deployment өзгөртүүлөрү андай кылбайт.

Экинчи жарымы: кайтуу жолу жана саясат

Күйгүзүлгөн өткөрүү зарыл, бирок жетиштүү эмес. Эгер кардарлар кластер тармагында маршруту жок жеке пулду колдонсо, жооптор туннелге кайра жол таба албайт, жана под ошол трафикти өз максатына карай маскировкалоосу керек.

Саясат анын үстүндө отурат. NetworkPolicy объектилери жана булут firewall эрежелери пакеттин которуудан кийин алып жүргөн булак дарегине каршы бааланат, ошондуктан кардар пулу үчүн жазылган эреже маскировка күйгүзүлгөндөн кийин үнсүз дал келүүнү токтотушу мүмкүн.

Кардарларга кластердин ичиндеги кызматтарга гана жетүү керек болсо, VPN'ди кызмат VIP'инде аяктоо под тармагына маршруттоодон кичирээк дизайн. Ал ошондой эле кардар пулун CNI маршрут таблицасынан толугу менен тышкары кармайт.

Ийгиликсиз секирикти кардардан обочолотуу

Сыртка карай иштеңиз жана биринчи үнсүз кадамда токтоңуз. VPN peer'инен баштаңыз, анан кандайдыр бир поддун дарегин, анан кызмат VIP'ин көрүңүз, жана андан кийин гана коомдук багытты. Ар бир ийгилик чекти бир секирик жылдырат, ал эми ар бир ийгиликсиздик текшерүүгө татыктуу катмарды атайт. Ар кандай чыгарылыштан кийин exec аркылуу кирип, sysctl'ди кайра окуңуз, анткени алмаштырылган под образдын демейкисинен башталат, ал эми манифестте эч качан болбогон оңдоо мурун эле кеткен.

Kubernetes документи кластерде sysctl колдонуу тууралуу кайсы аттарды pod коопсуздук контексти аркылуу коюуга болорун тизмелейт, жана admission өзгөртүүнү четке какканда эң оболу ошол жерди кароо керек.

Тектеш макалалар