సాకెట్ పీర్ లేదా ఫార్వర్డ్ చేసిన హెడర్: ఏ చిరునామాను నమ్మాలి?

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

ఏదైనా పోల్చడానికి ముందు మార్గాన్ని వివరించండి:

Client -> approved reverse proxy -> application origin

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

చిరునామా గురించి రెండు రకాల రుజువులు

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

ఫార్వర్డింగ్ ఫీల్డ్ అనేది గొలుసు గురించిన మెటాడేటా. X-Forwarded-For, X-Real-IP మరియు ప్రామాణిక ఫీల్డ్ Forwarded వాటిని ప్రతిధ్వనించే ముగింపు బిందువును చేరుకునే ఏ క్లయింట్ అయినా రాయగలదు, కాబట్టి వాటి విశ్వసనీయత వాటిని సెట్ చేయడానికి ఎవరికి అనుమతి ఉందో దానిపై పూర్తిగా ఆధారపడి ఉంటుంది.

రెండింటినీ అభ్యర్థన సందర్భంలో వేర్వేరు పేర్లతో ఉంచండి. పీర్ను హెడర్తో ఓవర్రైట్ చేసే అప్లికేషన్ తర్వాత విశ్వాస లోపాన్ని పునర్నిర్మించే సామర్థ్యాన్ని కోల్పోతుంది, మరియు అది మీకు అది అవసరమయ్యే సరైన క్షణం.

హెడర్ ఎప్పుడూ కనెక్షన్ను మళ్లీ మార్గనిర్దేశం చేయదు

ఫార్వర్డింగ్ ఫీల్డ్లో చిరునామా రాయడం సర్వర్కు వచ్చే TCP కనెక్షన్ మూలాన్ని మార్చదు, మరియు మార్గంలో ఎక్కడా రూటింగ్ను మార్చదు. సాధారణ VPN రూటింగ్ లేదా మూల NAT ఎలాంటి HTTP హెడర్ లేకుండా ట్రాఫిక్ను చేరవేస్తుంది. అలాగే, ట్రాన్సిట్ గేట్వే TLS ముగింపు బిందువు అమరికను మార్చకుండా సరిగా రక్షించబడిన HTTPS మార్పిడిని తిరిగి రాయదు.

వ్యతిరేక తప్పు కూడా అంతే సాధారణం: HTTPS క్లయింట్ అందించిన ఫార్వర్డింగ్ హెడర్ను నిజం చేయదు. అది అబద్ధ వాదన రవాణాను నిజమైన దానితో సమానంగా రక్షిస్తుంది.

సహోద్యోగి రూటింగ్ సమస్యను పరిష్కరించడానికి హెడర్ మార్పును సూచిస్తే, నిర్ధారణ ఇప్పటికే తప్పు దారిలో పోయింది. మార్గాన్ని సరిచేయండి, లేదా హెడర్ను రాసే ప్రాక్సీ కాన్ఫిగరేషన్ను సరిచేయండి.

వాదించడానికి అనుమతి ఉన్న ప్రాక్సీని పేర్కొనండి

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

NGINX యొక్క నిజమైన IP మాడ్యూల్ విభజనను స్పష్టంగా చూపిస్తుంది. set_real_ip_from ఎవరి వాదన లెక్కించబడుతుందో ఆ పంపినవారిని పేర్కొంటుంది, మరియు real_ip_header ఏ ఫీల్డ్ దానిని మోస్తుందో చెబుతుంది; మొదటిది విశ్వాసాన్ని చేస్తుంది, రెండవది ఎక్కడ చూడాలో మాత్రమే చెబుతుంది.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

హెడర్ ఎంపిక సూచన మాత్రమే విలువను ఎవరు పంపారనే దాని గురించి ఇంకా ఏమీ స్థాపించదు.

రవాణా భద్రత మీరు నమ్మే భాగాల మధ్య మొత్తం మార్గాన్ని ప్రయాణించాలి. సరిగ్గా సాధారణీకరించే అంచు ఆ విలువను, క్రింది అసురక్షిత దశ ప్రయాణంలో వేరొకరు వాదనను సవరించడానికి అనుమతించిన క్షణంలో కోల్పోతుంది.

బహుళ-దశల గొలుసులను ఉద్దేశపూర్వకంగా నిర్వహించండి

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

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

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

రెండు పరిశీలనలను లాగ్లో ఉంచండి

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

ఈ జత అర్థం ఏమిటో గుర్తుంచుకోండి. హెడర్ మీరు నమ్మాలని ఎంచుకున్న భాగం అందించే సందర్భాన్ని జోడిస్తుంది; పీర్ మీ హోస్ట్ నిజంగా చూసిన ఏకైక చిరునామాగా మిగిలిపోతుంది. రెండూ వ్యక్తిగత గుర్తింపుకు రుజువు కావు, మరియు ఏదైనా ఒకదాన్ని రుజువుగా పరిగణించే రూపకల్పన ఎవరో ఒకరి గురించి తప్పు పడుతుంది.