net.ipv4.conf.default.forwarding tun0 ను ఎందుకు తాకదు

మీరు net.ipv4.conf.default.forwarding=1 సెట్ చేశారు, VPN ను మళ్లీ ప్రారంభించారు, అయినా గేట్‌వే రూట్ చేయాల్సిన ప్యాకెట్‌లను టన్నెల్ ఇప్పటికీ పడవేస్తోంది. ఫైల్‌లో సెట్టింగ్ సరిగ్గా కనిపిస్తోంది, ఇంటర్‌ఫేస్ ఇప్పటికీ ఫార్వార్డింగ్ ఆఫ్‌లో ఉందని నివేదిస్తోంది. ఏదీ పగలలేదు: మీరు భవిష్యత్ ఇంటర్‌ఫేస్‌లు వారసత్వంగా పొందే విలువను మార్చారు, సజీవ టన్నెల్ ఉపయోగించేది కాదు.

టన్నెల్ కలిగి ఉన్న హోస్ట్‌లో, టన్నెల్ నిజంగా ఉన్న నెట్‌వర్క్ namespace లో దీన్ని పరిశీలించండి. కంటైనర్ లేదా నెట్‌వర్క్ namespace ఇంటర్‌ఫేస్‌ను ఉంచుకోవచ్చు, హోస్ట్ వేరే సంఖ్యలను చూపుతుంది.

మూడు విలువలను కలిసి చదవండి

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

సాధారణ ఫలితం ip_forward = 0, default.forwarding = 1 మరియు tun0.forwarding = 0. మొదటి రెండు హోస్ట్ పాత్రపై ఏకీభవించవు, మూడవది ఇంటర్‌ఫేస్ నిజంగా ఏమి చేస్తుందో చూపిస్తుంది. ఈ కలయిక ఎప్పుడూ రౌటర్‌గా కాన్ఫిగర్ చేయబడని, టెంప్లేట్ విలువ మాత్రమే పొందిన హోస్ట్‌తో సరిపోతుంది. మూడు సంఖ్యలు ఒకదానికొకటి విరుద్ధం కావు; అవి మూడు వేర్వేరు ప్రశ్నలకు సమాధానమిస్తాయి. టెంప్లేట్ విలువ రాయడం కూడా హోస్ట్ పాత్రను నిర్ణయించదు.

ఎందుకు ప్రపంచ స్విచ్‌ే కదులుతుంది

net.ipv4.ip_forward గేట్‌వే అంతటా నియంత్రణ. దాన్ని మార్చడం అదే కార్యకలాపంలో భాగంగా ప్రతి ఇంటర్‌ఫేస్ ఫార్వార్డింగ్ సెట్టింగ్‌లను నవీకరిస్తుంది, అందుకే ఒకే రాయడం ఇప్పటికే ఉన్న టన్నెల్ ఫార్వార్డ్ చేయడం ప్రారంభించేలా చేయగలదు. default.forwarding తర్వాత ప్రారంభమయ్యే ఇంటర్‌ఫేస్‌లను మాత్రమే విత్తుతుంది, కాబట్టి ఇప్పటికే ఉన్న టన్నెల్ పుట్టిన విలువను నిలుపుకుంటుంది.

కర్నెల్ డాక్యుమెంటేషన్ ip_forward ను సంబంధిత కారణంతో ప్రత్యేకమని గుర్తిస్తుంది: దాన్ని మార్చడం ఇతర IPv4 పారామితుల సమూహాన్ని హోస్ట్ లేదా రౌటర్ డిఫాల్ట్‌లకు రీసెట్ చేస్తుంది. ఇది దాన్ని మొద్దుబారిన సాధనంగా చేస్తుంది. గేట్‌వే పాత్రను స్థాపించడంలో భాగంగా ఒకసారి సెట్ చేయడం మంచిది; డీబగ్గింగ్ ఉపాయంగా పదే పదే టోగుల్ చేయడం మీరు సమయం వెచ్చించి సరిచేసిన కాన్ఫిగరేషన్‌ను నిశ్శబ్దంగా తిరిగి రాయవచ్చు.

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

సెట్టింగ్‌ను సరైన చోట శాశ్వతం చేయండి

ఒక విజయవంతమైన ఒకసారి sysctl -w కర్నెల్ విలువను అంగీకరిస్తుందని నిరూపిస్తుంది. అది రీబూట్ తర్వాత నిలవదు, మళ్లీ కనెక్ట్ అయ్యేటప్పుడు ఇంటర్‌ఫేస్ కాన్ఫిగరేషన్ గురించి తన సొంత భావనను మళ్లీ వర్తింపజేసే నెట్‌వర్క్ మేనేజర్ తర్వాత కూడా నిలవదు. గేట్‌వే పాత్రను sysctl కాన్ఫిగరేషన్ ఫైల్‌లో లేదా హోస్ట్‌ను కలిగి ఉన్న నెట్‌వర్క్ మేనేజర్‌లో ఉంచండి, తర్వాత దాన్ని వర్తింపజేసే సేవను మళ్లీ ప్రారంభించండి.

