IPv6 మాత్రమే కనెక్షన్, IPv4 సేవ: SOCKS ప్రాక్సీ వంతెనగా మారనివ్వండి

గమ్యస్థానపు చిరునామా కుటుంబానికి చెందిన చిరునామా లేకపోయినా అక్కడికి చేరవచ్చు, మార్గంలో ఏదైనా రిలే చేయడానికి సిద్ధంగా ఉంటే. అప్లికేషన్ ప్రాక్సీకి కనెక్ట్ అవుతుంది, ప్రాక్సీ గమ్యస్థానానికి రెండవ కనెక్షన్ను తెరుస్తుంది. ఇవి స్వతంత్ర చిరునామా కుటుంబాలున్న రెండు సాకెట్లు, ఏ ప్రోటోకాల్ కూడా అవి సరిపోలాలని కోరదు. ఇది అప్లికేషన్ స్థాయి రిలే, స్థానిక IPv4 మార్గం కాదు, ఈ భేదమే ఏది పనిచేస్తుంది ఏది పనిచేయదు అని నిర్ణయిస్తుంది. రెండింటినీ కలపడమే ల్యాప్టాప్కు IPv4 కనెక్టివిటీ ఉందని వర్ణించే పద్ధతి, అందులో ఉన్నది కేవలం ప్రాక్సీ అయినప్పటికీ.

రెండు సాకెట్లు, రెండు చిరునామా కుటుంబాలు

SOCKS5 అభ్యర్థన గమ్యస్థానాన్ని మూడు రూపాల్లో ఒకదానిలో పేర్కొంటుంది: అక్షరార్థ v4 చిరునామా, అక్షరార్థ v6 చిరునామా, లేదా ప్రాక్సీ పరిష్కరించాల్సిన పేరు. అభ్యర్థన ప్రాక్సీ ఎక్కడ కనెక్ట్ కావాలో వివరిస్తుంది, క్లయింట్ నుండి ప్రాక్సీకి కనెక్షన్ ఎలా ఉంటుందో కాదు.

ఈ చిరునామా రకాలను ఒకే సందేశంలోని మూడు స్వతంత్ర ఎంపికలుగా చదవండి. IPv6 ద్వారా చేరుకోగల ప్రాక్సీ పనిచేసే IPv4 నిష్క్రమణ ఉన్నప్పుడు, దాని విధానం అభ్యర్థనను అనుమతించినప్పుడు IPv4 గమ్యస్థాన సాకెట్ను తెరవగలదు. SOCKS5 వివరణ క్లయింట్ రవాణా గురించి ఎటువంటి ప్రస్తావన లేకుండా వాటిని నిర్వచిస్తుంది.

నియంత్రిత SSH ఉదాహరణ

ఉపయోగించడానికి అనుమతి ఉన్న SSH హోస్ట్ను తీసుకోండి, అది IPv6లో సమాధానం ఇస్తుంది, తానే v4లో మాత్రమే ఉన్న HTTPS సేవను చేరగలదు. OpenSSH యొక్క చలనాత్మక ఫార్వార్డింగ్ లాగిన్ సెషన్ v6 ద్వారా నడుస్తున్నప్పుడు మీ మెషీన్లో స్థానిక SOCKS శ్రోతను ఉంచుతుంది.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

పైన ఇచ్చిన హోస్ట్ మరియు ఖాతా ఉదాహరణలు, లూప్బ్యాక్ బైండింగ్ శ్రోతను ఈ కంప్యూటర్లోనే ఉంచుతుంది. కార్యాలయం ధృవీకరణ లేని ప్రాక్సీని పంచుకోగలగడానికి దాన్ని వైల్డ్కార్డ్ బైండింగ్తో మార్చవద్దు. ExitOnForwardFailure=yes విఫలమైన ఫార్వార్డింగ్ సెషన్ను ముగించడానికే ఉంది, నేపథ్యంలో నిశ్శబ్ద ఆదేశం నడుస్తూ ఉండటానికి కాదు.

