HAProxy 302 ఒక ప్రైవేట్ అనువర్తనానికి: రెండవ దశను ఎవరు తెరుస్తారు?

ఎవరో ఒక పబ్లిక్ HAProxy హోస్ట్ను లోకల్ అనువర్తనానికి మళ్లించి, బ్రౌజర్ ఎందుకు అనుసరించలేకపోతోందని అడుగుతారు। ప్రాక్సీ తన VPN ద్వారా అనువర్తనాన్ని చేరుకుంటుంది, రీడైరెక్ట్ ఒక Location హెడర్ను తిరిగి ఇస్తుంది, ఆ తర్వాత బ్రౌజర్ టన్నెల్ లోపల మాత్రమే ఉన్న చిరునామాను ప్రయత్నిస్తుంది। బయటి నుంచి పేజీ కేవలం వేలాడుతుంది। రెండవ కనెక్షన్ను ఏ పక్షం తెరుస్తుందనేదే నిర్ణయం, అదే రీడైరెక్ట్ను బ్యాకెండ్ నుంచి వేరు చేస్తుంది।

కాన్ఫిగరేషన్లో ఒకేలా కనిపించే రెండు మార్గాలు

ఒక రీడైరెక్ట్ మార్పిడిని ఒక ప్రతిస్పందనతో ముగిస్తుంది। క్లయింట్ Locationను చదివి, తాను ఉన్న చోటి నుంచే కొత్త అభ్యర్థనను ప్రారంభిస్తుంది, అంటే మీరు ఎప్పుడూ నియంత్రించని నెట్వర్క్ నుంచి। ప్రాక్సీ ఇక పాల్గొనదు। తర్వాత జరిగేదంతా క్లయింట్ స్వంత DNS, మార్గం మరియు విశ్వాసంపై ఆధారపడి ఉంటుంది, కాబట్టి వినియోగదారు బ్రౌజర్ను ఎక్కడ తెరిచారనే దానిపై ఫలితం మారుతుంది:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

ప్రాక్సీ బ్యాకెండ్ రెండవ పాదాన్ని సర్వర్ వైపే ఉంచుతుంది। ప్రాక్సీ దాన్ని ఇప్పటికే ఉన్న మార్గం ద్వారా తెరుస్తుంది, క్లయింట్ మాత్రం ఒకే పబ్లిక్ పేరుతో మాట్లాడుతూనే ఉంటుంది। టన్నెల్ పడిపోతే, క్లయింట్ అనుసరించలేని URLకు బదులుగా లోపాన్ని పొందుతుంది। ఈ భేదమే వైఫల్యాన్ని నిర్ధారణ చేయగలిగేలా చేస్తుంది, ఎందుకంటే లోపం లాగ్లు ఉన్న చోటే కనిపిస్తుంది:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy యొక్క రీడైరెక్ట్ డాక్యుమెంటేషన్ సరిగ్గా ఈ గీతను గీస్తుంది: క్లయింట్కు రీడైరెక్ట్తో సమాధానం ఇవ్వడం, అభ్యర్థనను బ్యాకెండ్కు పంపడం నుంచి భిన్నమైన చర్య। రెండు డైరెక్టివ్లు ఒక కాన్ఫిగరేషన్ ఫైల్లో కొన్ని పంక్తుల దూరంలో ఉంటాయి, ప్రవర్తనలో పూర్తిగా భిన్నం। ఒకటి అభ్యర్థనను ముగిస్తుంది, మరొకటి ప్రాక్సీ సొంతమైన రెండవ అభ్యర్థనను ప్రారంభిస్తుంది।

బ్రౌజర్కు ఏమి కావాలి, సర్వర్ VPN ఏమి ఇవ్వదు

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

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

అనువర్తనాన్ని ప్రాక్సీ మాత్రమే చేరుకోగలిగినప్పుడు

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

ఆ బ్లాక్ను ప్రాక్సీ రూటింగ్ పట్టిక గురించిన ప్రకటనగా చదవండి: 10.40.0.20 ప్రాక్సీ హోస్ట్ నుంచే చేరుకోగలిగి ఉండాలి, ఇక్కడ అంటే డిఫాల్ట్ మార్గం ద్వారా కాదు, VPN ఇంటర్ఫేస్ ద్వారా। check అనే కీలక పదం ఆ మార్గం ఏమి చేస్తుందో మాత్రమే తెలియజేస్తుంది, ఆరోగ్య మార్గం అనువర్తనంలో ఉండాలి, లేకపోతే ప్రతి పరీక్ష సర్వర్ను పనిచేయని వలె గుర్తిస్తుంది। విజయవంతమైన పరీక్ష క్లయింట్ గురించి ఏమీ నిరూపించదు, బ్యాకెండ్ను ఎవరు ఉపయోగించవచ్చో నిర్ణయించే విధానాన్ని భర్తీ చేయదు।

