TLS ను పరిశీలించే ప్రాక్సీ వెనుక SSTP: సెషన్ ఎక్కడ విరిగిపోతుంది
సాధారణ HTTPS ను నిర్వహించే ప్రాక్సీ కూడా SSTP యొక్క ద్విముఖ POST మరియు ప్రమాణపత్ర గొలుసును విచ్ఛిన్నం చేయగలదు. దశలను దాటి మొదట విఫలమయ్యే దశను పేర్కొనండి.
మీ బ్రౌజర్ కార్పొరేట్ ఇంట్రానెట్ను లోడ్ చేస్తుంది, ప్రాక్సీ ప్రమాణపత్రం విశ్వసనీయం, అయినా SSTP క్లయింట్ కనెక్షన్ ముగింపు దగ్గర పడిపోతుంది. ఈ నమూనా తప్పు పాస్వర్డ్ వైపు కాదు, వెబ్ అభ్యర్థన మరియు టన్నెల్ సెషన్ మధ్య వ్యత్యాసం వైపు సూచిస్తుంది. TCP నుండి పైకి కనెక్షన్ ద్వారా వెళ్లి మొదట విఫలమయ్యే దశను గుర్తించండి. ప్రాక్సీ కారణమా కాదా అని లోపం కోడ్ కాదు, దశ చెబుతుంది.
క్లయింట్ ఆగే చోటి నుండి ప్రారంభించండి
క్లయింట్ నిర్దిష్ట క్రమాన్ని దాటుతుంది: పోర్ట్ 443 కు TCP కనెక్షన్, TLS హ్యాండ్షేక్, ప్రమాణపత్ర ధృవీకరణ, SSTP యొక్క HTTP మార్పిడి, PPP చర్చలు మరియు ప్రామాణీకరణ, తర్వాత IP కాన్ఫిగరేషన్. ప్రతి దశలో వైఫల్యం వేరే జాడను వదిలిస్తుంది, వాటిని కలిపేయడం మిమ్మల్ని తప్పు కాన్ఫిగరేషన్ పేజీకి తీసుకెళ్తుంది.
TCP వైఫల్యం అంటే ఏదైనా TLS బైట్ కనిపించక ముందే సమయ ముగింపు లేదా రీసెట్. TLS వైఫల్యం అంటే హెచ్చరిక లేదా హ్యాండ్షేక్ సమయ ముగింపు. ప్రమాణపత్ర వైఫల్యం గొలుసు లేదా పేరు గురించి హెచ్చరిక ఇస్తుంది. HTTP వైఫల్యం విజయవంతమైన హ్యాండ్షేక్ తర్వాత వస్తుంది, తరచుగా స్థితి కోడ్ లేదా తక్షణ మూసివేతగా. PPP వైఫల్యం టన్నెల్ సాంకేతికంగా స్థాపించిన తర్వాత వస్తుంది, అందుకే అది ప్రామాణీకరణ సమస్యలా కనిపిస్తుంది.
మొదటి లోపం లైన్కు బదులు క్లయింట్ లాగ్లో చివరి విజయవంతమైన దశను చదవండి. లోపం లైన్ సాధారణంగా పరిణామాన్ని నివేదిస్తుంది, దశ సీమ కాదన్న భాగాన్ని పేర్కొంటుంది.
SSTP నెట్వర్క్ నుండి ఏమి మోసుకెళ్లమని కోరుతుంది
SSTP TCP 443 పై TLS మీద నడుస్తుంది, తర్వాత SSTP స్పెసిఫికేషన్లో నిర్వచించిన SSTP_DUPLEX_POST అనే HTTP అభ్యర్థనను /sra_{GUID}/ రూపంలోని మార్గానికి పంపుతుంది. అభ్యర్థన ఆచరణాత్మకంగా అపరిమిత కంటెంట్ పొడవును ప్రకటిస్తుంది మరియు సెషన్ జీవితకాలమంతా స్ట్రీమ్ను రెండు దిశలలో తెరిచి ఉంచుతుంది. PPP ఫ్రేమ్లు ఆ స్ట్రీమ్ లోపల ప్రయాణిస్తాయి.
అందుకే సాధారణ బ్రౌజింగ్ను నిర్వహించే ప్రాక్సీ కూడా విఫలమవుతుంది. పరిమిత బాడీ ఉన్న GET లేదా POST ను బఫర్ చేసి, పరిశీలించి పంపవచ్చు; ఎప్పటికీ ముగియని బాడీ ఉన్న ద్విముఖ స్ట్రీమ్ను పంపలేము. బాడీ పూర్తయ్యే వరకు వేచి ఉండే ప్రాక్సీ ఎప్పటికీ వేచి ఉంటుంది, క్లయింట్ చివరికి సమయ ముగింపుకు లోనవుతుంది.
పద్ధతి ఫిల్టరింగ్ మరియు ప్రామాణీకరణ తమ స్వంత వైఫల్య విధానాలను జోడిస్తాయి. ప్రాక్సీ అభ్యర్థనకు ఆధారాలు అడిగితే, బ్రౌజర్ సమాధానమిచ్చినా VPN క్లయింట్ ఇవ్వకపోవచ్చు. పద్ధతిని తొలగించినా లేదా తిరిగి రాసినా, PPP ప్రారంభం కాకముందే గేట్వే అభ్యర్థనను తిరస్కరిస్తుంది.
పరిశీలన గుర్తింపును ఎందుకు మారుస్తుంది
TLS ను పరిశీలించే ప్రాక్సీ క్లయింట్ యొక్క TLS కనెక్షన్ను ముగించి గేట్వేకి వేరే కనెక్షన్ తెరుస్తుంది. అందువల్ల క్లయింట్ గేట్వేది కాదు, ప్రాక్సీ ప్రమాణపత్రాన్ని ధృవీకరిస్తుంది, గేట్వే ప్రాక్సీని తన భాగస్వామిగా చూస్తుంది. సంస్థ తన సొంత మూలాన్ని పంపిణీ చేసినప్పుడు, బ్రౌజర్ మరియు VPN క్లయింట్ రెండూ ఆ గొలుసును అంగీకరించవచ్చు, కాబట్టి హ్యాండ్షేక్ విజయవంతమవుతుంది మరియు సమస్య తదుపరి దశకు వెళ్తుంది.
విజయవంతమైన ధృవీకరణ అంటే ప్రాక్సీ సెషన్ను మోసుకెళ్లగలదని కాదు. ఇంకా బఫరింగ్ లేకుండా అపరిమిత ద్విదిశ POST ను రిలే చేయాలి, రెండు కనెక్షన్లను గంటల తరబడి సజీవంగా ఉంచాలి. చాలా పరిశీలన ఉత్పత్తులు అభ్యర్థన-ప్రతిస్పందన ట్రాఫిక్ కోసం నిర్మించబడ్డాయి, ఈ సందర్భాన్ని దారుణంగా లేదా అసలు నిర్వహించవు.
అందుకే తెలియని మూలాన్ని జోడించడం లేదా ధృవీకరణను ఆపివేయడం తప్పు మరమ్మత్తు. క్లయింట్ ఏ ప్రమాణపత్రాన్ని అంగీకరిస్తుందో మారుస్తుంది; సెషన్ను నిజంగా విచ్ఛిన్నం చేసిన స్ట్రీమ్ నిర్వహణ గురించి ఏమీ చేయదు.
సెట్టింగ్లను మార్చే ముందు జారీదారుని గుర్తించండి
ఏ ప్రమాణపత్రాన్ని ప్రదర్శిస్తుంది, ఎవరు సంతకం చేశారు అని ముగింపు బిందువును అడగండి. దిగువ ఆదేశాలు VPN సెషన్ ప్రారంభించకుండా గొలుసు మరియు జారీదారుని చూపుతాయి:
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/జారీదారు పబ్లిక్ CA అయితే, ఈ హోస్ట్ కోసం కనెక్షన్ అడ్డగించబడటం లేదు, వైఫల్యం మరెక్కడో ఉంది. జారీదారు సంస్థ సొంత CA అయితే, పరిశీలన క్రియాశీలంగా ఉంది, గేట్వేను ప్రాక్సీ ద్వారా చేరుకుంటారు. పేరు ఆధారంగానే నిర్ణయించుకునే ముందు వేలిముద్రను నెట్వర్క్ జట్టు ఆశించే దానితో పోల్చండి.
అదే హోస్ట్కు బ్రౌజర్ పరీక్ష ప్రాక్సీ GET ను అంగీకరిస్తుందని మాత్రమే నిరూపిస్తుంది. SSTP పద్ధతి, అభ్యర్థన URI లేదా బాడీ ఆయుష్షు గురించి ఏమీ చెప్పదు, కాబట్టి పనిచేసే ఇంట్రానెట్ పేజీని టన్నెల్ మార్గానికి మద్దతు ఉందనే సాక్ష్యంగా పరిగణించవద్దు.
మద్దతు ఉన్న మార్గాన్ని ఎంచుకోండి
నెట్వర్క్ యజమానిని ఒక నిర్దిష్ట ప్రశ్న అడగండి: ఈ గేట్వేకి పోర్ట్ 443 పై బఫర్ లేని ద్విముఖ POST ను ప్రాక్సీ అనుమతిస్తుందా? అవును అంటే ప్రాక్సీలో మినహాయింపు లేదా VPN హోస్ట్ కోసం పత్రబద్ధమైన దారి మళ్లింపు. కాదు అంటే పరిశీలించిన మార్గం SSTP ను మోసుకెళ్లలేదు, మద్దతు ఉన్న పరిష్కారం క్లయింట్ సర్దుబాటు కాదు, మరో మార్గం లేదా ప్రోటోకాల్.
ఎంపికల్లో సాధారణంగా VPN గేట్వేకి పరిశీలించని నిష్క్రమణ, ప్రాక్సీ ద్వారా కార్పొరేట్ ట్రాఫిక్ మాత్రమే పంపే విభజిత టన్నెల్ రూపకల్పన, లేదా సంస్థ మరో పోర్ట్లో మద్దతు ఇచ్చే ప్రత్యామ్నాయ ప్రోటోకాల్ ఉంటాయి. ప్రతిదీ నెట్వర్క్ రూపకల్పనలో భాగం, పోలిక మార్గాన్ని వేరుచేయడానికి ప్రతిదీ ఒకే పరికరం మరియు ప్రొఫైల్తో పరీక్షించాలి.
ఫలితాన్ని నమోదు చేయండి: జారీదారు, విఫలమైన దశ, ప్రాక్సీ నియమం మరియు ఎంచుకున్న మార్గం. 98 శాతం వద్ద అదే నిలిచిపోవడాన్ని చూసే తదుపరి వ్యక్తి మొత్తం ప్రయాణాన్ని పునరావృతం చేయకుండా ఒక వాస్తవాన్ని తనిఖీ చేయగలడు.