VPN గేట్వే పునఃప్రారంభం తర్వాత కూడా IPv4 ఫార్వర్డింగ్ నిలిచి ఉండేలా చేయండి

గేట్వేకు ping పనిచేస్తుంది కానీ దాని వెనుక ఏదైనా చేరుకోవడం పనిచేయదు, మరియు ఇది టన్నెల్ సమస్య కాదు, ఫార్వర్డింగ్ సమస్య రూపం. గేట్వేకు స్థానిక డెలివరీ టన్నెల్ పైకి వచ్చిందని మరియు చిరునామా కేటాయింపు పనిచేసిందని నిరూపిస్తుంది; కెర్నల్ ఒక ఇంటర్ఫేస్ నుండి మరొకదానికి ప్యాకెట్ను పంపుతుందా అనే దాని గురించి ఏమీ చెప్పదు. ఏదైనా sysctl ను తాకే ముందు, ఈ ట్రాఫిక్ను రూట్ చేయడానికి యంత్రం ఉద్దేశించబడిందని నిర్ధారించండి మరియు క్లయింట్ వైపు ఇంటర్ఫేస్ ఉన్న నెట్వర్క్ సందర్భాన్ని కనుగొనండి. తర్వాత విలువను అక్కడే చదవండి, మీరు చదివిన చివరి మార్గదర్శిని యాదృచ్ఛికంగా చూసిన చోట కాదు.

గేట్వేను చేరుకోవడం ఫార్వర్డింగ్ వంటిది కాదు

కెర్నల్ లోపల రెండు వేర్వేరు నిర్ణయాలు జరుగుతాయి. స్థానిక చిరునామాకు డెలివరీ ప్యాకెట్ ప్రయాణాన్ని ముగిస్తుంది; ఫార్వర్డింగ్ దానిని మరొక ఇంటర్ఫేస్ ద్వారా తిరిగి బయటకు పంపుతుంది, మరియు ఆ రెండవ నిర్ణయం ప్రతి నెట్వర్క్ నేమ్స్పేస్కు నియంత్రించబడుతుంది. ఫార్వర్డింగ్ ఆఫ్ ఉన్నప్పటికీ గేట్వే పూర్తిగా చేరుకోగలిగేదిగా ఉండవచ్చు, మరియు ping ప్రాంప్ట్ నుండి ఆ రెండు వైఫల్యాలు ఒకేలా కనిపిస్తాయి.

క్లయింట్ ప్యాకెట్ ఏ ఇంటర్ఫేస్కు వస్తుంది మరియు తదుపరి మార్గం ఏ ఇంటర్ఫేస్ ద్వారా బయటకు వెళ్తుంది అని రాయండి. రెండూ ఒకే నేమ్స్పేస్కు చెందుతాయి, మరియు ముఖ్యమైన సెట్టింగ్ ఆ నేమ్స్పేస్లో ఉంది.

ప్యాకెట్లు నిజంగా ఉన్న చోటే విలువను చదవండి

హోస్ట్ నేమ్స్పేస్లో రూట్ చేసే గేట్వేపై, ఒకే ఆదేశం ప్రశ్నకు సమాధానం ఇస్తుంది: sysctl net.ipv4.ip_forward. ఇన్గ్రెస్ మరియు తదుపరి మార్గం పేరున్న నేమ్స్పేస్లో ఉన్నప్పుడు, ఆ నేమ్స్పేస్ను అడగండి: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. హోస్ట్ విలువ నేమ్స్పేస్ విలువకు ప్రత్యామ్నాయం కాదు, మరియు హోస్ట్పై ఒకటి ఉండటం ఏదానికీ సాక్ష్యం కాదు.

ప్రతి రూటింగ్ సందర్భానికి ip netns కు ఇవ్వగల లేబుల్ ఉండదు. కంటైనర్ రన్టైమ్లు మరియు సేవలు స్నేహపూర్వక పేరుతో ఎప్పుడూ నమోదు చేయబడని నేమ్స్పేస్లను సృష్టిస్తాయి, మరియు వాటికి మీరు రన్టైమ్ యొక్క తనిఖీ పరికరాలను ఉపయోగిస్తారు. vpn-gw స్థానంలో నిజమైన పేరు లేదా అదే సందర్భానికి చేరే రన్టైమ్ విధానాన్ని పెట్టండి, మరియు హోస్ట్ స్థాయిలో ఊహించడం ఆపండి.

సెట్టింగ్కు ఒకే యజమానిని ఇవ్వండి

సాంప్రదాయిక systemd హోస్ట్ గేట్వేపై, నిలకడ ఉండే రూపం నిర్వాహకుడు ఎంచుకున్న పేరుతో drop-in ఫైల్, ఉదాహరణకు /etc/sysctl.d/60-vpn-forwarding.conf, అందులో net.ipv4.ip_forward = 1 ఉంటుంది. ఫైల్ను రాయండి, తర్వాత ప్రత్యక్ష స్థితి కూడా మారేలా అదే నిర్దిష్ట ఫైల్ను లోడ్ చేయండి: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, ఆ తర్వాత తిరిగి చదివి తనిఖీ చేయండి. ఫైల్ పేరు ఒక ఉదాహరణ, రిజర్వ్ చేసిన VPN మార్గం కాదు, మరియు మొదటి సంఖ్య ముఖ్యం ఎందుకంటే తర్వాత క్రమబద్ధీకరించిన ఫైళ్లు గెలుస్తాయి.

