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

లక్షణం: గమ్యం LAN చిరునామాను చూస్తుంది

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

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

మూడు సూచనలు, మూడు వేర్వేరు చిరునామాలు

Listen ప్రాక్సీ క్లయింట్లను అంగీకరించే స్థానిక చిరునామాను పేర్కొంటుంది. Bind బయటకు ప్రాక్సీ చేసే కనెక్షన్లకు మూల చిరునామాను ఇస్తుంది, BindSame ఇప్పుడే అంగీకరించిన కనెక్షన్ స్థానిక చిరునామాను మళ్లీ ఉపయోగించమని చెబుతుంది. ఇవి మూడు వేర్వేరు ప్రశ్నలు, ఒక పంక్తి వాటిలో ఒకదానికే సమాధానమిస్తుంది. వాటిని కలపడమే మార్పు ఏమీ చేయనట్టు కనిపించడానికి సాధారణ కారణం.

What you observeCheck first
A client cannot connect at allListen: the local address the listener binds
The request works but the far side logs the LAN addressBind: the outgoing source is not being applied
A configured Bind appears to have no effectBindSame yes: the accepted local address overrides the Bind list
The lookup names the LAN interfaceThe route, not the proxy: the source cannot reach that destination

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

శ్రోతను, బయటకు వెళ్లే మూలాన్ని విడివిడిగా సెట్ చేయండి

LAN చిరునామా 192.168.50.10, టన్నెల్ చిరునామా 10.90.0.3 ఉన్న హోస్ట్ను తీసుకోండి. LAN క్లయింట్లు ప్రాక్సీని చేరుకోవాలి, వాటి అభ్యర్థనలు టన్నెల్ ద్వారా బయటకు వెళ్లాలి అంటే, ఇవి రెండు స్వతంత్ర నిర్ణయాలు, రెండూ రాయాలి. కింది భాగం సరిగ్గా అదే చెబుతుంది, అంతకంటే ఏమీ కాదు.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

ఇది పూర్తి కాన్ఫిగరేషన్ కాదు, కాబట్టి ఆమోదించిన పోర్టు, ప్రామాణీకరణ, క్లయింట్ యాక్సెస్ నియంత్రణలు, గమ్య పరిమితులను ఉంచండి. రెండు చిరునామాలు Tinyproxy నెట్వర్క్ నేమ్స్పేస్ లోపల ఈ హోస్ట్కు చెందాలి, ఎందుకంటే ప్రక్రియ కలిగి ఉండలేని Bind విలువ ప్రారంభంలో కాదు, కనెక్ట్ అయ్యే సమయంలో విఫలమవుతుంది. BindSame yes మరో విధానాన్ని వివరిస్తుంది, అక్కడ అంగీకరించిన కనెక్షన్ స్థానిక చిరునామానే బయటకు వెళ్లే మూలం అవుతుంది. ప్రస్తుత రిలీజ్లలో ఆ శాఖకు Bind జాబితా కంటే ప్రాధాన్యం ఉంది, అలాగే కాన్ఫిగర్ చేసిన మూలం ఎలాంటి లోపం లేకుండా అదృశ్యమవుతుంది.

మూలం సూచించే మార్గాన్ని తనిఖీ చేయండి

మూల చిరునామాన్ని ఎంచుకోవడం మార్గాన్ని సృష్టించదు, కాబట్టి ఆ మూలం, ఆ గమ్యంతో కెర్నల్ ఏమి చేస్తుందో అడగండి. టన్నెల్ ఇంటర్ఫేస్ను పేర్కొనే శోధన కనిష్ఠ సాక్ష్యం, LAN ఇంటర్ఫేస్ను పేర్కొనేది మూలం రాసినట్టు పనిచేయలేదని అర్థం. శోధన సందర్భాధారితం: ఆ నేమ్స్పేస్కు వర్తించే విధాన నియమాలు, పట్టికను మూల్యాంకనం చేస్తుంది. ఇది కనెక్షన్ కాదు, దిగువ NAT సేవకు ఏమి చూపిస్తుందని కూడా ఏమీ చెప్పదు.

ip -4 route get 203.0.113.25 from 10.90.0.3

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

గమ్యంలో మూలాన్ని నిర్ధారించండి

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

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl కేవలం ట్రాఫిక్ జనరేటర్; ధృవీకరించదగిన చిరునామా దూరపు వైపు నమోదు చేసినది, curl యాదృచ్ఛికంగా కనెక్ట్ అయిన తోటి కాదు. రెండూ కలవకపోతే, భేదం మూల-ఎంపిక నుంచి వస్తుందా లేక మరింత ముందున్న మార్పిడి నుంచి వస్తుందా నిర్ణయించండి, ఎందుకంటే అవి వేర్వేరు చోట్ల సరిచేయబడతాయి. చిరునామా మార్పులు, ప్రాక్సీ పునఃప్రారంభాలను కలిసి ప్లాన్ చేయండి, ఎందుకంటే టన్నెల్ ఇక లేని చిరునామాను బైండ్ చేయడం తిరిగి కనెక్ట్ అయిన తర్వాత నిశ్శబ్దంగా విఫలమవుతుంది. DNS, IPv6 ప్రవర్తనను కూడా విడిగా నిర్వచించండి, ఎందుకంటే పైనున్న IPv4 భాగం రెండింటిలో దేని గురించీ ఏమీ నిరూపించదు.

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