హోస్ట్ URL తో అతిథి VM లో PAC ప్రాక్సీ ఎందుకు విఫలమవుతుంది

«హోస్ట్ ఈ PAC ఫైల్‌ను ఉపయోగిస్తుంది, కాబట్టి నేను అదే URL ను VM లో పెట్టాను» అనేది సమంజసమైన వాక్యం మరియు అసంపూర్ణ ప్రణాళిక. PAC URL ఒక విధాన స్క్రిప్ట్‌ను సూచిస్తుంది, ప్రాక్సీని కాదు. అతిథి ఆ స్క్రిప్ట్‌ను పొందలేనంత, అతిథి స్వంత చిరునామాలతో దాన్ని మూల్యాంకనం చేయలేనంత మరియు స్క్రిప్ట్ పేర్కొనే ఏ ప్రాక్సీనైనా చేరుకోలేనంత వరకు, URL అనేది సెట్టింగ్‌ల ఫీల్డ్‌లోని ఒక స్ట్రింగ్ మాత్రమే. వర్చువల్ మెషీన్లలో ప్రాక్సీ విధానం చుట్టూ ఉన్న చాలా గందరగోళం ఆ ఒక్క పంక్తిని మొత్తం కాన్ఫిగరేషన్‌గా భావించడం వల్ల వస్తుంది.

PAC URL ఒక స్క్రిప్ట్, ప్రాక్సీ కాదు

ఫైల్‌లో URL మరియు హోస్ట్‌ను తీసుకుని ప్రాక్సీ వివరణ లేదా DIRECT అనే పదాన్ని తిరిగి ఇచ్చే ఫంక్షన్ ఉంది. URL లో యాప్‌లికేషన్‌కు ట్రాఫిక్ ఎక్కడ పంపాలో చెప్పేది ఏమీ లేదు; ఆ నిర్ణయం రన్‌టైమ్‌లో, స్క్రిప్ట్ లోపల, స్క్రిప్ట్ ప్లాట్‌ఫారమ్ నుండి అడిగే డేటాతో తీసుకోబడుతుంది. PAC URL ను అంగీకరించే సెట్టింగ్‌ల డైలాగ్ నిర్ణయ ప్రక్రియకు ఒక సూచికను అంగీకరిస్తుంది.

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

నాలుగు దశలు ఒక్కొక్కటి వేరే విధంగా విఫలమవుతాయి

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

పొందడాన్ని నిరూపించడంతో ప్రారంభించండి, ఎందుకంటే అది లేకుండా మిగిలినవన్నీ అర్థరహితం. ప్రైవేట్ సర్వర్‌లోని PAC ఫైల్‌కు ఏ నియమం సహాయం చేసే ముందే ఆ సర్వర్‌కు అనుమతించిన మార్గం అవసరం, మరియు చేరుకోలేని స్క్రిప్ట్ లోపల ప్రాక్సీ ఎంపిక దాన్ని పొందే మార్గాన్ని సృష్టించలేదు:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

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

అదే స్క్రిప్ట్ VM లోపల భిన్నంగా నిర్ణయిస్తుంది

PAC ఫంక్షన్లు అభ్యర్థించిన హోస్ట్ మరియు మూల్యాంకనం చేసే మెషీన్ గురించిన సమాచారాన్ని పరిశీలించగలవు. క్లయింట్ స్వంత చిరునామాపై నిర్మించిన నియమం, ఉదాహరణకు ఇంటర్‌ఫేస్ చిరునామా లేదా సబ్‌నెట్ సభ్యత్వాన్ని తనిఖీ చేసేది, భౌతిక హోస్ట్ చిరునామాను కాదు, అతిథి చిరునామాను చూస్తుంది. హోస్ట్ వైపు NAT వెనుక ఇవి వేరే చిరునామాలు, కాబట్టి అదే స్క్రిప్ట్ మరో ప్రాక్సీని ఎంచుకోవచ్చు లేదా VM లోపల DIRECT కు తిరిగి వెళ్లవచ్చు.

