VPN గేట్‌వేకు IP ఫార్వర్డింగ్ అవసరం: ఏమి తనిఖీ చేయాలి
గేట్‌వే తన సొంత చిరునామాపై సమాధానం ఇవ్వగలదు, కానీ ఇంటర్‌ఫేస్‌ల మధ్య ఏదీ ప్రయాణించదు. ప్రతి కుటుంబానికి ఫార్వర్డింగ్, ఆపై తిరిగి వచ్చే మార్గాన్ని తనిఖీ చేయండి.
మీ క్లయింట్ గేట్‌వే చిరునామాకు పింగ్ చేయగలదు, అయితే దాని వెనుక ఉన్న ప్రతి వనరు చేరుకోలేనిదిగా ఉంటుంది. ఈ రెండు పరిశీలనలు మీతో మాట్లాడుతున్న హోస్ట్‌ను మరియు రూటింగ్ చేయని రౌటర్‌ను వివరిస్తాయి, అవి ఒకే యంత్రంలో వేర్వేరు పాత్రలు. ఫార్వర్డింగ్ వాటి మధ్య స్విచ్.
రెండు పాత్రలు స్వతంత్రం, రెండు చిరునామా కుటుంబాలు కూడా.
తన సొంత చిరునామాకు సమాధానం ఇవ్వడం ఏమీ నిరూపించదు
ఒక ప్యాకెట్ గేట్‌వేకే చిరునామా చేయబడినప్పుడు, స్థానిక స్టాక్ దాన్ని వినియోగిస్తుంది మరియు ఎలాంటి ఫార్వర్డింగ్ నిర్ణయం జరగదు. అందుకే టన్నెల్ చిరునామాకు లేదా నిర్వహణ ఇంటర్‌ఫేస్‌కు విజయవంతమైన పింగ్ డీమన్ సజీవంగా ఉందని మరియు టన్నెల్ పైన ఉందని చెబుతుంది, కానీ బాక్స్ వెనుక ఉన్న నెట్‌వర్క్ కోసం ఉద్దేశించిన ట్రాఫిక్ గురించి ఏమీ చెప్పదు. కర్నెల్ తనకు చిరునామా చేయని ప్యాకెట్‌లకు మాత్రమే తన ఫార్వర్డింగ్ మార్గాన్ని చూస్తుంది.
అవసరాన్ని సెట్టింగ్‌గా కాకుండా పాత్రగా చదవండి: ఈ హోస్ట్ రెండు ఇంటర్‌ఫేస్‌ల మధ్య ప్యాకెట్‌లను తరలించాలి. దూర నెట్‌వర్క్‌ను చేరుకోవడం మాత్రమే అవసరమైన ల్యాప్‌టాప్ ఆ పాత్రను ఎప్పుడూ తీసుకోదు, సైట్-టు-సైట్ ఎండ్‌పాయింట్ ఎల్లప్పుడూ తీసుకుంటుంది. అవసరాన్ని ఇలా చదవడం పని చేస్తున్న క్లయింట్ కాన్ఫిగరేషన్ గేట్‌వేకు మార్చినప్పుడు ఎందుకు విఫలమవుతుందో వివరిస్తుంది.
అదే వాక్యం ఫార్వర్డింగ్ నిర్ణయానికి ముందున్న ఫైర్‌వాల్‌కు కూడా వర్తిస్తుంది, ఏమి ఫార్వర్డ్ చేయవచ్చు అనే దానిపై దానికి సొంత విధానం ఉంది.
ప్రతి చిరునామా కుటుంబాన్ని విడిగా తనిఖీ చేయండి
IPv4 ఫార్వర్డింగ్ ఒక స్విచ్, IPv6 ఫార్వర్డింగ్ ప్రతి ఇంటర్‌ఫేస్‌కు సొంత ప్రవర్తన కలిగిన మరొకటి. మొదటిది ప్రారంభించడం రెండవది గురించి ఏమీ చెప్పదు, డ్యూయల్-స్టాక్ క్లయింట్ సగం నెట్‌వర్క్‌ను చేరుకోగలదు, మిగిలినది చీకటిగానే ఉంటుంది. అందుకే వేర్వేరు కుటుంబాల రెండు క్లయింట్‌లు ఒకే గేట్‌వే గురించి ఏకీభవించకపోవచ్చు. ఏ సెట్టింగ్‌ను సవరించే ముందు విఫలమైన క్లయింట్ ఏ కుటుంబాన్ని ఉపయోగించిందో అడగండి. రూటింగ్ డిజైన్ తప్పు అని నిర్ధారించే ముందు రెండింటినీ నిర్ధారించండి.
sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40అనేక పంపిణీలలో రన్‌టైమ్‌లో మీరు చదివే విలువను అక్కడ ఒక సేవ లేదా కాన్ఫిగరేషన్ ఫైల్ ఉంచి ఉంటుంది, కాబట్టి ఒకసారి ఉపయోగించే ఆదేశంతో చేసిన మార్పు రీబూట్‌లో అదృశ్యం కావచ్చు. రన్‌టైమ్ విలువను సవరించే ముందు ఈ సెట్టింగ్‌ను కలిగి ఉన్న ఫైల్‌ను కనుగొనండి.
ఫార్వర్డింగ్ నాలుగు అవసరాలలో ఒకటి
పని చేస్తున్న ఫార్వర్డ్ చేసిన ప్రవాహానికి ఒకేసారి నాలుగు విషయాలు అవసరం: క్లయింట్ గమ్యం టన్నెల్ వెనుక ఉందని తెలుసుకోవాలి, గేట్‌వేకు ముందుకు వెళ్లే మార్గం ఉండాలి, సమాధానాలకు తిరిగి వచ్చే మార్గం ఉండాలి, ఫైర్‌వాల్ ట్రాఫిక్‌ను అనుమతించాలి. మూల అనువాదం ఆ డిజైన్‌లో నియమంగా కాకుండా ఎంపికగా చేరుతుంది, ఎందుకంటే సమరూప మార్గాలున్న ప్రైవేట్ రూట్ చేసిన నెట్‌వర్క్‌కు అది అవసరం లేదు, అసమరూపానికి సాధారణంగా అవసరం. నాలుగింటిలో ప్రతి ఒక్కటి స్వతంత్రంగా విఫలమవుతుంది, అందుకే ఒకదాన్ని సరిచేయడం లక్షణాన్ని అరుదుగా కదిలిస్తుంది. ఏదైనా మార్చే ముందు నాలుగింటినీ రాయండి.
క్లౌడ్ ప్లాట్‌ఫారమ్‌లు ఐదవ పరిగణనను జోడిస్తాయి. కొన్ని ఇన్‌స్టాన్స్‌లపై మూల మరియు గమ్య తనిఖీలను అమలు చేస్తాయి, ఇది అతిథి కర్నెల్ ఎలా కాన్ఫిగర్ చేయబడినా ఫార్వర్డ్ చేసిన ప్యాకెట్‌లను వదిలివేస్తుంది. అక్కడ అధికారం ప్లాట్‌ఫారమ్ సొంత నెట్‌వర్కింగ్ పత్రాలకే, VM లోపలి sysctl అవుట్‌పుట్‌కు కాదు.
గేట్‌వే నుండి కాదు, క్లయింట్ నుండి పరీక్షించండి
గేట్‌వే సొంత షెల్‌లో నడిపిన పరీక్ష మీరు ఇప్పుడే ప్రారంభించిన ఫార్వర్డింగ్ మార్గంలోని ఏ భాగం గుండా వెళ్లదు. సమస్య ఉన్న క్లయింట్ నుండి ట్రాఫిక్‌ను సృష్టించి, అది గేట్‌వేకు కాకుండా గేట్‌వే వెనుక ఉన్న ఏదో ఒకదానికి చేరుతుందని నిర్ధారించండి. మీరు మార్చిన పాత్రను సాధన చేసే ఏకైక పరీక్ష అదే.
లిజనర్ నియమాలు మరియు ఫార్వర్డింగ్ నియమాలను మీ మనస్సులో మరియు మార్పు రికార్డులో విడిగా ఉంచండి. VPN పోర్ట్ తెరవడం క్లయింట్‌లను సేవలోకి అనుమతిస్తుంది; అది వారికి దాని వెనుక నెట్‌వర్క్‌లో ఏమీ ఇవ్వదు, సంవత్సరాలుగా పెరిగిన ఫైర్‌వాల్ జాబితాలో రెండూ ఒకేలా కనిపిస్తాయి.
ప్యాకెట్‌లు వచ్చి సేవ వినియోగదారుని తిరస్కరిస్తే, మీరు నెట్‌వర్కింగ్ దాటారు. ఫార్వర్డింగ్ విధానాన్ని మళ్లీ విస్తరించడం బదులు అప్లికేషన్ అనుమతితో కొనసాగండి.