మీ పబ్లిక్ Linux సేవ VPN ద్వారా ఎందుకు సమాధానం ఇస్తుంది

సాకెట్లో ఏ ఇంటర్ఫేస్ అభ్యర్థనను మోసుకొచ్చిందో గుర్తుంచుకునేది ఏదీ లేదు, కాబట్టి పూర్తి-టన్నెల్ VPN యొక్క డిఫాల్ట్ మార్గం WAN కు చెందాల్సిన సమాధానాన్ని పట్టుకోగలదు. సేవ లోపలికి వచ్చే ఇంటర్ఫేస్ను పట్టించుకోకుండా లేదు; Linux స్థానికంగా సృష్టించిన సమాధానాన్ని గమ్యం మరియు మూల విధానం ప్రకారం మార్గనిర్దేశం చేస్తుంది. మూల ఆధారిత నియమం బదులుగా సేవ యొక్క సమాధానాలను మాత్రమే పూర్తి WAN పట్టిక ద్వారా పంపి సాధారణ బయటకు వెళ్లే ప్రవాహాన్ని టన్నెల్లోనే ఉంచగలదు. సమాధానం తప్పు మార్గం నుంచి బయటకు వెళ్తున్నప్పటికీ పోర్టు తెరిచే ఉంటుంది, అందుకే లక్షణం ఏకపక్షంగా కనిపిస్తుంది.

తప్పు అవగాహన: సమాధానాలు అవి వచ్చిన ఇంటర్ఫేస్ను అనుసరిస్తాయి

eth0 పై వచ్చే ప్యాకెట్ eth0 ద్వారానే వెళ్లాలని తార్కికంగా అనిపిస్తుంది. స్థితిలేని ప్యాకెట్ ఫిల్టర్లను అలా రాయవచ్చు, మరియు లోపలికి వచ్చే వైపు tcpdump అభ్యర్థనను సరిగ్గా ఆశించిన చోటే చూపిస్తుంది. హోస్ట్ తానే సృష్టించే ట్రాఫిక్కు మార్గనిర్దేశం అలా పనిచేయదు.

సేవ కనెక్షన్ను స్వీకరించిన తర్వాత దాని సమాధానం కొత్తగా స్థానికంగా సృష్టించిన ప్యాకెట్. కర్నెల్ సమాధానం యొక్క గమ్యం మరియు మూలానికి మార్గనిర్దేశక నియమాలను చూస్తుంది, మరియు VPN యొక్క డిఫాల్ట్ మార్గం పూర్తిగా చెల్లుబాటు అయ్యే సమాధానం. సాకెట్లో ఏ ఇంటర్ఫేస్ అభ్యర్థనను మోసుకొచ్చిందో గుర్తుంచుకునేది ఏదీ లేదు.

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

కర్నెల్ నిజంగా ఏమి మార్గనిర్దేశం చేస్తుంది: మూల చిరునామా

మీకు కావాల్సిన హ్యాండిల్ అంటే సేవ సమాధానాల కోసం ఉపయోగించే స్థానిక చిరునామా. eth0 చిరునామా ఉదాహరణకు 192.0.2.10/24 మరియు గేట్వే 192.0.2.1 ఉన్న హోస్ట్లో ఆ చిరునామా ఇంటర్ఫేస్పై ఉంటుంది. క్లౌడ్ VM లో పబ్లిక్ చిరునామా పైన అనువదించబడి అతిథిలో లేకపోవచ్చు, కాబట్టి హోస్ట్ నిజంగా కలిగి ఉన్న చిరునామానే ఉపయోగించండి.

పట్టిక సంఖ్య లేదా నియమ ప్రాధాన్యాన్ని రిజర్వ్ చేసే ముందు ప్రస్తుత స్థితిని పరిశీలించండి. ఉన్న విధాన నియమాలు కొత్తదాన్ని కప్పివేయగలవు, మరియు అదే సంఖ్య ఉన్న పాత పట్టిక ఇప్పటికే సంబంధం లేని మార్గాలను కలిగి ఉండవచ్చు:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

