Kubernetes లో OpenVPN పాడ్ ఏమీ ఫార్వర్డ్ చేయడం లేదా? ip_forward తనిఖీ చేయండి

మీ ల్యాప్టాప్ ఆకుపచ్చ సొరంగాన్ని చూపిస్తుంది, క్లయింట్ లాగ్ మార్గాలు పుష్ చేయబడినట్లు చెబుతుంది, మరియు సమాధానం ఇచ్చే ఏకైక చిరునామా VPN సర్వర్ స్వంత సొరంగ IP. దాని ఆవల పింగ్లు మీరు ఏది లక్ష్యంగా చేసుకున్నా చనిపోతాయి, అది 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 కు ముడి పింగ్లు విజయవంతమైతే, సమస్య ఫార్వర్డింగ్లో కాదు, 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 తో చేతితో వర్తించిన సరిదిద్దడం తదుపరి పునఃప్రారంభంలో అదృశ్యమై అప్పుడప్పుడు కనిపించే లోపంగా తిరిగి వస్తుంది.

manifest దాన్ని నిలుపుకునేలా ప్రారంభించడం

శాశ్వత ఎంపిక అదే pod sandbox లో నడిచే మరియు VPN కంటైనర్ ప్రారంభమయ్యే ముందు విలువను రాసే init కంటైనర్. పాడ్లోని కంటైనర్లు నెట్వర్క్ 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 వస్తువులు మరియు క్లౌడ్ ఫైర్వాల్ నియమాలు అనువాదం తర్వాత ప్యాకెట్ మోసే మూల చిరునామాకు వ్యతిరేకంగా మూల్యాంకనం చేయబడతాయి, కాబట్టి క్లయింట్ పూల్ కోసం రాసిన నియమం మాస్కింగ్ ప్రారంభమైన తర్వాత నిశ్శబ్దంగా సరిపోలడం ఆపవచ్చు.

క్లయింట్లు క్లస్టర్ లోపలి సేవలను మాత్రమే చేరుకోవాల్సి వస్తే, VPN ను సేవ VIP వద్ద ముగించడం పాడ్ నెట్వర్క్లోకి రూట్ చేయడం కంటే చిన్న రూపకల్పన. ఇది క్లయింట్ పూల్ను CNI రూటింగ్ పట్టిక నుండి పూర్తిగా బయట ఉంచుతుంది.

విఫలమయ్యే హాప్ను క్లయింట్ నుండి వేరుచేయడం

బయటకు పని చేయండి మరియు మొదటి నిశ్శబ్ద అడుగు వద్ద ఆగండి. VPN peer తో ప్రారంభించండి, తర్వాత ఏదో ఒక పాడ్ చిరునామా ప్రయత్నించండి, తర్వాత సేవ VIP, ఆ తర్వాతే పబ్లిక్ గమ్యం. ప్రతి విజయం సరిహద్దును ఒక హాప్ కదిలిస్తుంది, మరియు ప్రతి వైఫల్యం పరిశీలించదగిన పొరను పేర్కొంటుంది. ఏదైనా రోల్అవుట్ తర్వాత exec చేసి లోపలికి వెళ్లి sysctl ను మళ్లీ చదవండి, ఎందుకంటే భర్తీ చేయబడిన పాడ్ ఇమేజ్ డిఫాల్ట్ నుండి ప్రారంభమవుతుంది మరియు manifest లో ఎప్పుడూ లేని సరిదిద్దడం ఇప్పటికే పోయింది.

Kubernetes డాక్యుమెంటేషన్ క్లస్టర్లో sysctl వినియోగం గురించి ఏ పేర్లను పాడ్ భద్రతా సందర్భం ద్వారా సెట్ చేయవచ్చో జాబితా చేస్తుంది, మరియు admission మార్పును నిరాకరించినప్పుడు మొదట చూడాల్సిన స్థలం అదే.