VPN మళ్లీ కనెక్ట్ అయిన తర్వాత కూడా ప్రాక్సీ పాత టన్నెల్ చిరునామాలోనే ఉందా?

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

రెండో వైఫల్యం ప్రమాదకరమైనది: టన్నెల్ పనిచేస్తోంది, పేజీలు లోడ్ అవుతున్నాయి, బయటకు వెళ్లే చిరునామా మాత్రమే తప్పు.

టన్నెల్ నుంచి కాదు, లిసనర్ నుంచి ప్రారంభించండి

ఆటలో మూడు చిరునామాలు ఉన్నాయి, మళ్లీ కనెక్ట్ అవ్వడం వాటిలో కొన్నింటిని మాత్రమే కదిలిస్తుంది. లిసనర్ అంటే మీ బ్రౌజర్ సూచించే స్థలం, సాధారణంగా 127.0.0.1 లేదా LAN చిరునామా, టన్నెల్ మారిందని దానికి పట్టదు. బయటకు వెళ్లే స్థానిక మూలం అంటే తదుపరి అడుగు డయల్ చేసేటప్పుడు కెర్నల్ను ఉపయోగించమని ఫార్వర్డర్ అడిగేది, అది టన్నెల్ పరికరానికి కట్టబడి ఉంటుంది. ప్రజా నిర్గమం అంటే వెబ్ సర్వర్ నమోదు చేసేది, అది కొన్ని అడుగుల దూరంలో అనువదించిన చిరునామా కావచ్చు.

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

కంటైనర్ మరియు నేమ్స్పేస్ అమరికలు ఈ ఊహను నిశ్శబ్దంగా బద్దలు కొడతాయి. ఒక నెట్వర్క్ నేమ్స్పేస్లోని ఫార్వర్డర్ మరొకదానిలో ఉన్న టన్నెల్కు కట్టుబడలేదు, ఎంత కాన్ఫిగరేషన్ సవరించినా అది సరికాదు.

ఏదైనా సవరించే ముందు నాలుగు తనిఖీలు

వీటిని క్రమంగా చేయండి. మొదటి విఫలమయ్యే తనిఖీయే ఆగే స్థలం, ఎందుకంటే తర్వాతివి మునుపటివి నిజమని ఊహిస్తాయి.

1. ఉపయోగిస్తున్న టన్నెల్ ప్రాక్సీ నిర్మించిన ప్రొఫైలేనని, తనంతట తాను కనెక్ట్ అయిన రెండో ప్రొఫైల్ కాదని నిర్ధారించుకోండి.
2. ఆ పరికరంలో ఇప్పుడు ఉన్న చిరునామాను ముద్రించి, నడుస్తున్న కాన్ఫిగరేషన్లోని చిరునామాతో పోల్చండి.
3. డిస్క్లోని ఫైల్ చెప్పేది కాదు, ఫార్వర్డర్ ఏ మూలాన్ని కనుగొందో అడగండి.
4. ఫార్వర్డర్ నుంచి వచ్చే ట్రాఫిక్ మీరు ఆశించే రూటింగ్ మరియు ఫైర్వాల్ విధానానికి నిజంగా లోబడి ఉందని నిర్ధారించుకోండి.

పరికర చిరునామా సులభం: ip -4 addr show dev tun0 ప్రస్తుతదాన్ని ముద్రిస్తుంది, ip -4 route get 1.1.1.1 ఆ గమ్యానికి కెర్నల్ ఏ ఇంటర్ఫేస్ ఎంచుకుంటుందో చూపిస్తుంది. ఖచ్చితమైన చిరునామాకు కట్టుబడే ఫార్వర్డర్ చిరునామా మాయమైనప్పుడు గట్టిగా విఫలమవుతుంది. పరికరానికి కట్టుబడే, లేదా డిఫాల్ట్ మూలానికి తిరిగే ఫార్వర్డర్ పని కొనసాగిస్తూ కారుతుంది, అదే నిశ్శబ్ద ఫలితం.

డాక్యుమెంటేషన్ను మీరు నడిపే విడుదలకు సరిపోల్చండి, శోధనలో మొదటి ఫలితానికి కాదు. Squid బయటకు వెళ్లే చిరునామా సూచన v7 మరియు అంతకు మునుపటివాటికి డాక్యుమెంట్ చేయబడింది, v8 డాక్యుమెంటేషన్ ఆ సూచన అక్కడ అందుబాటులో లేదని స్పష్టంగా చెబుతుంది, కాబట్టి దాని చుట్టూ నిర్మించిన స్క్రిప్ట్ ఆ హద్దును దాటదు (Squid tcp_outgoing_address సూచన చూడండి). ఏదైనా మళ్లీ లోడ్ చేసే ముందు ఉత్పత్తి స్వంత పార్సర్తో ధృవీకరించండి: squid -k parse లోపాలను నివేదించి నడుస్తున్న ప్రక్రియను తాకకుండా బయటకు వెళ్తుంది.

ప్రతి టన్నెల్కు నంబర్ ఇవ్వండి, పాత మార్పిడులను పారేయండి

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

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

తెరిచిన సాకెట్లు కొత్త చిరునామాను అనుసరించవు

ఫార్వర్డర్ను మళ్లీ కాన్ఫిగర్ చేయడం ఇప్పటికే ఏర్పాటైన కనెక్షన్ల గురించి ఏమీ చెప్పదు. అవి ఖాళీ అవుతాయా లేదా చనిపోతాయా అనేది ఉత్పత్తిపై ఆధారపడి ఉంటుంది, కాబట్టి ఊహించడం బదులు ప్రవర్తనను గమనించండి.

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

కొత్త నిర్గమాన్ని కొత్త అభ్యర్థనతో నిరూపించండి

ముఖ్యమైనది సక్రియం చేసిన తర్వాత తెరిచిన అభ్యర్థన, ping కాదు, ఇప్పటికే కాష్ అయిన పేజీ కాదు. ప్రాక్సీని నిజమైన URL అడిగి, దూరపు చివర నివేదించే నిర్గమ చిరునామా చదవండి, తర్వాత ప్రదాత ఒకటి చూపినప్పుడు క్లయింట్ టన్నెల్ గురించి తన దృష్టితో పోల్చండి.

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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