Pod OpenVPN í Kubernetes sendir engu áfram? Athugaðu ip_forward

Skjólstæðingar pinga VPN-poddið og ekkert lengra. Nafnrýmið er með áframsendingu slökkt, og lagfæringin verður að lifa af admission, endurræsingar og bakleiðina.

Fartölvan þín sýnir grænan göng, biðlaraannállinn segir að leiðum hafi verið ýtt, og eina heimilisfangið sem svarar er eigið göngu-IP VPN-þjónsins. Ping þar fyrir utan deyja sama hvað þú miðar á, hvort sem það er ClusterIP, heimilisfang annars pods eða opinbert hýsilsnafn. Þessi samsetning er greinandi en ekki óljós: afhjúpun virkar, og annað hoppið ekki.

Ég rakst á þetta á Debian-hnút sem keyrði OpenVPN-mynd uppsetta með chart, og göngin voru auðveldi hlutinn. Biðlarinn fékk 10.8.0.x leigu, 10.8.0.1 svaraði, og 10.96.0.10, DNS-þjónusta klasans, rann út á tíma. Ekkert í þjónsannálnum leit veikt út, og það er einmitt hvers vegna fólk byrjar að endurskrifa iptables-reglur sem það þurfti aldrei að snerta.

VPN-pod er beinir, og það er þess virði að segja það hreint út. Dulkóðuð pakkningar berast, eru opnaðar í eigin netnafnrými podsins, og verða síðan að fara út um annað viðmót. Linux neitar því öðru skrefi nema áframsending sé virk inni í því sama nafnrými.

Hvað biðlarinn nær og hvað ekki

Heimilisfangið sem svarar tilheyrir endapunkti gangsins, og VPN-ferlið á það staðbundið, svo áframsending kemur alls ekki við. Allt annað, þar á meðal annað pod, þjónustu-VIP eða internetið, þarf kjarnann til að færa pakkningu frá tun0 til eth0. Þegar þeirri færslu er neitað er einkennið samræmd þögn frekar en synjun, því ekkert býr til ICMP-villu aftur niður göngin. Þú færð tímaútrunna, ekki skilaboð um óaðgengileika, og það er vísbendingin um að enginn sé yfirhöfuð að beina.

Tvær mínútur af flokkun þrengja lagið. Ef DNS-nöfn mistakast á meðan hrá ping á þjónustu-IP heppnast, er vandamálið í DNS-pípulögn, ekki áframsendingu. Ef hver áfangastaður handan við peer-heimilisfangið rennur út á tíma, þar á meðal bert IP, byrjaðu á nafnrýminu.

Lestu stillinguna inni í nafnrýminu

Hvert pod fær sitt eigið netnafnrými, og net.ipv4.ip_forward er sysctl fyrir hvert nafnrými. Að breyta því á hnútnum segir þér ekkert um gámina, og það er áreiðanleg leið til að eyða síðdegi á röngu vélinni.

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

Núll staðfestir greininguna. Gildið erfist heldur ekki frá keyrsluskilgreiningu hnútsins: það byrjar á sjálfgefnu myndarinnar í hvert sinn sem gámur er búinn til. Lagfæring sem beitt er handvirkt með kubectl exec ... sysctl -w hverfur því við næstu endurræsingu og kemur aftur sem galli sem virðist slitróttur.

Virkja það svo manifestið haldi því

Varanlegi kosturinn er init-gámur sem keyrir í sama pod sandbox og skrifar gildið áður en VPN-gámurinn byrjar. Gámarnir í podi deila netnafnrými, svo stillingin flyst inn í aðalgáminn.

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

Það er einmitt privileged: true sem rýnarar mótmæla, og þeir eiga rétt á því. Að skrifa sysctl krefst annaðhvort forréttinda eða þröngs afmarkaðs hæfis, og klasi sem keyrir takmarkaða Pod Security Standard getur hafnað forréttindaríkum init-gámi algjörlega. Ef admission hafnar podinu lærir þú það við sköpun, sem er að minnsta kosti heiðarlegt og auðlesið.

Hreinna valkosturinn er securityContext.sysctls-listinn á pod-stigi, sem leyfir kubelet að beita nafnrýmis-sysctl án þess að veita neinum gámi forréttindi. Hann nær aðeins yfir nöfn á leyfðum lista klasans. Hvort net.ipv4.ip_forward er á þeim lista fer eftir því hvernig kubelet var stillt, og pod sem biður um sysctl utan hans er hafnað við admission eða situr fast í CreateContainerConfigError á meðan sandboxið er reynt aftur. Athugaðu leyfða listann áður en þú gerir ráð fyrir að reiturinn sé bilaður.

Áður en þú byggir annan hvorn aðferðina handvirkt, athugaðu hvort chartið sýni rofann þegar, oft sem eitthvað eins og ipForwardInitContainer: true. Að nota gildi chartsins heldur hnekkingarskránni þinni lítilli og lifir af næstu uppfærslu, sem handvirkt plástruðum Deployment-breytingum tekst ekki.

Seinni helmingurinn: bakleið og stefna

Áframsending á er nauðsynleg, ekki nægjanleg. Ef biðlarar nota einkarekinn hóp sem klasanetið hefur enga leið að, finna svörin ekki leiðina aftur í göngin, og podið þarf að fela þann umferð til áfangastaðar.

Stefnan situr ofan á því. NetworkPolicy-hlutir og eldveggjarreglur skýsins eru metnar gegn upprunafanginu sem pakkning ber eftir þýðingu, svo regla skrifuð fyrir biðlarahópinn getur hljóðlega hætt að passa þegar felan er virkjuð.

Þegar biðlarar þurfa aðeins að ná þjónustum inni í klasanum er minni hönnun að láta VPN enda á þjónustu-VIP en að beina inn í pod-netið. Það heldur biðlarahópnum líka algjörlega utan við beiningartöflu CNI.

Að einangra bilaða hoppið frá biðlaranum

Vinnuðu út á við og stansaðu við fyrsta hljóða skrefið. Byrjaðu á VPN-peer, prófaðu svo heimilisfang einhvers pods, svo þjónustu-VIP, og aðeins eftir það opinberan áfangastað. Hver velgengni færir landamærin eitt hopp, og hver mistök nefna lagið sem er þess virði að skoða. Eftir hverja útbreiðslu skaltu fara inn með exec og lesa sysctl aftur, því skipt pod byrjar á sjálfgefnu myndarinnar og lagfæring sem var aldrei í manifestinu er þegar farin.

Kubernetes-skjöl um notkun sysctl í klasa telja upp hvaða nöfn má setja gegnum öryggissamhengi podsins, og það er fyrsti staðurinn að skoða þegar admission hafnar breytingunni.

Tengdir greinar