Port-Share అన్ని వెబ్సైట్ సందర్శకులను localhost లాగా చూపించడం ఎందుకు

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

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

లాగ్ పంక్తిని కాదు, రెండు కనెక్షన్లను అనుసరించండి

Port-Share ఒకే TCP శ్రోతలో రెండు ప్రోటోకాల్లను మల్టీప్లెక్స్ చేస్తుంది. OpenVPN వచ్చే కనెక్షన్ మొదటి బైట్లను తనిఖీ చేస్తుంది, అది తన ప్రోటోకాల్ లాగా కనిపిస్తే దానిని ఉంచుకుంటుంది, మిగిలినవన్నీ రెండవ గమ్యానికి అప్పగిస్తుంది. ఆ గమ్యం సాధారణంగా అదే హోస్ట్లోని వెబ్ సర్వర్, కాబట్టి వెబ్ సర్వర్ అంగీకరించిన సాకెట్ భాగస్వామి OpenVPN ప్రక్రియ.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

మొదటి ఆదేశం పబ్లిక్ శ్రోత ఎవరిదో చూపిస్తుంది. రెండవది బ్యాకెండ్ పోర్టుకు వచ్చే కనెక్షన్లను చూపిస్తుంది, వాటి భాగస్వామి చిరునామానే యాక్సెస్ లాగ్ ముద్రిస్తుంది. ఆ భాగస్వామి loopback అయితే లాగ్ ఖచ్చితమైనది, సమాచారం ఒక పొర ముందే పోయింది. లాగ్ ఫీల్డ్ పేరు మార్చడం లేదా క్లయింట్-IP మాడ్యూల్ ప్రారంభించడం కనెక్షన్ ఎప్పుడూ మోయని చిరునామాను తిరిగి తీసుకురావు.

మిగిలినవన్నీ నిర్ణయించే తనిఖీ ఇదే. బ్యాకెండ్ భాగస్వామి బ్రౌజర్ చిరునామా అయితే, పోర్ట్ భాగస్వామ్యం మీ సమస్య కాదు, లాగ్ ఫార్మాటే.

రవాణా ఫార్వార్డింగ్ అనేది హెడర్ ఇంజెక్షన్ కాదు

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

మూల చిరునామాను రెండు విధానాలు మోయగలవు, రెండింటికీ రెండు చివరల్లో అంగీకారం అవసరం. PROXY ప్రోటోకాల్ కనెక్షన్ ప్రారంభంలో చిన్న హెడర్ను జోడిస్తుంది, బ్యాకెండ్ దానిని ఆశించేలా కాన్ఫిగర్ చేయాలి; ఆశించని బ్యాకెండ్ ఆ బైట్లను అభ్యర్థన ప్రారంభంగా భావించి గందరగోళంగా విఫలమవుతుంది. X-Forwarded-For వంటి నమ్మదగిన ప్రాక్సీ హెడర్లు HTTP అర్థం చేసుకునే ప్రాక్సీ వాటిని సెట్ చేసినప్పుడు, ఏ భాగస్వాములు వాటిని ధృవీకరించగలరో బ్యాకెండ్కు చెప్పినప్పుడు పని చేస్తాయి.

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

ఐచ్ఛిక మూల-మ్యాపింగ్ డైరెక్టరీ

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

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

ఈ మార్గాన్ని ఎంచుకుంటే, రెండు సగాల ఇంటిగ్రేషన్గా పరిగణించండి: ఫార్వార్డర్ రాసే మ్యాపింగ్ మరియు బ్యాకెండ్ చేసే శోధన. రెండింటినీ ధృవీకరించి, డైరెక్టరీ పునఃప్రారంభాన్ని తట్టుకుంటుందని, బిజీ శ్రోతలో అపరిమితంగా పెరగదని నిర్ధారించండి.

చిరునామాకు ఏ భాగం హామీ ఇస్తుందో నిర్ణయించండి

కాన్ఫిగరేషన్ మార్చే ముందు, క్లయింట్ చిరునామాను ధృవీకరించడానికి అనుమతి ఉన్న భాగాన్ని, దానిని నమ్మడానికి అనుమతి ఉన్న భాగాలను పేర్కొనండి. రాసిన ఒకే సమాధానం, మూడు వేర్వేరు పొరలు ఒక్కొక్కటి వేరే మూలాన్ని నమ్మే సాధారణ పొరపాటును నివారిస్తుంది.

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

పని చేయనిది ఏమిటంటే ఫార్వర్డ్ చేసిన loopback చిరునామాను అభ్యర్థన ఈ యంత్రంలో పుట్టిందని రుజువుగా భావించడం. ఆ అనుమానం సరిగ్గా వ్యతిరేకం: చిరునామా ఉన్నట్లే స్థానిక భాగం కనెక్షన్ సృష్టించింది. అలా రాసిన నియమం శ్రోతను చేరుకోగల ఎవరినైనా అంగీకరిస్తుంది.

పేజీని కాదు, నియమాన్ని పరీక్షించండి

లోడ్ అయ్యే పేజీ ఫార్వార్డింగ్ మార్గం పని చేస్తుందని రుజువు చేస్తుంది, ఆపాదన గురించి ఏమీ చెప్పదు. చిరునామా వినియోగదారుని పరీక్షించండి: యాక్సెస్ నియమం, రేటు పరిమితి, ఆడిట్ నమోదు, భౌగోళిక శోధన.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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