Squid పేరెంట్‌కు వేరు లాగిన్ వివరాలు పెట్టండి

మీ Squid సేవకు వినియోగదారు లాగిన్, పేరెంట్‌కు Squid లాగిన్ వేర్వేరు వివరాలు వాడతాయి. పేరెంట్ మరో నిర్వాహకుడిది కావచ్చు లేదా వేరే ఖాతా డేటాబేస్ వాడవచ్చు. క్లయింట్ పాస్‌వర్డ్ అంగీకరించడం అంటే దాన్ని అప్‌స్ట్రీమ్‌కు పంపాలి అని అనుకోకండి.

Squid 6.13 పేరెంట్ నిర్వచనానికి స్థిర లాగిన్ జోడించగలదు:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

పైన చిరునామా, పాస్‌వర్డ్ డాక్యుమెంటేషన్ ఉదాహరణలు. పొరపాటున రెండో peer సృష్టించకుండా ప్రస్తుత పేరెంట్ నిర్వచనానికి లాగిన్ జోడించండి. ఏ అభ్యర్థనలు ఈ పేరెంట్‌ను తప్పనిసరిగా వాడాలో నిర్ణయించే వేరు రూటింగ్ విధానాన్ని ఉంచండి.

ఖాతాల పరిధులను వేరుగా ఉంచండి

డౌన్‌స్ట్రీమ్ auth_param సెట్టింగ్‌లు మీ Squid ఇన్‌స్టన్స్ క్లయింట్‌లను ధృవీకరిస్తాయి. Peer login ఆప్షన్ మరో హాప్‌కు వివరాలు ఇస్తుంది. ఒకదాన్ని మార్చితే మరొకటి స్వయంచాలకంగా అప్‌డేట్ కాదు.

పేరెంట్ డాక్యుమెంట్ చేసిన ప్రామాణీకరణ అవసరాలు పాటించండి. ఈ లైన్ ప్రతి కనెక్షన్ ఆధారిత ప్రామాణీకరణ పద్ధతికీ పూర్తి కాన్ఫిగరేషన్ కాదు. పేరెంట్ NTLM లేదా Negotiate ఆశిస్తే ఈ ఫీల్డ్ పాస్‌వర్డ్ పదేపదే మార్చకుండా మద్దతున్న peer అమరికను తనిఖీ చేయండి.

Squidలో PASS, PASSTHRU వంటి వివరాలను పంపించే ఆప్షన్‌లూ ఉన్నాయి. వాటి అర్థం ప్రత్యేక అప్‌స్ట్రీమ్ ఖాతాకు భిన్నం; క్లయింట్ ప్రామాణీకరణ సమాచారాన్ని peerకు బయటపెట్టవచ్చు. రూపకల్పన వేరు ఖాతాలు వాడితే వాటిని సులువైన మార్గంగా ఎంచుకోవద్దు.

కాన్ఫిగరేషన్‌ను కాపాడి సరైన హాప్‌ను పరీక్షించండి

స్థిర రహస్యం కాన్ఫిగరేషన్‌లో నిల్వ ఉంటుంది. ఫైల్, బ్యాకప్ యాక్సెస్ పరిమితం చేసి parser లేదా debug అవుట్‌పుట్ పంచే ముందు సున్నిత సమాచారం తొలగించండి. ఆప్షన్‌కు సొంత escaping నియమాలున్నాయి: డాక్యుమెంటేషన్ URL escapesను అనుమతించి సాధారణ శాతం గుర్తును రెండుసార్లు రాయాలని కోరుతుంది.

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