Redsocks లూప్బ్యాక్లో వింటోంది కానీ VPN ట్రాఫిక్ ఎప్పటికీ చేరుకోదు

ఒక సొరంగం పైకి వస్తుంది, క్లయింట్ గేట్వేకు ping చేయగలదు, కానీ ప్రాక్సీ మార్గం గుండా వెళ్లే ప్రతి వెబ్ అభ్యర్థన చనిపోతుంది. redsocks ప్రక్రియ నడుస్తోంది మరియు దాని పోర్ట్ వింటోంది, కాబట్టి గేట్వే నుండే సేవ ఆరోగ్యంగా కనిపిస్తుంది. విఫలమయ్యేది డెలివరీ దశ: సొరంగం నుండి మళ్లించబడిన ప్యాకెట్ మీరు ప్రారంభించిన సాకెట్పై పడదు. బైండ్ చిరునామా మరియు మళ్లింపు లక్ష్యం సరిపోలాలి, సాధారణంగా వాటిలో ఒకటి మాత్రమే తనిఖీ చేయబడుతుంది.

మళ్లించబడిన ప్యాకెట్ నిజంగా ఎక్కడ పడుతుంది

గేట్వేపై పారదర్శక ప్రాక్సీ PREROUTING లోని nat పట్టికలో REDIRECT ఉపయోగించి వచ్చే కనెక్షన్ గమ్యాన్ని స్థానిక పోర్టుకు తిరిగి రాస్తుంది. తిరిగి రాసిన గమ్యం ప్యాకెట్ వచ్చిన ఇంటర్ఫేస్ నుండి కనిపించే స్థానిక చిరునామా, మరెక్కడో ప్రారంభించిన ప్రక్రియ యొక్క లూప్బ్యాక్ చిరునామా కాదు. 127.0.0.1 కు మాత్రమే కట్టుబడిన శ్రోత ఇప్పటికే హోస్ట్పై స్థానికంగా ఉన్న కనెక్షన్లను అంగీకరిస్తుంది, సొరంగ ట్రాఫిక్ విఫలమవుతున్నప్పుడు పని కొనసాగించే సందర్భం సరిగ్గా ఇదే. క్లయింట్ యొక్క స్వంత లూప్బ్యాక్ మూడవ చిరునామా మరియు ఎప్పటికీ గేట్వే నియమం యొక్క లక్ష్యం కాదు.

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

శ్రోతను మరియు మళ్లింపు నియమాన్ని కలిసి చదవండి

సాకెట్ పట్టికను మరియు nat నియమాలను ఒకే పాస్లో ముద్రించండి, ఎందుకంటే ఎవరూ కలిగి లేని పోర్టును సూచించే నియమం తప్పు చిరునామాను సూచించే నియమంలా కనిపిస్తుంది. sudo ss -ltnp | grep redsocks బైండ్ చిరునామా మరియు యజమాని ప్రక్రియను చూపుతుంది. sudo iptables -t nat -S PREROUTING REDIRECT లక్ష్యాన్ని చూపుతుంది, sudo iptables -t nat -L PREROUTING -v -n దానితో ఏదైనా సరిపోలిందా అని చూపుతుంది.

REDSOCKS అనే వినియోగదారు గొలుసుకు దూకడం ఆ గొలుసు లేకుండా మరియు ఉద్దేశించిన మినహాయింపులను, REDIRECT చర్యను కలిగి లేకుండా ఏమీ సాధించదు. పేరే పని చేస్తుందని ఊహించడం బదులు sudo iptables -t nat -S REDSOCKS తో అది దూకే గొలుసును చదవండి.

తర్వాత రెండు విలువలను పోల్చండి. నియమం పోర్ట్ 12345 లోని గేట్వే చిరునామాకు మళ్లిస్తే మరియు శ్రోత 127.0.0.1:12345 అని నివేదిస్తే, ఆ అసమతౌల్యం అదనపు నిర్ధారణ లేకుండా వైఫల్యాన్ని వివరిస్తుంది.

ఇరుకుగా కట్టండి, తర్వాత ఏది దాన్ని చేరుకోగలదో పరిమితం చేయండి

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

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

క్లయింట్ నుండి కొత్త కనెక్షన్తో దాన్ని నిరూపించండి

గేట్వేపై షెల్ నుండి కాదు, నిజమైన VPN క్లయింట్ నుండి కొత్త TCP కనెక్షన్తో పరీక్షించండి. క్లయింట్పై curl -sS -o /dev/null -w '%{http_code}\n' http://example.com మళ్లించబడిన మార్గాన్ని మొదటి నుండి చివరి వరకు నడుపుతుంది.

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

చివరగా, ఈ మార్గం ఏమి కవర్ చేయదో గుర్తుంచుకోండి. సాధారణ redsocks TCP మళ్లింపు UDP, QUIC లేదా DNS ను SOCKS ట్రాఫిక్గా మార్చదు, మరియు ప్రైవేట్ గమ్యాలకు సాధారణంగా స్పష్టమైన మినహాయింపులు అవసరం. విజయవంతమైన స్థానిక పరీక్ష ఎప్పుడూ సమస్య కాని లూప్బ్యాక్ మార్గాన్ని మాత్రమే నిరూపిస్తుంది.