సెషన్ నడుస్తున్నప్పుడు అభ్యర్థన ఇలా ఉంటుంది:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

లూప్బ్యాక్ కనెక్షన్ IPv4 ఇంటర్నెట్ మార్గం కాదు. మీ మెషీన్ నుండి బయటకు వెళ్లేది v6 ద్వారా లాగిన్ సెషన్, గమ్యస్థాన సాకెట్ను దూరపు వైపు తెరుస్తుంది. socks5h రూపం పేరు పరిష్కారాన్ని కూడా ఆ వైపుకే అప్పగిస్తుంది, క్లయింట్కు సొంత IPv4 పరిష్కారక మార్గం లేనప్పుడు ఇది ముఖ్యం.

గమ్యస్థానం నిజంగా చూసేది

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

సంభాషణలోని రెండు సగాలూ కనిపించే ప్రదేశం కూడా రిలేయే, ఇది నిర్ధారణలో ఉపయోగకరమైన లక్షణం, విధానం లేకుండా రిలే పంచబడితే భారం.

ఇది DNS64 లేదా NAT64 కాదు

DNS64 v4 గమ్యస్థానాలకు ప్రత్యామ్నాయంగా సంశ్లేషిత రికార్డులతో సమాధానం ఇస్తుంది, NAT64 కాన్ఫిగర్ చేసిన మార్గంలో ప్యాకెట్లను తిరిగి రాస్తుంది. రెండూ ఇక్కడ జరిగేదాన్ని వివరించవు, ఒక రవాణా సంభాషణ ముగిసి మరొకటి ప్రారంభమయ్యే చోట ఏ సంశ్లేషిత చిరునామా ఫలితాన్ని వివరించదు. కాబట్టి విజయవంతమైన అభ్యర్థన మీ ప్రొవైడర్ ఏ అనువాద సేవలు నడుపుతుందో ఏమీ చెప్పదు, ప్రాక్సీ తన సొంత నిష్క్రమణపై సాధారణ NAT ను నడపవచ్చు.

రెండు యంత్రాంగాలు ఒకే నెట్వర్క్లో ఉండవచ్చు, కాబట్టి దగ్గరగా వినిపించేది కాదు, మీరు నిజంగా ధృవీకరించినది వివరించండి.

మాట ఇచ్చే ముందు పరిధిని తెలుసుకోండి

OpenSSH యొక్క చలనాత్మక ఫార్వార్డింగ్ TCP కనెక్షన్లను మోసుకెళ్తుంది, ఏకపక్ష IP ట్రాఫిక్ను కాదు, కాబట్టి UDP, ICMP మరియు ప్రాక్సీని విస్మరించే ఏ ప్రోటోకాల్కైనా వేరే మద్దతు ఉన్న రూపకల్పన అవసరం. SSH హోస్ట్ కీ ధృవీకరణ, సర్వర్ ఫార్వార్డింగ్ పరిమితులు మరియు HTTPS సర్టిఫికెట్ ధృవీకరణను నిలబెట్టుకోండి, ఎందుకంటే ప్రాక్సీ అదనపు విశ్వసనీయ భాగస్వామి, గుర్తింపు తనిఖీలను బలహీనపరచడానికి కారణం కాదు. లక్ష్యం VPN యొక్క బాహ్య రవాణాను ప్రాక్సీ ద్వారా తీసుకెళ్లడమైతే, ఏ SOCKS శ్రోత అయినా దాన్ని రిలే చేయగలదని ఊహించడం బదులు రెండు చివరలు ఆ రవాణాను మద్దతు ఇస్తాయని ధృవీకరించండి.

వీటిలో ఏదీ క్లయింట్ను ద్వంద్వ-స్టాక్ చేయదు, అలాంటి అవసరం కూడా లేదు. ఒక అప్లికేషన్ ఒక రిలే ద్వారా ఒక సేవను చేరేలా చేస్తుంది, ఇది చిన్న వాదన మరియు ధృవీకరించడం చాలా సులభం.