ప్రాధాన్యత అనేది నిలకడ నిశ్శబ్దంగా విరిగే చోటు. పంపిణీ లోడర్ మరియు మీ స్వంత drop-in రెండింటినీ తనిఖీ చేయండి, ఎందుకంటే procps sysctl --system చివరలో /etc/sysctl.conf కూడా చదువుతుంది, అయితే systemd యొక్క sysctl.d క్రమం పూర్తిగా వేరే క్రమం. తర్వాతి కేటాయింపు అదే కీని వెంటనే తిరిగి పెట్టగలదు, మీ ఫైల్ సరిగ్గా ఉండి ప్రభావవంతమైన విలువ తప్పుగా ఉండేలా చేస్తుంది. ఆ వాదనను గెలవడానికి ఉన్న నిర్వాహక ఫైల్ను తిరిగి రాయవద్దు; యజమానిని కనుగొని అక్కడే మార్చండి.

బూట్ తర్వాత సృష్టించిన నేమ్స్పేస్ హోస్ట్ drop-in ద్వారా అసలు నియంత్రించబడదు. దాని సెట్టింగ్ దానిని సృష్టించేదానికి చెందుతుంది, అది కంటైనర్ రన్టైమ్ అయినా నేమ్స్పేస్ ప్రొవిజనింగ్ యూనిట్ అయినా. ప్రశ్నను తప్పించుకోవడానికి కంటైనర్కు విస్తృత హోస్ట్ అధికారాలను ఇవ్వడం సరైన యజమానిని గుర్తించడానికి పది నిమిషాలు వెచ్చించడం కంటే చెడ్డ ఒప్పందం.

స్విచ్ను తిప్పే ముందు దాని ఖరీదు తెలుసుకోండి

ip_forward హానికరం కాని బూలియన్ కాదు. కెర్నల్ పత్రాలు దానిని మార్చడం అనేక ఇతర IPv4 పారామితులను హోస్ట్ లేదా రూటర్ డిఫాల్ట్లకు రీసెట్ చేస్తుందని పేర్కొంటాయి, కాబట్టి నిర్ధారణ కోసం తిప్పడం వేరే చోట చేసిన ట్యూనింగ్ను పారవేసి దాని గురించి ఎప్పుడూ ప్రస్తావించకపోవచ్చు. దానిని నిర్లక్ష్యంగా అమలు చేయగల పరీక్షగా కాకుండా, దుష్ప్రభావాలు ఉన్న కాన్ఫిగరేషన్ మార్పుగా పరిగణించండి.

క్లయింట్ హోస్ట్ను చేరుకోలేని ప్రతిసారీ దానిని ఆఫ్ చేసి ఆన్ చేయడాన్ని కూడా ఇది మినహాయిస్తుంది. విలువ ఇప్పటికే ఒకటి అయితే, లోపం మార్గంలో మరెక్కడో ఉంది, మరియు అదే కీని మూడవసారి తిరిగి రాయడం దానిని కదిలించదు.

నిలకడను నిరూపించండి, తర్వాత మార్గంలో మిగిలిన భాగాన్ని పరీక్షించండి

నాలుగు క్షణాలలో విలువను తిరిగి చదవండి: మార్పు తర్వాత వెంటనే, VPN ఇంటర్ఫేస్ కనిపించిన తర్వాత, తిరిగి కనెక్ట్ అయిన తర్వాత, మరియు ప్రణాళికాబద్ధమైన పునఃప్రారంభం తర్వాత. ఆ బిందువులలో ఏదైనా వెనక్కి తిరిగే విలువకు రెండవ యజమాని ఉంటాడు, మరియు మరోసారి రాయడం దానిని తదుపరి రీబూట్ వరకు మాత్రమే దాచుతుంది.

ఫార్వర్డింగ్ ప్రారంభించి ఉన్నా మూడు విషయాలు తనిఖీ చేయాల్సి ఉంటుంది. క్లయింట్కు గమ్యస్థానానికి మార్గం కావాలి, గేట్వేకు తదుపరి మార్గం మరియు దాన్ని ఉపయోగించడానికి అనుమతి కావాలి, గమ్యస్థానానికి క్లయింట్ టన్నెల్ చిరునామాకు తిరిగి వెళ్లే మార్గం కావాలి. ప్రైవేట్ రూట్ చేసిన LAN కు స్వయంచాలకంగా NAT అవసరం లేదు, కాబట్టి మూడింటిలో ఏది లేదో తెలిసే ముందు masquerading జోడించవద్దు, మరియు గేట్వే నుండి కాకుండా ఉద్దేశించిన క్లయింట్ నుండి పరీక్షించండి, ఎందుకంటే గేట్వేపై పుట్టిన అభ్యర్థన మీరు ఇప్పుడు ప్రారంభించిన ఫార్వర్డింగ్ మార్గాన్ని ఎప్పుడూ తాకదు. IPv6కు దాని స్వంత ఫార్వర్డింగ్ మరియు రూటింగ్ విధానం ఉంది, కాబట్టి పనిచేసే IPv4 పరీక్ష దాని గురించి ఏమీ చెప్పదు.

drop-in మార్గం, నేమ్స్పేస్ యజమాని మరియు తిరిగి చదివే ఆదేశాన్ని runbookలో కలిసి ఉంచండి. దీన్ని తర్వాత తీసుకునేవారు విలువను చదవగలగాలి, యజమాని ఎవరో చూడగలగాలి, మరియు సమస్య నిలకడదా లేక మార్గంలో మిగిలిన భాగమా అని ఒక నిమిషంలో నిర్ణయించగలగాలి.