GKE పాడ్‌లు VPN ద్వారా ఆన్-ప్రెమ్ హోస్ట్‌లను చేరుకోలేకపోవడానికి కారణం

నోడ్ నుండి పింగ్ పనిచేస్తుంది మరియు పాడ్ నుండి విఫలమవుతుంది, స్థానిక వైపు ఏమీ చేరుకోదు. టన్నెల్ మరియు మార్గం సరిగ్గా ఉన్నాయి; తీగపై ఉన్న మూల చిరునామా సరిగ్గా లేదు. ఈ రెండు సందర్భాల మధ్య భేదం ఏమిటంటే క్లస్టర్‌ను విడిచిపెట్టేటప్పుడు ప్యాకెట్ తనను ఏమని ప్రకటించుకుంటుంది అనేది, GKE కి దాని గురించి అభిప్రాయం ఉంది. యంత్రాంగం masquerade మినహాయింపుల జాబితా, దాన్ని చదవడానికి ఒక ఆదేశం చాలు.

ఏదైనా మార్చే ముందు అమలులో ఉన్న జాబితాను చదవండి

GKE ప్రతి గమ్యస్థాన పరిధికి పాడ్ ట్రాఫిక్ బయలుదేరేటప్పుడు నోడ్ చిరునామాకు తిరిగి రాయబడుతుందా అని నిర్ణయించే ఏజెంట్‌ను అందిస్తుంది. దాని అందించిన కాన్ఫిగరేషన్ మూడు RFC1918 బ్లాకులను, 10.0.0.0/8, 172.16.0.0/12 మరియు 192.168.0.0/16, మినహాయించిన గమ్యస్థానాలుగా పేర్కొంటుంది. అందువల్ల పాడ్ నుండి స్థానిక 10.x హోస్ట్‌కు మీరు పంపే ప్రతిదీ పాడ్ యొక్క స్వంత చిరునామా ఇంకా అతుక్కుని ఉండగానే నోడ్‌ను విడిచిపెడుతుంది. నోడ్ యొక్క సొంత ట్రాఫిక్ తిరిగి రాయబడదు, అందుకే దాని పింగ్ పనిచేస్తుంది.

ఉద్దేశించిన కాన్ఫిగరేషన్ మరియు ఇన్‌స్టాల్ చేసిన నియమాలను చదవండి, ఎందుకంటే అవి సరిపోలకపోవచ్చు. kubectl -n kube-system get configmap ip-masq-agent -o yaml ఏజెంట్‌కు ఏమి చెప్పారో చూపిస్తుంది, kubectl -n kube-system get pods -l k8s-app=ip-masq-agent దాన్ని వర్తింపజేయడానికి ఏదైనా నడుస్తున్నదా చూపిస్తుంది. నోడ్‌పై iptables-save | grep -i masq కెర్నల్‌లో నిజంగా ఉన్న నియమాలను చూపిస్తుంది. ConfigMap ఒకటి చెప్పి నియమాలు మరొకటి చెబితే, అనుమానితుడు నెట్‌వర్క్ కాదు, ఏజెంట్.

క్యాప్చర్‌తో మూల చిరునామాన్ని నిర్ధారించండి

జాబితాను మార్చే ముందు క్యాప్చర్ చేయండి. ఒకే గమ్యస్థానంపై ఫిల్టర్ అవుట్‌పుట్‌ను చదవగలిగేలా ఉంచుతుంది: tcpdump -ni any host 10.20.30.40.

దాన్ని అవతలి వైపు నివేదించే దానితో పోల్చండి. స్థానిక వైపు పాడ్ చిరునామాను చూపి సమాధానం లేని క్యాప్చర్ వృత్తాన్ని మూస్తుంది: మినహాయింపుల జాబితా టన్నెల్ లోపం లేకుండా అసమానతను వివరిస్తుంది. ఒకే మూల చిరునామపై రెండు పరిశీలనలు CNI గురించి ఊహించడం ఆపడానికి సరిపోతాయి.

మినహాయింపును పాడ్ CIDR వరకు తగ్గించండి

మద్దతు ఉన్న మరమ్మతు మినహాయింపును తీసివేయడం బదులు తగ్గిస్తుంది: పాడ్ CIDR ను మినహాయింపుగా ఉంచి 10.x స్థలంలో మిగిలినది వదిలేయండి. ఆ జాబితా ఏజెంట్ యొక్క ConfigMap లో nonMasqueradeCIDRs కింద ఉంటుంది, దాన్ని మార్చడం సవరణ మరియు తర్వాత విడుదల. విస్తృత ఎంట్రీని క్లస్టర్ యొక్క నిజమైన పాడ్ పరిధితో భర్తీ చేయండి, క్లస్టర్ లోపలి ట్రాఫిక్‌కు ఇంకా అవసరమైతే ఇతర ప్రైవేట్ బ్లాకులను ఉంచండి, కారణం లేకపోతే resyncInterval ను అలాగే ఉంచండి. వర్తింపజేయండి, ఏజెంట్ పాడ్‌లు పునఃప్రారంభమైనట్లు నిర్ధారించండి, కెర్నల్ నియమాలు మారినట్లు నిర్ధారించండి.