సగం డిఫాల్ట్ కాదు, పూర్తి రిటర్న్ పట్టికను నిర్మించండి

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

ఉదాహరణను కాపీ చేయడం బదులు నిజమైన ప్రిఫిక్స్ మరియు గేట్వేను ఉపయోగించండి. ఆన్-లింక్ గేట్వేతో /32 గా కాన్ఫిగర్ చేసిన క్లౌడ్ ఇంటర్ఫేస్కు వేరే కనెక్ట్ అయిన మార్గం కావాలి, మరియు తప్పు ప్రిఫిక్స్ నుంచి నిర్మించిన పట్టిక మొదటి హాప్లోనే విఫలమవుతుంది. src లక్షణం ఆ మార్గానికి ఇష్టమైన మూలాన్ని తెలియజేస్తుంది; అది మూల నియమాన్ని భర్తీ చేయదు.

క్రమం కూడా ముఖ్యం. తక్కువ ప్రాధాన్య సంఖ్య ఉన్న విస్తృత నియమం మొదట అంచనా వేయబడుతుంది, కాబట్టి ఈ ట్రాఫిక్ను ప్రధాన పట్టికకు తిరిగి పంపగల ఏ నియమం కంటే ముందు మూల నియమానికి చేరాలి. జోడించిన తర్వాత ip rule show తో ప్రాధాన్యాలను తనిఖీ చేయండి, బూట్లో మాత్రమే కాదు.

మూల-నిర్దిష్ట శోధనతో ధృవీకరించండి

సేవ చిరునామా నుంచి పరీక్ష గమ్యానికి మార్గనిర్దేశం చేయమని కర్నెల్ను అడగండి. సమాధానంలో టన్నెల్ కాదు, eth0 మరియు WAN గేట్వే పేరు ఉండాలి:

ip -4 route get 198.51.100.25 from 192.0.2.10

తర్వాత కొత్త అధికృత కనెక్షన్ ఏర్పాటు చేసి రెండు దిశలను గమనించండి. సరైన పట్టికను ఎంచుకునే శోధనలో ప్రత్యక్ష కనెక్షన్ ఇంకా విఫలమైతే అది పట్టికను కాదు, రివర్స్-పాత్ ఫిల్టరింగ్ లేదా ఫైర్వాల్ నియమాన్ని సూచిస్తుంది. ఏదైనా ప్రపంచవ్యాప్తంగా నిలిపివేసే ముందు ఆ నియంత్రణలను తనిఖీ చేయండి.

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

ఈ మినహాయింపు ఎక్కడ ఆగుతుంది

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

ఇది హోస్ట్ యొక్క పబ్లిక్ చిరునామాను ఇంటర్ఫేస్పై కనిపించేలా కూడా చేయదు. పైనున్న NAT ఆ చిరునామాను కలిగి ఉన్నప్పుడు, ఆ NAT ఆశించే మార్గం ద్వారానే సమాధానం బయటకు వెళ్లాలి, అందుకే WAN పట్టిక ఊహించిన పబ్లిక్ పరిధి బదులు అసలు గేట్వే మరియు ప్రిఫిక్స్ను ప్రతిబింబించాలి.

మినహాయింపును దాని పట్టిక సంఖ్య, నియమ ప్రాధాన్యం మరియు ఖచ్చితమైన మూల చిరునామాతో పాటు డాక్యుమెంట్ చేసి ఉంచండి. VPN లేదా ఇంటర్ఫేస్లో తదుపరి మార్పు దాన్ని నిశ్శబ్దంగా విరగ్గొట్టగలదు, మూడు విలువలను పేర్కొనే గమనిక కస్టమర్ నివేదిక నుంచి లక్షణాన్ని మళ్లీ కనుగొనడం కంటే వేగంగా తనిఖీ చేయబడుతుంది.

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