టన్నెల్‌లలో క్రమం ముఖ్యం. మేనేజర్ బూట్‌లో ఇంటర్‌ఫేస్‌ను సృష్టించి తర్వాత ఫార్వార్డింగ్‌ను వర్తింపజేస్తే, ఇంటర్‌ఫేస్ పాత డిఫాల్ట్‌ను వారసత్వంగా పొందవచ్చు. టన్నెల్‌ను తిరిగి సృష్టించే సేవా రీస్టార్ట్ కూడా ఒక సృష్టి సంఘటన, యూనిట్ ఆరోగ్యంగా కనిపించినప్పుడు దాన్ని మిస్ చేయడం సులభం. చివరి ఫైల్ కంటెంట్ మాత్రమే కాదు, క్రమాన్ని తనిఖీ చేయండి.

VPN మళ్లీ కనెక్ట్ అయిన తర్వాత మరియు మళ్లీ రీబూట్ తర్వాత అదే మూడు విలువలను తిరిగి చదవండి. కొత్తగా సృష్టించిన టన్నెల్ కొత్త ఇంటర్‌ఫేస్, కొత్త ఇంటర్‌ఫేస్ సృష్టి క్షణంలో అమలులో ఉన్న డిఫాల్ట్‌ను తీసుకుంటుంది. ఈ సంఘటనల మధ్య సంఖ్యలు మారితే, మీరు ఇంకా గుర్తించని ఏదో కాన్ఫిగరేషన్‌ను వర్తింపజేస్తోంది.

తప్పు సాధనంతో దీన్ని సరిచేయవద్దు

ఫార్వార్డింగ్ పగిలినట్లు కనిపించినప్పుడు, ఫైర్‌వాల్‌ను ఖాళీ చేయాలని లేదా masquerading జోడించాలని ఆశ పుడుతుంది. రెండూ ఫార్వార్డింగ్ స్విచ్‌ను పరిష్కరించవు. ఫార్వార్డింగ్ స్థితి, ఫార్వార్డ్ చేయడానికి అనుమతి, గమ్యానికి మార్గం మరియు తిరిగి వచ్చే మార్గం — ఇవి నాలుగు వేర్వేరు అవసరాలు, మొదటిది మాత్రమే sysctl.

సరైన ప్రవాహంతో కూడా పరీక్షించండి. గేట్‌వేపైనే చేసిన అభ్యర్థన ఫార్వార్డింగ్‌ను అసలు ఉపయోగించదు; అది స్థానికంగా ఉత్పత్తి అయిన ట్రాఫిక్. ప్రశ్న ఏమిటంటే VPN క్లయింట్ లేదా LAN హోస్ట్ నుండి వచ్చే ప్యాకెట్ అంగీకరించబడి ముందుకు రూట్ అవుతుందా అనేది, కాబట్టి పరీక్ష గేట్‌వే వెనుక నుండి ప్రారంభం కావాలి.

IPv6 కేసును వేరుగా ఉంచండి

ఇక్కడ అంతా IPv4. IPv6 ఫార్వార్డింగ్, రౌటర్ ప్రకటనలు మరియు accept_ra ప్రవర్తనకు వాటి స్వంత నియంత్రణలు ఉన్నాయి, మరియు ipv4 మార్గాన్ని ipv6 సెట్టింగ్‌లోకి కాపీ చేయడం నమ్మదగినట్లు కనిపించే కానీ ఉపయోగకరమైనది ఏమీ చేయని ఫైల్‌ను ఉత్పత్తి చేస్తుంది. రెండు-స్టాక్ గేట్‌వే రెండు సెట్‌లను ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేయాలి.

చివరి తనిఖీ: విలువలు సరిపోయిన తర్వాత, టన్నెల్ మార్గం గమ్యానికి ఎంపిక అవుతోందని మరియు ప్రతిస్పందన మార్గం ఉందని నిర్ధారించండి. మార్గం లేని ఇంటర్‌ఫేస్‌పై ప్రారంభించిన ఫార్వార్డింగ్ ఇప్పటికీ నల్ల రంధ్రం, ఆ వైఫల్యం క్లయింట్ వైపు నుండి ఒకేలా కనిపిస్తుంది.