ఇది స్క్రిప్ట్‌లోని లోపం కాదు. స్క్రిప్ట్ ఏ పని కోసం రాయబడిందో అదే పనిని వేరే ఇన్‌పుట్‌తో చేస్తోంది, అదే హోస్ట్ ప్రాక్సీని ఉపయోగించి అతిథి నేరుగా కనెక్ట్ అయ్యే గందరగోళ నివేదికను వివరిస్తుంది. నిర్ణయం గురించి ఆలోచించడం బదులు దాన్ని పునరుత్పత్తి చేయండి: చిరునామా మరియు URL తీసుకునే PAC మూల్యాంకనకర్త, మీ పంపిణీలో ఉంటే, ఒకే ఆదేశంతో ప్రశ్నను పరిష్కరిస్తుంది. లేకపోతే నిజంగా ఉపయోగించే యాప్‌లికేషన్‌తో పరీక్షించండి, మరియు ఊహించడం బదులు దాని ప్రాక్సీ లాగ్ చదవండి.

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

PAC ను అసలు చదవని సాధనాలు

కమాండ్-లైన్ సాధనాలు వేరే సరిహద్దు, ఇక్కడే చాలా సమయం వృథా అవుతుంది. curl PAC ఫైల్‌లను అమలు చేయదు, దాని ప్రాక్సీ డాక్యుమెంటేషన్ స్పష్టంగా చెప్పినట్టు. ప్రాక్సీ వేరియబుల్‌ను PAC డౌన్‌లోడ్ URL వైపు చూపించడం స్క్రిప్ట్‌ను ప్రాక్సీ ముగింపు బిందువుగా మార్చదు; సాధనం JavaScript ఫైల్‌తో HTTP మాట్లాడేందుకు ప్రయత్నిస్తుంది మరియు నెట్‌వర్క్ సమస్యలా కనిపించే విధంగా విఫలమవుతుంది.

స్పష్టమైన ప్రాక్సీ వేరియబుల్‌లు లేదా తమ స్వంత కాన్ఫిగరేషన్‌ను మాత్రమే గౌరవించే అనేక ప్యాకేజీ నిర్వాహకులు, భాషా రన్‌టైమ్‌లు మరియు బిల్డ్ సాధనాలకు ఇదే వర్తిస్తుంది. మీకు ముఖ్యమైన పరీక్ష CLI సాధనమైతే, PAC స్క్రిప్ట్ ఎంచుకునే నిర్దిష్ట ప్రాక్సీతో దాన్ని కాన్ఫిగర్ చేయండి, మరియు ఆ ఎంపికకు ఎలా వచ్చారో నమోదు చేయండి, తద్వారా తదుపరి వ్యక్తి దాన్ని పునరావృతం చేయగలరు.

Linux లో డెస్క్‌టాప్ యాప్‌లికేషన్‌లకు, సిస్టమ్ సెట్టింగ్ స్వయంచాలక మోడ్‌లో ఉంచాలి మరియు URL కూడా ఇవ్వాలి; మోడ్ ఇంకా మాన్యువల్‌గా ఉన్నప్పుడు సేవ్ చేసే URL ఏమీ చేయదు. రెండింటినీ తనిఖీ చేయండి, మరియు అతిథి లోపల తనిఖీ చేయండి:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT కూడా ఒక నిర్ణయం

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

కాబట్టి అవసరం రాయబడిన దిశలోనే ధృవీకరించండి. అవసరం «ఈ యాప్‌లికేషన్ అంతర్గత సైట్‌ను చేరుకుంటుంది» అయితే, ఆ యాప్‌లికేషన్ చేరుకుంటుందని నిరూపించండి, మరియు ఏ ప్రాక్సీ లేదా మార్గం దాన్ని మోసుకెళ్లిందో నమోదు చేయండి. అవసరం «VM కార్పొరేట్ నెట్‌వర్క్‌లో ఉంది» అయితే, ఎంచుకున్న ప్రాక్సీ ద్వారా పనిచేసే బ్రౌజర్ ఆ బ్రౌజర్‌కు సాక్ష్యం, అంతకు మించి ఏమీ కాదు.

పరీక్ష పాస్ కావడానికి హోస్ట్ సొరంగాన్ని ఆపేయడం లేదా ఫార్వర్డింగ్ విధానాన్ని సడలించడం బదులు అతిథి లోపల గొలుసును సరిచేయండి. గొలుసులో నాలుగు లింకులు ఉన్నాయి, వాటిలో ఒకదాన్ని దాటవేసే మార్పు తదుపరిసారి స్క్రిప్ట్ నవీకరించబడే వరకు లేదా అతిథి చిరునామా మారే వరకు కొనసాగుతుంది.