కార్పొరేట్ VPN వెనుక యాప్ అభ్యర్థనలు విఫలమవుతాయి, కానీ బ్రౌజర్ పనిచేస్తుంది

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

యాప్ నిజంగా పంపే అభ్యర్థనను చూడండి

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

చివరి రెండింటిని అదే గమ్యస్థానానికి అమలు చేసి అవి ఎక్కడ విభేదిస్తాయో చూడండి. పనిచేసే బ్రౌజర్ మరియు పనిచేసే curl మరియు పనిచేయని యాప్ సమస్యను యాప్ జోడించే ఒకదానికి కుదిస్తాయి: ప్రాక్సీ, రవాణా లేదా సందేశ పరిమాణం.

ఎవరూ కాన్ఫిగర్ చేయని ప్రాక్సీని యాప్ వారసత్వంగా పొందింది

చాలా HTTP స్టాక్లు డిఫాల్ట్‌గా ఆపరేటింగ్ సిస్టమ్ నుండి ప్రాక్సీ కాన్ఫిగరేషన్‌ను చదువుతాయి. కార్పొరేట్ VPN క్లయింట్ తరచుగా దాన్ని తన యాక్సెస్ ప్రొఫైల్‌లో భాగంగా ఇన్‌స్టాల్ చేస్తుంది, కాబట్టి అభ్యర్థనలు డెవలపర్ కోడ్‌లో ఎప్పుడూ ప్రస్తావించని ప్రాక్సీ ద్వారా బయటకు వెళ్తాయి. .NET లో డిఫాల్ట్ హ్యాండ్లర్ IE/WinHTTP సెట్టింగ్ల నుండి తీసుకుంటుంది; Java -Dhttp.proxyHost చదువుతుంది; Node లో లైబ్రరీ జోడించే వరకు అంతర్నిర్మిత ప్రాక్సీ మద్దతు లేదు. వైఫల్యం అరుదుగా శుభ్రమైన తిరస్కరణగా ఉంటుంది, అందుకే ప్రజలు సర్వర్ వైపు చూడటం ప్రారంభిస్తారు.

పరీక్ష ఖర్చు ఒక అభ్యర్థన: ఒక హ్యాండ్లర్‌పై ప్రాక్సీని స్పష్టంగా ఆఫ్ చేసి పోల్చండి.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

మీరు ఎంచుకున్న పోర్ట్ విధానం అనుమతించే పోర్ట్ కాదు

రూట్ చేయబడిన హోస్ట్ అనుమతించిన సేవ కాదు. కార్పొరేట్ విధానం సాధారణంగా బయటకు వెళ్లే వెబ్ పోర్ట్‌లను అనుమతించి మిగతావి విసిరేస్తుంది, కాబట్టి 8080 లేదా 1883 పై ఉన్న సేవను చేరుకోలేము, అయితే 443 బాగా పనిచేస్తుంది. బ్రౌజర్ ఇక్కడ ఏమీ నిరూపించదు: అది నిర్వచనం ప్రకారం 443 వాడుతుంది.

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

మార్గం రీసెట్ చేసే ముడి TCP

దీర్ఘకాలం జీవించే ముడి TCP కనెక్షన్లు అత్యంత గందరగోళంగా విఫలమయ్యే పొర. వెబ్ ట్రాఫిక్‌ను అనుమతించే మార్గం కూడా అసాధారణ బయటకు వెళ్లే TCP ను రీసెట్ చేయవచ్చు లేదా తిరిగి రాయవచ్చు, మరియు క్లయింట్ అంతరాయంగా చదవబడే సాకెట్ లోపాన్ని నివేదిస్తుంది. సందేశం మరియు ఈవెంట్ సేవలు ఇటువంటి నెట్‌వర్క్ కోసమే WebSocket రవాణాను అందిస్తాయి, మారడం సొరంగ మార్పు కాదు, క్లయింట్ ఎంపిక.

రవాణాను మార్చి, మళ్లీ పరీక్షించి, అదే రన్‌లో మరేదీ మార్చవద్దు. ఆ ఒకే-చర పరీక్ష రీసెట్ మార్గం నుండి వచ్చిందా సేవ నుండి వచ్చిందా అని చెబుతుంది.

పెద్ద పేలోడ్లపై మాత్రమే మూసుకునే కనెక్షన్లు

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

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

ఒకే దశలో నాలుగింటిని ఎలా వేరు చేయాలి

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

ప్రతి పరీక్షలో ఒక చరాన్ని ఉంచి, మీరు ఉపయోగించిన గమ్య హోస్ట్‌ను నమోదు చేయండి. ఆ ఆధార రేఖ లేకుండా తదుపరి వ్యక్తి నాలుగు దశలను తిరిగి మొదటి నుండి పునరావృతం చేస్తారు.