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

ఈ యంత్రాంగానికి రెండు భాగాలున్నాయి: టన్నెల్ ట్రాఫిక్ మాత్రమే ఉపయోగించాల్సిన రూటింగ్ పట్టిక, మరియు సరిపోలే మూలాన్ని అక్కడికి పంపే నియమం.

బైండింగ్ మూల చిరునామాను మాత్రమే సెట్ చేస్తుంది

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

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

టన్నెల్‌కు దాని సొంత పట్టిక ఇవ్వండి

wg-quick ప్రొఫైల్ చెప్పిన చోట మార్గాలను ఇన్‌స్టాల్ చేస్తుంది. [Interface] కింద Table = 40 జోడిస్తే అవి ప్రధాన పట్టికకు బదులు పట్టిక 40కి వెళ్తాయి. ఇంటర్‌ఫేస్‌ను పైకి లేపి అవి చేరుకున్నాయని నిర్ధారించుకోండి: ip -4 route ls table 40 టన్నెల్ మార్గాలను చూపాలి, ip -4 route get 10.66.127.142 కర్నెల్ ఇప్పుడు వాటిలో ఒకదాన్ని ఎలా పరిష్కరిస్తుందో చూపుతుంది. మార్గాలు తమ సొంత పట్టికలో ఉన్నప్పుడు ప్రధాన పట్టిక మిగతా అన్నింటికీ పని చేస్తూనే ఉంటుంది.

విశాలమైన ప్రిఫిక్స్‌ను సరిపోల్చడం బదులు IPv6కూ ఇదే చేయండి. ip -6 rule add from fd00::2/128 lookup 40 ఒక చిరునామాను పిన్ చేస్తుంది; fc00::/8 హోస్ట్‌లోని ఇతర ఇంటర్‌ఫేస్‌లతో ఢీకొని ఉద్దేశించినదానికంటే ఎక్కువ సరిపోలే నియమాన్ని సృష్టించవచ్చు.

మూల నియమాన్ని జోడించి కౌంటర్లను చూడండి

తర్వాత రెండు భాగాలను కలపండి: ip -4 rule add from 10.66.127.142/32 lookup 40, అదే చిరునామా WireGuard ఇంటర్‌ఫేస్‌కు జోడించి ఉంచి. రెండు నియమాలను PostUp లో పెట్టండి, తిరిగి కనెక్ట్ అయినప్పుడు అవి పునరుద్ధరించబడతాయి. సెట్టింగ్‌తో కాదు, నిజమైన అభ్యర్థనతో ధృవీకరించండి: ip route get 1.1.1.1 from 10.66.127.142 టన్నెల్ పరికరాన్ని పేర్కొనాలి, curl --interface wg0 ifconfig.me ఇంటి చిరునామా బదులు టన్నెల్ చిరునామాను నివేదించాలి.

అప్పటికీ విఫలమైతే ip -s rule చదవండి. ఉన్నా ఎప్పుడూ సరిపోలని నియమం సున్నా కౌంటర్లను చూపుతుంది, అదే తప్పు నియమాన్ని నియమమే లేకపోవడం నుండి వేరు చేస్తుంది. ఆ ఒక ఆదేశం యాప్ తన ఇంటర్‌ఫేస్ సెట్టింగ్‌ను నిర్లక్ష్యం చేసిందా అనే దానిపై చాలా ఊహలను ఆదా చేస్తుంది.

వ్యతిరేక సందర్భం: SSHను టన్నెల్ వెలుపల ఉంచండి

వ్యతిరేక సమస్యా అంతే సాధారణం: wg-quick డిఫాల్ట్ మార్గాన్ని కలిగి ఉంది మరియు సర్వర్‌కు SSH సెషన్ మధ్యలోనే మరణిస్తుంది. దాని నియమాలు తక్కువ ప్రాధాన్య సంఖ్యలో ఉంటాయి, కాబట్టి మినహాయింపు వాటికి ముందు మూల్యాంకనం చేయాలి. ip rule add dport 22 ipproto tcp table main priority 123 ఇటీవలి iproute2లో అలా చేస్తుంది; సెలెక్టర్ అందుబాటులో లేని చోట nftablesలో ప్రవాహాన్ని గుర్తించి బదులుగా మార్కును సరిపోల్చండి.

తిరిగి వచ్చే మార్గాన్ని కూడా తనిఖీ చేయండి. స్థాపించబడి తర్వాత నిశ్శబ్దమయ్యే SSH సెషన్‌లో సాధారణంగా అసమాన రూటింగ్ ఉంటుంది: ఒక దిశ టన్నెల్ ద్వారా, మరొకటి భౌతిక ఇంటర్‌ఫేస్ ద్వారా బయటకు వెళ్తుంది. సర్వర్ చిరునామా కోసం ip route get సమాధానం ఏ వైపు వెళ్తుందో చెబుతుంది.

పట్టిక సంఖ్య, మూల నియమం మరియు మినహాయింపును ప్రొఫైల్‌లోనే నమోదు చేయండి. మూడూ ఒకే రూపకల్పనకు చెందినవి, కలిసి సవరించబడతాయి.

సంబంధిత వ్యాసాలు