OpenVPN కోసం SOCKS5 ప్రాక్సీ: TCP సొరంగం లేదా యాప్‌లను ప్రాక్సీ చేయడమా?

ప్రాక్సీ ద్వారా మాత్రమే బయటకు వెళ్లడానికి అనుమతించే నెట్‌వర్క్‌లే పనిచేస్తున్న ప్రొఫైల్ అకస్మాత్తుగా మరణించే ప్రదేశం. ప్రాక్సీ చిరునామా ఆ వైఫల్యంలో అత్యంత ఆసక్తికరం కాని వేరియబుల్. ప్రతిదీ ప్రాక్సీ పంపబోయే ట్రాఫిక్ ఆకారం నిర్ణయిస్తుంది, ఎందుకంటే ఈ ప్రాక్సీలు బైట్ స్ట్రీమ్‌ను పంపుతాయి మరియు UDP సొరంగం అలా కాదు. ఇది రెండు నిర్మాణాలను మిగులుస్తుంది, అవి వేర్వేరు చోట్ల విరిగిపోతాయి.

ఒక పరిమితి రూపకల్పనను నిర్ణయిస్తుంది

SOCKS5 నిజంగానే UDP అనుబంధ మోడ్‌ను నిర్దేశిస్తుంది. అయినప్పటికీ OpenVPN క్లయింట్ ప్రాక్సీ మద్దతు స్ట్రీమ్‌ల చుట్టూ నిర్మించబడింది: socks-proxy TCP ప్రొఫైల్‌ల కోసం డాక్యుమెంట్ చేయబడింది, మరియు HTTP CONNECT ప్రాక్సీకి డేటాగ్రామ్‌లకు ఎలాంటి మార్గం లేదు. డాక్యుమెంటేషన్‌లోని ఒక వరుస కాన్ఫిగరేషన్ ఫైల్‌ను తాకే ముందే నిర్మాణాన్ని నిర్ణయిస్తుంది.

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

ఎంపిక A: సొరంగాన్ని స్ట్రీమ్ చేయండి

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

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

చివరి వరుసను http-proxy proxy.internal 8080 తో భర్తీ చేయండి ప్రాక్సీ HTTP మాట్లాడినప్పుడు, అవసరమైతే ఆధారాల ఫైల్‌ను జోడించండి. ప్రాక్సీ మీ VPN పోర్టుకు CONNECT చేయడానికి సిద్ధంగా ఉండాలి, సర్వర్ TCPలో సమాధానం ఇవ్వాలి; UDP మాత్రమే శ్రోత ఆ ప్రయత్నాన్ని పట్టించుకోదు. 443 ఎంచుకోవడం ఆచరణాత్మక చర్య, ఎందుకంటే చాలా నిర్బంధ నెట్‌వర్క్‌లు దానిని మరియు కొద్దిగా మిగతావి మాత్రమే అనుమతిస్తాయి.

ఖర్చు TCP పైన TCP పేర్చడం. ఒక పోయిన బయటి విభాగం ఆ కనెక్షన్‌ను పంచుకునే ప్రతి లోపలి స్ట్రీమ్‌ను ఆపుతుంది, కాబట్టి సాధారణంగా స్వతంత్రంగా ఉండే పునరుద్ధరణ పంచుకోబడినది అవుతుంది. సెటప్ ఎక్కువ సమయం తీసుకుంటుంది, అస్థిరమైన బయటి మార్గం నెమ్మదైన దానికి బదులుగా అస్థిరమైన సొరంగం అవుతుంది.

ఎంపిక B: సొరంగాన్ని ఒంటరిగా వదిలేయండి

సొరంగం UDPలోనే ఉండాల్సినప్పుడు, ఏదైనా కాన్ఫిగర్ చేసే స్థలం సొరంగం కాదు. బదులుగా యాప్‌ల నుండి బయటకు వెళ్లే TCP స్థానిక SOCKS శ్రోతకు మళ్లించబడుతుంది, యాప్‌లు ప్రాక్సీ ఉందని ఎప్పటికీ తెలుసుకోవు. Linuxలో ఇది సాధారణంగా redsocks మరియు nat పట్టికలో NAT REDIRECT నియమం.

మళ్లీ TCP మాత్రమే. privoxy వంటి HTTP మాత్రమే ప్రాక్సీ ఏకపక్ష ప్రోటోకాల్‌లను పంపలేదు, ఈ రూపకల్పన యాప్‌లకు డేటాగ్రామ్ మద్దతును కూడా జోడించదు.

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

ప్రతి ఎంపిక ఎక్కడ విఫలమవుతుంది

సర్వర్‌కు TCP శ్రోత లేనప్పుడు, ప్రాక్సీ CONNECT లక్ష్యాన్ని తిరస్కరించినప్పుడు, లేదా బయటి స్ట్రీమ్ సొరంగానికి అవసరమైన దానికంటే తక్కువకు పరిమితం చేయబడినప్పుడు ఎంపిక A విఫలమవుతుంది. మొదటి రెండు ప్రాక్సీ లాగ్‌లో నమోదు వదిలివేస్తాయి; మూడవది స్థాపించబడి తర్వాత తప్పుగా అనిపించే కనెక్షన్‌ను వదిలివేస్తుంది. ప్రొఫైల్ సవరించే ముందు ఆ లాగ్‌ను చదవండి, ఎందుకంటే అది అనుమతి సమస్యను సామర్థ్య సమస్య నుండి వేరు చేస్తుంది. పూర్తయిన CONNECT దర్యాప్తును సొరంగం లోపలికి తరలిస్తుంది.

డేటాగ్రామ్‌లు అవసరమయ్యే ప్రతిదానికీ, ప్రాక్సీకి అర్థం కాని ప్రోటోకాల్‌లకు, మళ్లింపు నియమం ఉన్నా రూటింగ్ ట్రాఫిక్‌ను దాని పక్కన నుండి పంపే హోస్ట్‌లలో ఎంపిక B నిశ్శబ్దంగా విఫలమవుతుంది.

ఏ ఎంపిక పరికర అవసరాన్ని మార్చదు. కెర్నల్ రూట్ చేయడానికి ముందు ప్యాకెట్‌లకు ఇంకా TUN లేదా TAP నోడ్ అవసరం, కాబట్టి ప్రక్రియకు ఇంకా /dev/net/tun పై అనుమతి అవసరం. ర్యాపర్ ఆ నోడ్ తెరిచిన తర్వాత ఏమి జరుగుతుందో మారుస్తుంది, మీకు అది అవసరమా అనేది కాదు.

మీరు ఏ మార్గాన్ని నిర్మించారో నిరూపించండి

ట్రే ఐకాన్‌కు బదులు సాకెట్‌లను చూడండి. VPN ప్రక్రియ ప్రాక్సీ చిరునామాకు స్థాపించిన కనెక్షన్‌ను ఉంచుకోవాలి, ప్రాక్సీ దాని నుండి చేరుకోవలసిన లక్ష్యాన్ని లాగ్ చేసి ఉండాలి:

ss -tnp | grep openvpn

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

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