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 өзгерісті қабылдамағанда ең алдымен соған қарау керек.

Қатысты мақалалар