OpenVPN-pod yn Kubernetes stjoert neat troch? Kontrolearje ip_forward

Klanten pingje de VPN-pod en dêrnei neat. De namespace hat trochstjoeren út, en de fix moat admission, werstarts en de weromwei oerlibje.

Dyn laptop lit in griene tunnel sjen, it kliïntlogboek seit dat rûtes pusht binne, en it iennichste adres dat antwurdet is de eigen tunnel-IP fan de VPN-tsjinner. Pings dêrnei stjerre, wat jo ek rjochtsje, itsij in ClusterIP, it adres fan in oare pod of in publike hostnamme. Dy kombinaasje is diagnostysk en net ûndúdlik: dekapsulaasje wurket, en de twadde hop net.

Ik kaam dit tsjin op in Debian-node mei in OpenVPN-image dat fia chart ynstallearre wie, en de tunnel wie it maklike part. De klant krige in 10.8.0.x-lien, 10.8.0.1 antwurde, en 10.96.0.10, de DNS-tsjinst fan it cluster, einige yn in time-out. Neat yn it tsjinnerlogboek seach ûnsûn út, en dat is krekt wêrom't minsken iptables-regels begjinne te werôverjen dy't se nea hawwe hoegde oan te reitsjen.

In VPN-pod is in router, en it is de muoite wurdich dat gewoan te sizzen. Fersifere pakketten komme oan, wurde yn 'e eigen netwurk-namespace fan de pod útpakt, en moatte dan fia in oare interface nei bûten. Linux wegeret dy twadde stap, útsein as trochstjoeren binnen deselde namespace ynskeakele is.

Wat de klant wol en net berikke kin

It adres dat antwurdet heart by it tunnel-einpunt, en it VPN-proses hat it lokaal, sadat trochstjoeren hielendal net belutsen is. Al it oare, ynklusyf in oare pod, in tsjinst-VIP of it ynternet, hat de kernel nedich om in pakket fan tun0 nei eth0 te ferpleatsen. As dy ferpleatsing wegere wurdt, is it symptoom gelykfoarmige stilte ynstee fan in ôfwizing, om't neat in ICMP-flater werom by de tunnel del generearret. Jo krije time-outs, gjin berjochten oer ûnberikberens, en dat is de oanwiising dat nimmen hielendal rûtelet.

Twa minuten klassifikaasje ferlingt de laach. As DNS-nammen misse wylst rûge pings nei in tsjinst-IP slagje, is it probleem DNS-lieding, net trochstjoeren. As elke bestimming foarby it peer-adres in time-out jout, ek in keale IP, begjin dan by de namespace.

Lês de ynstelling binnen de namespace

Elke pod krijt syn eigen netwurk-namespace, en net.ipv4.ip_forward is in sysctl per namespace. It feroarjen op de node fertelt jo neat oer de container, en it is in betroubere manier om in middei op 'e ferkearde masine troch te bringen.

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

In nul befêstiget de diagnose. De wearde wurdt ek net fan 'e runtime-konfiguraasje fan 'e node erfd: it begjint by de image-standert elke kear as in container makke wurdt. In fix dy't mei de hân mei kubectl exec ... sysctl -w tapast is, ferdwynt dêrom by de folgjende werstart en komt werom as in defekt dat ûnregelmjittich liket.

It ynskeakelje sadat it manifest it hâldt

De duorsume opsje is in init-container dy't yn deselde pod-sandbox rint en de wearde skriuwt foardat de VPN-container start. Containers yn in pod diele in netwurk-namespace, dus de ynstelling giet mei nei de haadcontainer.

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

Dy privileged: true is de rigel dêr't resinsinten tsjin yn gean, en se hawwe gelyk. In sysctl skriuwe freget ofwol privileezje, ofwol in smel begrinze kapasiteit, en in cluster mei de beheinde Pod Security Standard kin in privilezjeare init-container folslein wegerje. As admission de pod wegeret, learsto dat by it oanmeitsjen, wat teminsten earlik en maklik te lêzen is.

It skjinere alternatyf is de securityContext.sysctls-list op pod-nivo, dy't de kubelet ynnammens sysctls tapasse lit sûnder privileezje oan in container te jaan. It beslacht allinnich nammen op 'e tastiene list fan it cluster. Oft net.ipv4.ip_forward op dy list stiet, hinget ôf fan hoe't de kubelet konfigurearre is, en in pod dy't in sysctl bûten dy list freget, wurdt by admission wegere of bliuwt hingjen yn CreateContainerConfigError wylst de sandbox wer besocht wurdt. Kontrolearje de tastiene list foardat jo oannimme dat it fjild stikken is.

Foardat jo ien fan beide oanpakken mei de hân bouwe, sjoch dan oft de chart de skeakel al bleatleit, faak as eat lykas ipForwardInitContainer: true. It brûken fan 'e chart-wearde hâldt jo override-bestân lyts en oerlibbet de folgjende upgrade, wat mei de hân patchte Deployment-wizigings net dogge.

De twadde helte: weromwei en belied

Trochstjoeren oan is needsaaklik, net genôch. As klanten in partikuliere pool brûke dêr't it clusternetwurk gjin rûte foar hat, fine antwurden de wei net werom yn 'e tunnel, en de pod moat dat ferkear nei syn bestimming maskearje.

Belied sit dêrop. NetworkPolicy-objekten en cloud-firewallregels wurde beoardiele tsjin it boarneadres dat in pakket nei oersetting draacht, sadat in regel skreaun foar de klantpool stilwei ophâlde kin te passen as maskearjen ynskeakele is.

As klanten allinnich tsjinsten binnen it cluster berikke moatte, is it lytsere ûntwerp om de VPN by de tsjinst-VIP einigje te litten as om yn it pod-netwurk te rûteljen. It hâldt de klantpool ek hielendal bûten de rûtetabel fan 'e CNI.

De mislearjende hop fan 'e klant isolearje

Wurkje nei bûten en stopje by de earste stille stap. Begjin by de VPN-peer, besykje dan it adres fan in pod, dan in tsjinst-VIP, en pas dêrnei in publike bestimming. Elk súkses ferpleatst de grins ien hop, en elke mislearring neamt de laach dy't it besjen wurdich is. Nei elke rollout, gean der yn en lês de sysctl wer, om't in ferfongen pod by de image-standert begjint en in fix dy't nea yn it manifest stien hat is al fuort.

De Kubernetes-dokumintaasje oer it brûken fan sysctls yn in cluster listet hokker nammen fia de befeiligingskontekst fan 'e pod ynsteld wurde kinne, en it is it earste plak om te sjen as admission de feroaring wegeret.

Relatearre artikelen