Kubernetes-də OpenVPN podu heç nə yönləndirmir? ip_forward yoxlayın

Noutbukunuz yaşıl tunel göstərir, müştəri jurnalı marşrutların göndərildiyini bildirir və cavab verən yeganə ünvan VPN serverinin öz tunel IP-sidir. Ondan sonrakı pinglər nəyi hədəfləsəniz də ölür, istər ClusterIP, istər başqa podun ünvanı, istərsə də açıq host adı olsun. Bu birləşmə qeyri-müəyyən deyil, diaqnostikdir: dekapsulyasiya işləyir, ikinci hop isə işləmir.

Bununla chart ilə quraşdırılmış OpenVPN obrazı işlədən Debian node-unda rastlaşdım və tunel asan hissə idi. Müştəri 10.8.0.x icarəsini aldı, 10.8.0.1 cavab verdi, 10.96.0.10 isə, yəni cluster DNS xidməti, vaxt aşımına düşdü. Server jurnalında heç nə qeyri-sağlam görünmürdü və insanların heç vaxt toxunmalı olmadıqları iptables qaydalarını yenidən yazmağa başlamalarının səbəbi məhz budur.

VPN podu bir marşrutlaşdırıcıdır və bunu açıq deməyə dəyər. Şifrələnmiş paketlər gəlir, podun öz şəbəkə namespace-ində açılır və sonra başqa interfeysdən çıxmalıdır. Linux bu ikinci addımı yalnız həmin namespace daxilində yönləndirmə aktiv olduqda qəbul edir.

Müştərinin nəyə çata bildiyi və çata bilmədiyi

Cavab verən ünvan tunel son nöqtəsinə aiddir və VPN prosesi ona lokal olaraq sahibdir, buna görə yönləndirmə heç iştirak etmir. Qalan hər şey, o cümlədən başqa pod, xidmət VIP-si və ya internet, kerneldən paketi tun0-dən eth0-ə köçürməsini tələb edir. Bu köçürmə rədd edildikdə simptom rədd deyil, bərabər sükutdur, çünki heç nə tuneldən geriyə ICMP xətası yaratmır. Siz əlçatmaz mesajları deyil, vaxt aşımları alırsınız və bu, heç kimin ümumiyyətlə marşrutlaşdırmadığının işarəsidir.

İki dəqiqəlik təsnifat qatı daraldır. Əgər DNS adları uğursuz olur, lakin xidmət IP-sinə xam pinglər keçirsə, problem yönləndirmədə deyil, DNS boru xəttindədir. Əgər peer ünvanından sonrakı hər təyinat, o cümlədən sadə IP vaxt aşımına düşürsə, namespace-dən başlayın.

Parametri namespace daxilində oxuyun

Hər pod öz şəbəkə namespace-ini alır və net.ipv4.ip_forward hər namespace üçün ayrıca sysctl-dir. Onu node-da dəyişmək konteyner haqqında heç nə demir və bu, günortanı səhv maşında keçirməyin etibarlı yoludur.

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

Sıfır diaqnozu təsdiqləyir. Dəyər node-un işləmə konfiqurasiyasından da miras alınmır: hər dəfə konteyner yaradıldıqda obrazın defoltundan başlayır. Buna görə kubectl exec ... sysctl -w ilə əl ilə tətbiq edilən düzəliş növbəti yenidən başlamada yox olur və fasiləli görünən nasazlıq kimi qayıdır.

Manifest saxlasın deyə onu aktivləşdirmək

Davamlı variant eyni pod sandbox-unda işləyən və dəyəri VPN konteyneri başlamazdan əvvəl yazan init konteyneridir. Poddakı konteynerlər şəbəkə namespace-ini paylaşır, buna görə parametr əsas konteynerə keçir.

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

O privileged: true sətri rəyçilərin etiraz etdiyi yerdir və onlar haqlıdır. Sysctl yazmaq ya imtiyaz, ya da dar əhatəli qabiliyyət tələb edir və məhdud Pod Security Standard ilə işləyən cluster imtiyazlı init konteynerini tamamilə rədd edə bilər. Əgər admission podu rədd edirsə, bunu yaradılma anında öyrənirsiniz, bu heç olmasa dürüst və oxunaqlıdır.

Daha təmiz alternativ pod səviyyəsində securityContext.sysctls siyahısıdır ki, kubeletin heç bir konteynerə imtiyaz vermədən namespace sysctl-lərini tətbiq etməsinə imkan verir. O, yalnız cluster-in icazə siyahısındakı adları əhatə edir. net.ipv4.ip_forward həmin siyahıda olub-olmadığı kubeletin necə konfiqurasiya edildiyindən asılıdır və ondan kənar sysctl istəyən pod admission-da rədd edilir və ya sandbox yenidən cəhd edilərkən CreateContainerConfigError vəziyyətində ilişib qalır. Sahənin xarab olduğunu fərz etməzdən əvvəl icazə siyahısını yoxlayın.

Hər iki yanaşmanı əl ilə qurmazdan əvvəl chart-ın açarı artıq təqdim edib-etmədiyinə baxın, çox vaxt ipForwardInitContainer: true kimi bir şeylə. Chart dəyərini istifadə etmək override faylınızı kiçik saxlayır və növbəti yüksəltmədən sağ çıxır, əl ilə yamaqlanmış Deployment dəyişiklikləri isə yox.

İkinci yarı: geri dönüş yolu və siyasət

Yönləndirmənin aktiv olması zəruridir, kafi deyil. Əgər müştərilər cluster şəbəkəsinin marşrutu olmayan şəxsi hovuz istifadə edirsə, cavablar tunelə geri yol tapa bilmir və pod bu trafiki təyinatına doğru maskalamalıdır.

Siyasət bunun üzərində oturur. NetworkPolicy obyektləri və bulud firewall qaydaları paketin tərcümədən sonra daşıdığı mənbə ünvanına görə qiymətləndirilir, buna görə müştəri hovuzu üçün yazılmış qayda maskalama aktivləşdikdən sonra səssizcə uyğunluğu dayandıra bilər.

Müştərilər yalnız cluster daxilindəki xidmətlərə çatmalı olanda, VPN-in xidmət VIP-də bitməsi pod şəbəkəsinə marşrutlaşdırmaqdan daha kiçik dizayndır. O, həm də müştəri hovuzunu CNI-nin marşrut cədvəlindən tamamilə kənarda saxlayır.

Uğursuz hopu müştəridən təcrid etmək

Xaricə doğru işləyin və ilk səssiz addımda dayanın. VPN peer ilə başlayın, sonra hansısa podun ünvanını, sonra xidmət VIP-sini yoxlayın və yalnız bundan sonra açıq təyinatı. Hər uğur sərhədi bir hop irəli aparır və hər uğursuzluq yoxlanmalı olan qatı adlandırır. Hər yerləşdirmədən sonra içəri exec edin və sysctl-i yenidən oxuyun, çünki dəyişdirilmiş pod obraz defoltundan başlayır və manifestdə heç vaxt olmayan düzəliş artıq yoxdur.

Kubernetes sənədləri cluster-də sysctl istifadəsi haqqında hansı adların pod təhlükəsizlik konteksti ilə təyin edilə biləcəyini göstərir və admission dəyişikliyi rədd etdikdə ilk baxılacaq yer budur.