ఇది నిజమైన ప్రభావ పరిధి ఉన్న మొత్తం క్లస్టర్ మార్పు. అది అమల్లోకి వచ్చాక, ముందు తన పాడ్ మూలాన్ని నిలుపుకున్న ట్రాఫిక్ ఇప్పుడు నోడ్‌కు తిరిగి రాసి వస్తుంది, కాబట్టి ఆ పాడ్ చిరునామాలపై ఆధారపడిన ప్రతిదీ వేరే పంపినవారిని చూస్తుంది. బాధితులు పాడ్ చిరునామాలను పేర్కొనే లాగ్‌లు, అనుమతి జాబితాలు మరియు స్థానిక ఫైర్‌వాల్ నియమాలు, అవి నిశ్శబ్దంగా విఫలమవుతాయి. మార్పును మరమ్మతుగా కాదు, ప్రవర్తన మార్పుగా ప్రకటించండి.

అనేక నోడ్ పూల్‌లు ఉన్న క్లస్టర్‌లో, ప్రభావిత పాడ్‌లు నిజంగా నడిచే నోడ్‌లపై ఏజెంట్ షెడ్యూల్ అయిందా అని తనిఖీ చేయండి. DaemonSet లేని పూల్ తన పాత నియమాలను ఉంచుకుంటుంది, ConfigMap లో అది చూపించేది ఏమీ ఉండదు.

ప్రత్యామ్నాయం మరియు దాని ఖర్చు

మరో ఎంపిక పాడ్ చిరునామాలను తాకకుండా ఉంచి మార్గానికి వాటి గురించి నేర్పుతుంది. పాడ్ CIDR Cloud VPN ట్రాఫిక్ సెలెక్టర్‌లలోకి వెళ్తుంది, స్థానిక వైపు సమాధానాలు ఎక్కడికి వెళ్లాలో తెలియడానికి దానికి తిరిగి వెళ్లే మార్గం కావాలి. ఇది కొన్ని భద్రతా నమూనాలు కోరుకునే పాడ్ గుర్తింపును కాపాడుతుంది, అవతలి వైపు అంగీకరించాల్సిన రౌటింగ్ మరియు ఫైర్‌వాల్ పరిధి రెండింటినీ విస్తరిస్తుంది.

వ్యాపారం చదవగలిగేతనం మరియు పరిధి. అనువాదం స్థానిక వైపు ప్రతి నోడ్‌కు ఒక చిరునామా చూసేలా చేస్తుంది, దాన్ని అనుమతి జాబితాలో పెట్టడం సులభం మరియు ఏ పాడ్ ఏమి పంపిందో దాచుతుంది. అనువాదం లేకపోతే పాడ్ చిరునామా చివర నుండి చివర వరకు ఉంటుంది, అది ఆపాదనకు మంచిది మరియు కొత్త పరిధిని నేర్చుకోవాల్సిన మార్గంలోని ప్రతి పరికరానికి చెడు. ఏ ఎంపికా Docker లేదా CNI లోపం కాదు; రెండూ కార్యాచరణ బిల్లు ఉన్న రౌటింగ్ నిర్ణయాలు. మీ బృందం చెల్లించగల బిల్లు ఉన్నదాన్ని ఎంచుకోండి, ఎందుకో రాయండి.

ధృవీకరించి తిరిగి తీసుకోండి

అదే క్యాప్చర్‌ను మళ్లీ నడపండి. మీ సవరణ తర్వాత కూడా నోడ్ స్థాయి క్యాప్చర్ పాడ్ చిరునామాను ముద్రిస్తే, ConfigMap ఏమి చెప్పినా నియమాలు ఎప్పుడూ మారలేదని అర్థం. తీగే వాస్తవం; మిగతావన్నీ ఊహ.

తర్వాత వ్యతిరేక దిశను తనిఖీ చేయండి, ఎందుకంటే ఈ మార్పులలో సగం బయటకు మాత్రమే ధృవీకరించబడతాయి. సమాధానం అభ్యర్థన పంపిన నోడ్ లేదా పాడ్‌ను చేరుతుందా, అప్లికేషన్ SYN మాత్రమే తీసుకోకుండా పూర్తయిందా అని నిర్ధారించండి. సమాధానం లేని అభ్యర్థనను చూపే క్యాప్చర్ అవతలి వైపు రౌటింగ్ సమస్య, ఈ వైపు masquerade సమస్య కాదు.

తిరిగి తీసుకోవడం అంటే మునుపటి ConfigMap, అదే విధంగా వర్తింపజేసి, ఏజెంట్ పునఃప్రారంభమైంది మరియు నియమాలు మారాయని అదే నిర్ధారణతో. మార్పు రికార్డులో ఒక తెలిసిన అభ్యర్థన యొక్క మూల చిరునామాను ముందు మరియు తర్వాత ఉంచండి, ఎందుకంటే ఆ ఒక్క పంక్తే మార్పు మీరు చెప్పినట్లు చేసిందని రుజువు చేస్తుంది. GKE IP masquerade ఏజెంట్ గైడ్ డిఫాల్ట్‌లు మరియు ConfigMap ఫీల్డ్‌లను డాక్యుమెంట్ చేస్తుంది. విడుదల తర్వాత మూల చిరునామా మారకపోతే, ఆ నోడ్‌పై ఏజెంట్ నడవదు మరియు ఎంత YAML సవరణ చేసినా అది సరికాదు.