మీ URL కి 45000 కాదు, పోర్ట్ 80 లేదా 443 ప్రవేశం ఎందుకు అవసరం

బ్రౌజర్‌లో హోస్ట్‌నేమ్ టైప్ చేయండి, స్కీమ్ గమ్యస్థాన పోర్ట్‌ను నిర్ణయిస్తుంది: http కి 80, https కి 443. DNS సమాధానంలో ఏదీ దాన్ని రద్దు చేయదు, మరియు మీ మెషీన్‌పై ఏ ఫార్వార్డింగ్ నియమమూ ప్రొవైడర్ అంచున శ్రోతను సృష్టించలేదు. VPN ప్రొవైడర్ మీకు 45000 వంటి ఎత్తైన పబ్లిక్ పోర్ట్ ఇచ్చినప్పుడు, స్పష్టమైన URL పనిచేస్తుంది, శుభ్రమైనది పనిచేయదు. ఖాళీ ప్రవేశ బిందువు వద్ద ఉంది, అప్లికేషన్ లోపల కాదు.

బ్రౌజర్ నుండి ప్రాసెస్ వరకు మార్గాన్ని ఒకసారి చూడండి, మూడు ప్రచురణ ఎంపికలు రహస్యంగా కనిపించడం ఆగిపోతాయి.

అభ్యర్థన వాస్తవంగా ఎక్కడికి వెళ్తుందో చూడండి

బ్రౌజర్ పేరును చిరునామాగా పరిష్కరించి, ఆ తర్వాత URL వేరే పోర్ట్ చెప్పకపోతే స్కీమ్ డిఫాల్ట్ పోర్ట్‌లో ఆ చిరునామాకు కనెక్ట్ అవుతుంది. వచ్చే కనెక్షన్‌కు ఏమవుతుందో మీ ప్రొవైడర్ అంచు నిర్ణయిస్తుంది. దాని ఫార్వార్డింగ్ పట్టిక 45000ని మాత్రమే మీ అంతర్గత చిరునామాకు మ్యాప్ చేస్తే, 80కి కనెక్షన్‌కు వెళ్లడానికి చోటు లేదు, మీ మెషీన్ పాల్గొనకముందే అది తిరస్కరించబడుతుంది లేదా పడవేయబడుతుంది.

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

స్థానిక నియమం అంచును ఎందుకు సరిచేయలేదు

అప్లికేషన్ హోస్ట్‌పై రీడైరెక్ట్ లేదా DNAT నియమం ఇప్పటికే వచ్చిన ప్యాకెట్‌లపై పనిచేస్తుంది. ప్రొవైడర్ వద్ద పోర్ట్ 80కి పంపిన ప్యాకెట్‌లు ఎప్పటికీ రావు, కాబట్టి నియమం ఎప్పటికీ మూల్యాంకనం చేయబడదు. మొత్తం సమస్యలో ఇదే అత్యంత సాధారణంగా వృథా అయ్యే గంట.

DNS కూడా పోర్ట్‌ను మోయలేదు. HTTP వివరణ స్కీమ్ డిఫాల్ట్‌లను నిర్వచిస్తుంది, A లేదా AAAA రికార్డ్ చిరునామాను తిరిగి ఇస్తుంది, CNAME వేరే పేరును తిరిగి ఇస్తుంది. బ్రౌజర్ ఇప్పటికీ స్కీమ్ పోర్ట్‌ను కలుపుతుంది, కాబట్టి URLలో స్పష్టమైన పోర్ట్ మాత్రమే గమ్యాన్ని మారుస్తుంది.

ఎంపిక ఒకటి: స్పష్టమైన పోర్ట్‌ను ఉంచుకోండి

తరచుగా సరైన సమాధానం మెరుపు లేనిదే. పోర్ట్‌తో పూర్తి URL ప్రచురించండి, దాన్ని మద్దతిచ్చే ప్రవేశంలో TLS ముగించండి, ఉత్పత్తి అయిన ప్రతి లింక్ అదే మూలాన్ని ఉంచుతుందని నిర్ధారించుకోండి. చిన్న, నియంత్రిత ప్రేక్షకులకు ఇది పూర్తి, కనిపించే పోర్ట్ నంబర్ తప్ప వేరే ఖర్చు లేదు.

