OpenVPN-podo en Kubernetes nenion plusendas? Kontrolu ip_forward

Klientoj pingas la VPN-podon kaj nenion preter ĝi. La namespace havas plusendadon malŝaltita, kaj la riparo devas postvivi admission, restartojn kaj la returnan vojon.

Via tekkomputilo montras verdan tunelon, la klienta protokolo raportas, ke itineroj estis puŝitaj, kaj la sola adreso, kiu respondas, estas la propra tunela IP de la VPN-servilo. Pingoj preter ĝi mortas egale al kio vi celas, ĉu ClusterIP, adreso de alia podo aŭ publika gastigantnomo. Tiu kombino estas diagnoza, ne malklara: malkapsuligo funkcias, kaj la dua salto ne.

Mi renkontis tion sur Debian-nodo ruliganta OpenVPN-bildon instalitan per chart, kaj la tunelo estis la facila parto. La kliento ricevis luon 10.8.0.x, 10.8.0.1 respondis, kaj 10.96.0.10, la DNS-servo de la klastero, tempolimis. Nenio en la servila protokolo aspektis malsana, kaj ĝuste tial homoj komencas reverki iptables-regulojn, kiujn ili neniam bezonis tuŝi.

VPN-podo estas enkursigilo, kaj indas diri tion senpage. Ĉifritaj pakaĵoj alvenas, estas malvolvataj en la propra reta namespace de la podo, kaj poste devas eliri tra alia interfaco. Linux rifuzas tiun duan paŝon krom se plusendado estas ŝaltita ene de ĝuste tiu namespace.

Kion la kliento povas kaj ne povas atingi

La adreso, kiu respondas, apartenas al la tunela finpunkto, kaj la VPN-procezo posedas ĝin loke, do plusendado tute ne partoprenas. Ĉio alia, inkluzive alian podon, servan VIP aŭ la interreton, bezonas la kernon por movi pakaĵon de tun0 al eth0. Kiam tiu movo estas rifuzata, la simptomo estas unuforma silento anstataŭ rifuzo, ĉar nenio generas ICMP-eraron reen laŭ la tunelo. Vi ricevas tempolimojn, ne mesaĝojn pri neatendeblo, kaj tio estas la indico, ke neniu entute enkursigas.

Du minutoj da klasifiko mallarĝigas la tavolon. Se DNS-nomoj malsukcesas dum krudaj pingoj al serva IP sukcesas, la problemo estas DNS-tubaro, ne plusendado. Se ĉiu celo preter la peer-adreso tempolimas, inkluzive nudan IP, komencu ĉe la namespace.

Legu la agordon interne de la namespace

Ĉiu podo ricevas sian propran retan namespace, kaj net.ipv4.ip_forward estas sysctl por ĉiu namespace. Ŝanĝi ĝin sur la nodo diras al vi nenion pri la ujo, kaj ĝi estas fidinda maniero pasigi posttagmezon sur la malĝusta maŝino.

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

Nulo konfirmas la diagnozon. La valoro ankaŭ ne estas heredata de la rulada agordo de la nodo: ĝi komenciĝas de la bilda defaŭlto ĉiufoje, kiam ujo estas kreata. Riparo aplikita mane per kubectl exec ... sysctl -w do malaperas ĉe la sekva restarto kaj revenas kiel difekto, kiu aspektas intermita.

Ŝalti ĝin tiel, ke la manifestaĵo konservu ĝin

La daŭra opcio estas init-ujo, kiu rulas en la sama pod-sandbox kaj skribas la valoron antaŭ ol la VPN-ujo startas. Ujoj en podo kunhavas retan namespace, do la agordo portiĝas en la ĉefan ujon.

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

Ekzakte privileged: true estas la linio, kontraŭ kiu recenzantoj protestas, kaj ili pravas. Skribi sysctl bezonas aŭ privilegion aŭ strikte limigitan kapablon, kaj klastero ruliganta la restriktan Pod Security Standard povas tute rifuzi privilegian init-ujon. Se admission rifuzas la podon, vi ekscias ĉe kreado, kio almenaŭ estas honesta kaj facile legebla.

La pli pura alternativo estas la podnivela listo securityContext.sysctls, kiu lasas la kubeleton apliki namespacajn sysctl-ojn sen doni privilegion al iu ujo. Ĝi kovras nur nomojn sur la permeslisto de la klastero. Ĉu net.ipv4.ip_forward estas sur tiu listo dependas de tio, kiel la kubelet estis agordita, kaj podo, kiu petas sysctl ekster ĝi, estas rifuzata ĉe admission aŭ restas blokita en CreateContainerConfigError dum la sandbox estas relanĉata. Kontrolu la permesliston antaŭ ol supozi, ke la kampo estas difektita.

Antaŭ ol mane konstrui iun el la du aliroj, vidu ĉu la chart jam elmetas la ŝaltilon, ofte kiel io kiel ipForwardInitContainer: true. Uzi la chart-valoron tenas vian anstataŭigan dosieron malgranda kaj postvivas la sekvan ĝisdatigon, kion mane flikaj Deployment-redaktoj ne faras.

La dua duono: reena vojo kaj politiko

Ŝaltita plusendado estas necesa, ne sufiĉa. Se klientoj uzas privatan bankon, por kiu la klastera reto havas neniun itineron, respondoj ne povas retrovii la vojon en la tunelon, kaj la podo devas maski tiun trafikon al sia celo.

Politiko sidas sur tio. NetworkPolicy-objektoj kaj nubaj fajroŝirmilaj reguloj estas taksataj laŭ la fontadreso, kiun pakaĵo portas post traduko, do regulo skribita por la klienta banko povas silente ĉesi kongrui post kiam maskado estas ŝaltita.

Kiam klientoj bezonas atingi nur servojn interne de la klastero, fini la VPN ĉe la serva VIP estas pli malgranda dezajno ol enkursigi en la podan reton. Ĝi ankaŭ tenas la klientan bankon tute ekster la enkursiga tabelo de la CNI.

Izoli la malsukcesan salton de la kliento

Laboru eksteren kaj haltu ĉe la unua silenta paŝo. Komencu per la VPN-peer, poste provu adreson de iu podo, poste servan VIP, kaj nur poste publikan celon. Ĉiu sukceso movas la limon unu salton, kaj ĉiu malsukceso nomas la tavolon indan je inspekto. Post ajna lanĉo, eniru per exec kaj legu la sysctl denove, ĉar anstataŭigita podo komenciĝas de la bilda defaŭlto kaj riparo, kiu neniam estis en la manifestaĵo, jam foriris.

La Kubernetes-dokumentaro pri uzado de sysctl en klastero listigas, kiuj nomoj povas esti agorditaj per la sekureca kunteksto de la podo, kaj ĝi estas la unua loko por rigardi, kiam admission rifuzas la ŝanĝon.

Rilataj artikoloj