ఈ భాగం పూర్తి ఫ్రంటెండ్ కాదు। వినేవాడిని, ప్రామాణీకరణను, అనుమతించిన హోస్ట్ మరియు మార్గ ఎంపికను, అనువర్తనాన్ని ఎవరు చేరుకోవచ్చో నిర్ణయించే నియమాన్ని ఉంచండి। బ్యాకెండ్ ప్రోటోకాల్ను కూడా సరిపోల్చండి, ఎందుకంటే HTTPS బ్యాకెండ్కు సర్టిఫికెట్ ధృవీకరణ మరియు సర్వర్ గుర్తింపు కాన్ఫిగరేషన్ కావాలి, ఆ తనిఖీని దాటవేయడం ప్రైవేట్ కనెక్షన్ను ధృవీకరించని కనెక్షన్గా మారుస్తుంది।

విజయం ప్రకటించే ముందు తిరోమార్గాన్ని రెండు దిశల్లోనూ నిర్ధారించండి। అనువర్తనం ఇప్పుడు ప్రాక్సీ నుంచి వచ్చిన కనెక్షన్ను చూస్తుంది, కాబట్టి దాని లాగ్లు మరియు క్లయింట్ చిరునామా గురించిన ఏ మెటాడేటా అయినా, మీరు వేరేలా ఏర్పాటు చేయకపోతే, ప్రాక్సీనే వివరిస్తాయి। గుర్తింపు మరియు పంపిన చిరునామాలు ఎలా నిర్వహించబడతాయో నిర్ణయించి, ఆ నిర్ణయాన్ని ఊహించకుండా పరీక్షించండి।

అనువర్తనం స్వంత రీడైరెక్ట్లు ఇంకా లోపలికే సూచిస్తున్నాయి

మొదటి అభ్యర్థనను పంపడం ఏకీకరణలో సగం మాత్రమే। అనువర్తనం సంపూర్ణ రీడైరెక్ట్లు, కఠినంగా కోడ్ చేసిన ఆస్తి URLలు లేదా లోపల తనకు తెలిసిన పేరుకు పరిమితమైన కుకీలను జారీ చేయవచ్చు, వాటిలో ప్రతి ఒక్కటి బ్రౌజర్ను అది చేరుకోలేని చిరునామాకు తిరిగి పంపుతుంది। లోపలి పేరును సూచించే Location హెడర్ అసలు సమస్యలాగానే కనిపిస్తుంది, అందుకే అది ప్రాక్సీ వైఫల్యంగా తప్పుగా నిర్ధారించబడుతుంది।

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

పంపిన మెటాడేటాను నియమించిన ప్రాక్సీ నుంచి మాత్రమే నమ్మండి। ఏ క్లయింట్ అయినా సెట్ చేయగల హెడర్ ఎప్పుడూ అధికార విలువగా మారకూడదు, లేకపోతే ప్రాక్సీ ఒక కాలర్ మరొకరి గుర్తింపును క్లెయిమ్ చేసుకునే మార్గంగా మారుతుంది। ఆ నియమం రీడైరెక్ట్ ప్రశ్న నుంచి స్వతంత్రం, తర్వాతి ఏ పునఃరూపకల్పనలోనైనా నిలిచి ఉంటుంది।

మీకు నిజంగా ఏ డిజైన్ ఉందో నిర్ణయించండి

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

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

రివర్స్ ప్రాక్సీని ప్రచురించడం వేరే యాక్సెస్ నిర్ణయం, ప్రాక్సీ స్వంత VPNను దాని పబ్లిక్ URLను లోడ్ చేయగల ఎవరికైనా పారదర్శకంగా పొడిగించడం కాదు। ఒక గ్రాఫిక్లో రెండూ ఒకేలా కనిపిస్తాయి, ఎవరికి లోపలికి అనుమతి అనే దానిలో భేదిస్తాయి। ఆ ప్రశ్నను డిప్లాయ్ చేసిన తర్వాత నిర్ణయించడమే అంతర్గత అనువర్తనం ప్రమాదవశాత్తు పబ్లిక్ ఒకటిగా మారే మార్గం।

మీరు ఏది నిర్మించారు, ఎందుకు అని రాసి పెట్టండి। కాన్ఫిగరేషన్ను తాకే తదుపరి వ్యక్తి మరొకటి అనుకుంటారు। సౌలభ్యం కోసం జోడించిన ఒకే రీడైరెక్ట్ అసలు వైఫల్యాన్ని తిరిగి సృష్టించడానికి చాలు, లక్షణం మీరు ఇప్పుడే సరిచేసిన దానిలాగానే కనిపిస్తుంది।