VPN చిరునామాకు బద్ధమైన యాప్ ఇప్పటికీ తప్పు మార్గాన్ని ఉపయోగిస్తుంది

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

ఈ రన్‌బుక్‌లో మిగిలినది నేను ఉపయోగించే తనిఖీ క్రమం, ప్రతి పరిశీలనను ఇచ్చే ఆదేశంతో పాటు.

బైండ్ నిజంగా ఏమి నిర్ణయిస్తుంది

బైండ్ సాకెట్‌కు స్థానిక చిరునామాను కేటాయిస్తుంది. తర్వాత విధాన నియమం ఆ లుకప్ చదివే పట్టికను మార్చకపోతే, కర్నెల్ మరోలా చేసి ఉండే అదే మార్గ లుకప్‌ను చేస్తుంది.

అందుకే ప్యాకెట్ భౌతిక ఇంటర్‌ఫేస్‌పై VPN మూల చిరునామాతో బయటకు వెళ్లవచ్చు. ఆవలి వైపు అది నెట్‌వర్క్ ఆ మార్గంలో ఎప్పుడూ ఊహించని ప్రైవేట్ పరిధి నుండి వస్తుంది, తిరిగి వచ్చే ట్రాఫిక్‌కు తిరిగి వెళ్లే మార్గం ఉండదు, కనెక్షన్ వేలాడుతుంది లేదా రీసెట్ అవుతుంది.

Linux IP సాకెట్ సూచన బైండ్ అర్థాన్ని నమోదు చేస్తుంది. రౌటింగ్ సగం ip-rule మరియు ip-routeలో ఉంటుంది, అవి ఒక కారణంతో వేర్వేరు మాన్యువల్స్.

చిరునామా ఈ నేమ్‌స్పేస్‌కు చెందినదని నిర్ధారించండి

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

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

ఆ మూలం మరియు గమ్యం కోసం లుకప్‌ను చదవండి

ఒక ఆదేశం బైండ్ జవాబివ్వని ప్రశ్నకు జవాబిస్తుంది:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

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

అదే డిజైన్ అయితే మాత్రమే విధాన నియమాన్ని ఇన్‌స్టాల్ చేయండి

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

పనిచేసే రూపం టన్నెల్ ద్వారా డిఫాల్ట్ మార్గం ఉన్న ప్రత్యేక పట్టిక, దానితో పాటు VPN మూల పరిధిని ఆ పట్టికకు పంపే నియమం. డిజైన్‌కు అవసరమైన మినహాయింపులను జోడించండి, ఎందుకంటే టన్నెల్ డిఫాల్ట్ మాత్రమే ఉన్న పట్టిక స్థానికంగా ఉండాల్సిన లేదా భౌతిక మార్గం ద్వారా చేరుకోవాల్సిన గమ్యాలను కూడా పట్టుకుంటుంది.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del మరియు ip route flush table 100 తో వెనక్కి తీసుకోండి. ఈ విధంగా జోడించినదంతా రీబూట్‌లో అదృశ్యమవుతుంది, మేనేజర్ రాస్తే తప్ప; ఇది భద్రతా లక్షణం మరియు ఏకైక కాపీని మీ షెల్ చరిత్రలో ఉంచకపోవడానికి కారణం కూడా.

మూడు పరిశీలనలతో ధృవీకరించండి

యాప్ అడిగిన మూలం, లుకప్ ఎంచుకున్న మార్గం, మరియు సర్వర్ నిజంగా చూసిన మూలాన్ని నమోదు చేయండి.

ఈ మూడూ భిన్నంగా ఉండవచ్చు, ప్రతి భేదం వేరే చోటుకు సూచిస్తుంది. టన్నెల్ ఇంటర్‌ఫేస్‌పై క్యాప్చర్ ప్యాకెట్ సరైన మూలంతో బయటకు వెళ్లిందని నిరూపిస్తుంది. భౌతిక ఇంటర్‌ఫేస్‌పై క్యాప్చర్ అది తప్పు దారిన బయటకు వెళ్లిందని నిరూపిస్తుంది. మార్గాన్ని మొదటి నుండి చివరి వరకు నిరూపించేది సర్వర్ వైపు దృశ్యం మాత్రమే.

యాప్ పరికరానికి బద్ధం చేయడం ఎంపిక లేదా ప్రతి యాప్ రౌటింగ్ మోడ్ అందిస్తే, దాన్ని వేరే పరిమితులున్న వేరే యంత్రాంగంగా పరిగణించండి. చూడటానికి సమానమైన సెట్టింగ్‌లు అన్నీ ఒకే కర్నెల్ నిర్ణయానికి చేరుకోవు.