Kubernetes లో VPN క్లయింట్ IP: దాన్ని కాపాడాలా లేక SNAT చేయాలా?
Kubernetes లో VPN క్లయింట్ యొక్క నిజమైన చిరునామా మరియు మూల NAT మధ్య మూడు షరతుల ఆధారంగా ఎంచుకోండి, తర్వాత తిరిగి వచ్చే మార్గాన్ని మరియు pod మార్పును ధృవీకరించండి.
ఎక్కడో టన్నెల్ మరియు backend మధ్య క్లయింట్ చిరునామా గాని నిలిచిపోతుంది లేక భర్తీ చేయబడుతుంది, మరియు రెండు ఫలితాలు సమర్థనీయమైనవి. ఎంపిక స్వీకరించే సేవ యజమానికి చెందుతుంది, CNI ఇన్స్టాల్ చేసిన వారికి కాదు. ప్రతి క్లయింట్ అధికారం, కోటాలు లేక ఆడిట్ రికార్డులు ముఖ్యమైనప్పుడు, చిరునామా ప్రతి హాప్ను దాటాలి. భాగస్వామ్య ఆపాదన ఆమోదయోగ్యమైనప్పుడు, మూల NAT మీరు లేకపోతే శాశ్వతంగా నిర్వహించాల్సిన రౌటింగ్ సమస్యను తొలగిస్తుంది.
చిరునామా నిజంగా ఎక్కడ మాయమవుతుంది
దూరపు క్లయింట్ ప్యాకెట్ VPN pod-కు టన్నెల్ పరిధిలోని అంతర్గత మూలంతో చేరుతుంది, అనుకుందాం 10.90.0.42. pod ఆ ప్యాకెట్ను ClusterIP లేక pod IP వైపు పంపినప్పుడు, మూడు వేర్వేరు యంత్రాంగాలు మూలాన్ని తిరిగి రాయగలవు. node యొక్క CNI masquerade నియమం pod క్లస్టర్ CIDR వెలుపల పంపే ట్రాఫిక్ను కవర్ చేస్తుంది. గమ్యం nodeపై kube-proxy యొక్క conntrack నమోదు స్వయంగా Service హాప్ను కవర్ చేస్తుంది. కనెక్షన్ను ముగించే ప్రాక్సీ ప్యాకెట్ను అసలు పంపదు, కాబట్టి చివరికి మీరు చూసే మూలం ప్రాక్సీదే.
వాటిలో ప్రతి ఒక్కటి వేరే పొరలో నివసిస్తుంది, అందుకే ఒక Service ఫీల్డ్ దాదాపు ఎప్పుడూ మొత్తం మార్గాన్ని సరిచేయదు.
VPN యొక్క పబ్లిక్ Serviceపై externalTrafficPolicy బాహ్య కనెక్షన్ గురించి మాత్రమే నిర్ణయిస్తుంది: Local దూరపు చిరునామాను దాన్ని స్వీకరించిన nodeపై ఉంచుతుంది, Cluster kube-proxy ప్యాకెట్ను మరో nodeకు ఇచ్చి అక్కడ masquerade చేయడానికి అనుమతిస్తుంది. ఆ సెట్టింగ్ మీ క్లయింట్లు కనెక్ట్ అయ్యే listenerను నియంత్రిస్తుంది. మీ VPN ప్రక్రియ తర్వాత క్లస్టర్లోకి పంపే డీక్రిప్ట్ చేసిన ప్యాకెట్ గురించి అది ఏమీ చెప్పదు.
వాదనను తీర్చే మూడు షరతులు
ఈ విషయం వచ్చిన ప్రతిసారీ అదే మూడు ప్రశ్నలను అదే క్రమంలో అడుగుతాను, ఎందుకంటే మొదటిది సాధారణంగా చర్చను ముగిస్తుంది. నిర్దిష్ట పనిభారానికి సమాధానం చెప్పండి, మొత్తం క్లస్టర్కు కాదు. ఒకే కంపెనీలోని రెండు క్లస్టర్లు వేర్వేరు సమాధానాలకు చేరుకోవచ్చు, రెండూ సరైనవే కావచ్చు.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
backend మొదటి ప్రశ్నకు అవును, రెండవదానికి కాదు అని చెబితే, మీకు నెట్వర్క్ పని ఉంది, manifest మార్చడం కాదు. మూడవ వరుస ప్రాక్సీ అని చెబితే, చిరునామా ఎప్పుడూ నిలిచేది కాదు, దానికి విరుద్ధంగా చెప్పడం ఒక వారం ప్యాకెట్ క్యాప్చర్కు ఖర్చవుతుంది.
preserve మోడ్ నెట్వర్క్ నుండి ఏమి కోరుతుంది
మూలాన్ని కాపాడటం అంటే గమ్యం node ట్రాఫిక్ను యాక్టివ్ VPN గేట్వే ద్వారా 10.90.0.42కు తిరిగి పంపాలి. VPN పూల్ క్లస్టర్ CIDR కాదు, కాబట్టి ఏ CNI దాన్ని మీ కోసం డిఫాల్ట్గా రూట్ చేయదు. మీరే మార్గాన్ని జోడించి, ఆపై అది సూచించే గేట్వే ముగింపు బిందువు పునర్షెడ్యూలింగ్ను తట్టుకుంటుందని నిర్ధారించుకుంటారు.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2ఆ తదుపరి హాప్ pod చిరునామా, pod చిరునామాలు కదులుతాయి. మార్గాన్ని Service VIP లేక స్థిరంగా ఉండే node చిరునామా వైపు తిప్పండి, లేక ప్రతి బహిష్కరణ తర్వాత మీరు గేట్వేను వెంబడిస్తారని అంగీకరించండి. విలోమ మార్గ ఫిల్టరింగ్ మరో ఉచిత్రం: కఠిన మోడ్, వచ్చిన ఇంటర్ఫేస్కు సరిపోని తిరిగి వచ్చే మార్గం ఉన్న ప్యాకెట్లను పడేస్తుంది, ఇది సరిగ్గా సంరక్షించబడిన VPN ప్రవాహం ఆకారం.
వదులైన ధృవీకరణ తరచుగా పనిచేసే తిరిగి వచ్చే మార్గానికి మరియు backendను వదిలిన తర్వాత మాయమయ్యే సమాధానాలకు మధ్య తేడా. VPN nodeపై masquerade నియమాలు కూడా టన్నెల్ పరిధిని మినహాయించాలి, లేకపోతే పంపిన ప్యాకెట్ pod చిరునామాతోనే బయటకు వెళ్తుంది, మీరు ఏ మార్గం నిర్మించినా. ఈ మినహాయింపును iptablesను చేతితో సవరించడం బదులు CNI స్వంత కాన్ఫిగరేషన్లో వ్యక్తపరచండి, ఎందుకంటే ఏజెంట్ పునఃప్రారంభంలో తన చైన్లను తిరిగి రాస్తుంది, మీ చేతితో రాసిన నియమం సరిగ్గా తదుపరి అప్గ్రేడ్ వరకే నిలుస్తుంది.
NetworkPolicy యాక్సెస్ నియంత్రణ, రౌటింగ్ కాదు. విధానాన్ని కఠినతరం చేయడం masquerade ఇప్పటికే భర్తీ చేసిన చిరునామాను ఎప్పుడూ పునరుద్ధరించదు.
SNAT ఖర్చు ఏమిటి, దాన్ని ఎలా నమోదు చేయాలి
క్లస్టర్ వైపు మూల NAT చవకైన రూపకల్పన, అది పొరపాటు కాదు. backend VPN pod లేక node చిరునామాను చూస్తుంది, లాగ్లు ఒకదానితో ఒకటి సరిపోతాయి, తిరిగి వచ్చే మార్గం ఉండాల్సిన అవసరం లేదు. మీరు కోల్పోయేది నెట్వర్క్ పొరలో ఇద్దరు క్లయింట్లను వేరు చేసే సామర్థ్యం, కాబట్టి కోటాలు, నిషేధాలు మరియు ఆడిట్ జాడలు మరెక్కడినుండో రావాలి.
సాధారణంగా ఆ మరెక్కడో అంటే అప్లికేషన్: సెషన్ టోకెన్, సంతకం చేసిన హెడర్, లేక మీరు నియంత్రించే ప్రాక్సీ రాసే PROXY ప్రోటోకాల్ లైన్. ఇవి గ్రహీతకు ప్రాక్సీ మార్గంలో ఉన్నప్పుడు మరియు హెడర్ను క్లయింట్ వైపు నుండి సెట్ చేయలేనప్పుడు మాత్రమే నమ్మగల గుర్తింపును ఇస్తాయి. runbookలో ఏది వర్తిస్తుందో స్పష్టంగా చెప్పండి, ఎందుకంటే తదుపరి ఇంజనీర్ లాగ్లోని చిరునామానే క్లయింట్ అని భావిస్తారు. అలా కాదు, ఒక సంఘటన ఆ ఊహను ఖరీదైనదిగా చేయడానికి సరిపోతుంది.
ఈ మార్పిడి రాసి ఉన్నంత కాలం నిజాయితీగా ఉంటుంది.
పనిచేసే మార్గాన్ని అదృష్టవంతమైన మార్గం నుండి వేరు చేసే తనిఖీలు
తాజా కనెక్షన్తో పరీక్షించండి, కాష్ చేసిన కనెక్షన్తో కాదు, రెండు దిశల్లో పరీక్షించండి. అనేక వైఫల్యాలు అడపాదడపా అనిపించడానికి కారణం కొత్త ప్రవాహాలు తిరిగి రాసిన మార్గాన్ని తీసుకోవడమే.
ఒక అధికారిక అభ్యర్థన సమయంలో tupleను మూడు చోట్ల పట్టుకోండి: డీక్రిప్షన్ తర్వాత వెంటనే, VPN pod యొక్క నిష్క్రమణ ఇంటర్ఫేస్పై, మరియు backendపై. రెండవ మరియు మూడవ పట్టు మధ్య మూలం మారితే, కారణం pod కింద ఉంది. రెండవదానికి ముందు మారితే, pod స్వయంగా అనువదిస్తోంది.
తర్వాత VPN podను తొలగించి, పునర్షెడ్యూలింగ్ సమయంలో పరీక్షను పునరావృతం చేయండి. బహిష్కరణలో విరిగిపోయే సంరక్షించబడిన మార్గం అసంపూర్ణం, ఇప్పుడు లేని చిరునామాకు పిన్ చేసిన NAT నియమం కూడా అలాగే. చివరగా, తిరస్కరించబడుతుందని మీరు ఆశించే మూలం నుండి ఒక అభ్యర్థన పంపి, తిరస్కరణ విధానం నుండి వస్తుందా, తప్పిపోయిన మార్గం నుండి కాదా అని నిర్ధారించండి.