VPN పోర్టును తెరవడం క్లయింట్లను LAN వరకు చేర్చదు

టన్నెల్ పైకి వస్తుంది, క్లయింట్ ధృవీకరించబడుతుంది, కానీ గేట్‌వే వెనుక ఉన్న LAN కనిపించదు. దీన్ని సరిచేయాల్సిన నియమం VPN పోర్టును అనుమతిస్తుంది మరియు రాసినట్లుగానే పనిచేస్తుంది, ఎందుకంటే ఆ నియమం గేట్‌వేకే పంపిన ప్యాకెట్లను నియంత్రిస్తుంది. గేట్‌వే వెనుక ఉన్న హోస్ట్ వైపు వెళ్లే క్లయింట్ ట్రాఫిక్‌కు వేరే గమ్యం మరియు వేరే గొలుసు ఉంటాయి. విజయవంతమైన లాగిన్ కెర్నల్ ఏ గొలుసును చూస్తుందో మార్చదు.

రెండు గొలుసులు, రెండు వేరే గమ్యాలు

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

మొత్తం పురాణం ఒక వాక్యంలో: శ్రోతను అనుమతించడం అతని వెనుక ఉన్న నెట్‌వర్క్‌ను అనుమతించడం గురించి ఏమీ చెప్పదు. ఇవి వేరే సాక్ష్యాలతో ఉన్న రెండు వేరే నిర్ణయాలు, రెండింటిపై ఇంటర్‌ఫేస్ పేరు ఉండటం వాటిని ఒకటిగా చేయదు.

శ్రోత నియమం నిజంగా ఏమి అనుమతిస్తుంది

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

ప్రక్రియ వేరే గమ్యం కోసం క్లయింట్ ట్రాఫిక్‌ను డీక్యాప్సులేట్ చేసినప్పుడు, ప్యాకెట్ ఫార్వర్డింగ్ మార్గంలోకి ప్రవేశించి అక్కడ అనుమతి కావాలి. విజయవంతమైన ధృవీకరణ క్లయింట్ ఎవరో నిర్ణయిస్తుంది; ఎక్కడికి వెళ్లవచ్చో నిర్ణయించదు. రెండు ప్రశ్నలకు వేరే యజమానులు, లాగ్‌లు మరియు లోప సందేశాలు ఉంటాయి.

క్లయింట్ నుండి పరీక్షించండి, గేట్‌వే నుండి ఎప్పుడూ కాదు

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

ఫార్వర్డింగ్‌కు ఒకటి కాదు, మూడు కావాలి

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

మూడు అవుట్‌పుట్‌లను కలిపి చదవండి. మొదటిదానిలో సున్నా ఉంటే మిగతా రెండూ అప్రస్తుతం, రెండవదానిలో డిఫాల్ట్-డ్రాప్ విధానం ఉంటే క్లయింట్ ప్యాకెట్లు పడవేయబడతాయి, గేట్‌వే స్వంత ట్రాఫిక్ మాత్రం కొనసాగుతుంది. మూడవ అవుట్‌పుట్ శ్రోత నియమం ఎప్పుడూ సమస్య ఎందుకు కాలేదో చూపిస్తుంది.

పత్రాలలో రెండు నియమ సముదాయాలను వేరుగా ఉంచండి

శ్రోత నియమాన్ని మరియు ఫార్వర్డ్ చేసిన సేవ నియమాన్ని వేరే పంక్తులలో, వేరే యజమానులు మరియు కారణాలతో రాయండి. VPN పోర్టు మారినప్పుడు లేదా కొత్త సేవ ప్రచురించబడినప్పుడు, ఆ విభజన ఒక మార్పు మరొకదాన్ని నిశ్శబ్దంగా విస్తరించకుండా నిరోధిస్తుంది.

ప్రతి ధృవీకరించిన భాగస్వామిని నమ్మదగిన LAN సభ్యునిగా భావించే బదులు, అవసరమైన క్లయింట్ పరిధులు మరియు సేవలకు ఇరుకైన నియమాలను ఉపయోగించండి. StrongSwan ఫార్వర్డింగ్ గమనికలు అదే సరిహద్దు తిరిగి వచ్చే మార్గం మరియు అనువాద వైపును వివరిస్తాయి, అది మళ్లీ మూడవ నిర్ణయం.

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