అక్కడ ఉన్నప్పుడు రీడైరెక్ట్‌లు మరియు కుకీ పరిధిని తనిఖీ చేయండి, ఎందుకంటే తన స్వంత హోస్ట్‌నేమ్‌ను Location హెడర్‌లో రాసే backend ఈ ఏర్పాటును రద్దు చేస్తుంది.

ఎంపిక రెండు: డిఫాల్ట్ పోర్ట్‌లో నిజమైన ప్రవేశం పొందండి

కొన్ని ప్రొవైడర్లు మరియు హోస్టింగ్ ఏర్పాట్లు పత్రబద్ధమైన సేవగా పంచుకున్న లేదా ప్రత్యేక చిరునామాపై 80 మరియు 443ని ఫార్వార్డ్ చేస్తాయి. పబ్లిక్ ఎగ్జిట్ చిరునామా ఏకపక్ష ఇన్‌బౌండ్ పోర్ట్‌లను సూచిస్తుందని ఊహించడం బదులు వాస్తవంగా ఏమి చేర్చబడిందో అడగండి. ప్రత్యేక ఎగ్జిట్ చిరునామా ఇన్‌బౌండ్ ఫార్వార్డింగ్ గురించి ఏమీ చెప్పదు.

యాజమాన్యం మరియు లభ్యతను లిఖితపూర్వకంగా ధృవీకరించండి, టన్నెల్ వేరే చిరునామాతో తిరిగి కనెక్ట్ అయినప్పుడు ప్రవేశానికి ఏమవుతుందో కూడా. టన్నెల్‌తో కదిలే ప్రవేశం DNS వైఫల్యాల్లా కనిపించే అంతరాయాలను సృష్టిస్తుంది.

ఎంపిక మూడు: ముందు ఒక ఫ్రంటెండ్ పెట్టండి

చేరుకోగల చిరునామాపై రివర్స్ ప్రాక్సీ 443లో విని TLS ముగించడం మరియు VPN ద్వారా backendకి ప్రత్యేక కనెక్షన్ తెరవగలదు. సందర్శకులు ఫ్రంటెండ్ పేరు మరియు డిఫాల్ట్ పోర్ట్ చూస్తారు, ఫ్రంటెండ్ మీ తరపున backend ఎత్తైన పోర్ట్‌తో మాట్లాడుతుంది. ఇది పనిచేస్తుంది ఎందుకంటే ప్రవేశ బిందువుతో పోరాడటం బదులు ఆర్కిటెక్చర్‌ను మారుస్తుంది. అప్పుడు backendకి పబ్లిక్ ఇంటర్నెట్‌లో ఇన్‌బౌండ్ పోర్ట్ అసలు అవసరం లేదు.

ఇది మీరు నిర్వహించేదాన్ని కూడా మారుస్తుంది. ఫ్రంటెండ్ వద్ద పబ్లిక్ TLS, యాక్సెస్ పాలసీ, లాగ్‌లు మరియు లభ్యత ఉంటాయి, అది backend ఎంపికను ఉద్దేశించిన సేవకు పరిమితం చేయాలి. ఫ్రంటెండ్ నుండి backendకి దూకుడు HTTPS ఉపయోగిస్తే, ఆ దూకుడులో సర్టిఫికెట్ ధృవీకరణను ఉంచండి.

ఒకే మూలాన్ని ఉంచండి

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

తర్వాత ప్రేక్షకులను దృష్టిలో ఉంచుకుని నిర్ణయించండి. చిన్న URL నిర్వహిత ఫ్రంటెండ్‌ను సమర్థించగలదు, VPN కోసం మాత్రమే ఉన్న ప్రైవేట్ సేవను పొరపాటున పబ్లిక్‌గా మార్చడం విలువైనది కాదు.