బ్రౌజర్ HTTPS విజయవంతమయ్యే చోట SSTP విఫలమవుతుంది: ఎందుకు
SSTP పోర్ట్ 443లో TLS లోపల నడుస్తుంది, కానీ అది వెబ్ అభ్యర్థన కాదు. TCP, TLS గుర్తింపు, SSTP మార్పిడి మరియు PPP ప్రామాణీకరణను వేర్వేరు దశలుగా పరీక్షించండి.
బ్రౌజర్ VPN హోస్ట్‌నామ్‌ను HTTPS ద్వారా ఎలాంటి ఫిర్యాదు లేకుండా తెరుస్తుంది, మరియు SSTP క్లయింట్ ఇప్పటికీ కనెక్ట్ కావడానికి నిరాకరిస్తుంది. ఆ జోడీలో ఎలాంటి వైరుధ్యం లేదు. SSTP TLSని బాహ్య రవాణాగా ఉపయోగించి, ఆ తర్వాత అదే కనెక్షన్ లోపల తన స్వంత అభ్యర్థనను మరియు PPP పేలోడ్‌ను అమలు చేస్తుంది, కాబట్టి పేజీ విజయవంతంగా లోడ్ కావడం ఒకే ఒక సన్నని విషయాన్ని నిరూపిస్తుంది: హోస్ట్ పోర్ట్ 443లో GETకు సమాధానం ఇస్తుంది. క్లయింట్ మరో ప్రశ్న అడుగుతోంది, మరియు సర్వర్ దానికి దారుణంగా సమాధానం ఇవ్వవచ్చు.
పేజీ లోడ్ అవుతుంది, సొరంగం కాదు
ప్రజలు బ్రౌజర్ పరీక్ష వైపు మళ్లుతారు ఎందుకంటే అది వేగంగా ఉంటుంది, ఆ తర్వాత ఫలితాన్ని సర్వర్ చేరుకోగలిగినది మరియు కాన్ఫిగర్ చేయబడినది అనే రుజువుగా తీసుకుంటారు. ఇది చిరునామా పట్టీ తెరిచిన మార్గానికి GET గురించిన రుజువు, అంతకంటే ఎక్కువ కాదు. VPN సంభాషణ అదే TLS హ్యాండ్‌షేక్ తర్వాత ప్రారంభమవుతుంది, కానీ పంపేది వెబ్ పేజీ ఎప్పుడూ ఉపయోగించని పద్ధతిని మరియు మార్గాన్ని. కాబట్టి బ్రౌజర్‌కు ఇచ్చే 200 సమాధానం SSTP చివరి బిందువు ఉందో లేదో గురించి ఏమీ చెప్పదు.
రెండు పరిశీలనలను వేరు చేయండి, అన్వేషణ చిన్నదవుతుంది. రవాణా మరియు ధృవపత్రాల గొలుసు పనిచేస్తాయి, వాటి పైన ప్రోటోకాల్ మార్పిడిలో ఏదో పనిచేయదు. ఇది విరిగిన పోర్ట్ లేదా గడువు ముగిసిన ధృవపత్రం కంటే భిన్నమైన దర్యాప్తు, మరియు భిన్నమైన ఆధారాలు అవసరం.
SSTP క్లయింట్ నిజంగా ఏమి పంపుతుంది
క్లయింట్ /sra_{GUID}/ మార్గానికి SSTP_DUPLEX_POST పద్ధతితో HTTP అభ్యర్థనను పంపి, తర్వాత కనెక్షన్ బాడీని PPP ఫ్రేమ్‌లను మోసే ద్విదిశ ప్రవాహంగా తెరిచి ఉంచుతుంది. అనుగుణమైన సర్వర్ HTTP/1.1 200 అని సమాధానం ఇచ్చి వెబ్ సర్వర్‌లా ప్రవర్తించడం ఆపేస్తుంది. మిగతాది ఏదైనా ఒక సంతకం: 405 లేదా 404 అంటే చివరి బిందువు లేదు, 301 లేదా 302 అంటే ఏదో అభ్యర్థనను మళ్లింపు చేస్తోంది, మరియు తక్షణ FIN అంటే ప్రాక్సీ లేదా సర్వర్ ప్రవాహాన్ని మూసింది.
అందుకే లక్ష్యం TLS ధృవపత్రం జోడించిన వెబ్ సర్వర్ కాదు, SSTP సర్వర్ అయి ఉండాలి. పద్ధతి, మార్గం మరియు దీర్ఘకాల బాడీ ప్రోటోకాల్ అవసరాలు, కాబట్టి రివర్స్ ప్రాక్సీ వాటిని కాన్ఫిగరేషన్ ద్వారా మాత్రమే జోడించలేదు. సాధారణ HTTPSని పరిపూర్ణంగా పంపే ప్రాక్సీ కూడా తనకు తెలియని పద్ధతిని తిరస్కరించవచ్చు.
ప్రాక్సీ లేదా వెబ్ సర్వర్ ప్రవాహాన్ని ఎక్కడ విచ్ఛిన్నం చేస్తుంది
మధ్యవర్తి ఏదైనా పంపే ముందు HTTP అభ్యర్థన పంక్తిని పరిశీలిస్తాడు, అసాధారణ మార్గంతో కూడిన అనుకూల పద్ధతి అతని నియమాలలో విఫలమవచ్చు. కొన్ని పరికరాలు సాధారణ పేజీని అందిస్తూ సొరంగాన్ని తిరస్కరిస్తాయి లేదా అంతరాయం కలిగిస్తాయి, కాబట్టి క్లయింట్ స్వచ్ఛమైన తిరస్కరణకు బదులు ప్రారంభమై తర్వాత చనిపోయే కనెక్షన్‌ను నివేదిస్తుంది. మరికొన్ని అభ్యర్థనను అంగీకరించి, తర్వాత PPP కీప్‌అలైవ్‌లు తట్టుకోలేని బాడీ లేదా నిష్క్రియ సమయ పరిమితిని వర్తింపజేస్తాయి. క్లయింట్ వైపు నుండి రెండూ ఒకేలా కనిపిస్తాయి, కాబట్టి ఏ దశ విఫలమైంది అనేది లోపం వచనం కంటే ముఖ్యం.
ఒక వెబ్‌సైట్ మరియు SSTP మధ్య పోర్ట్ 443 పంచుకోవడం రూటింగ్ ఎంపిక, ప్రతి హాప్ రెండు సంభాషణలను ఒకే విధంగా నిర్వహిస్తుందని హామీ కాదు. మార్గంలో లోడ్ బ్యాలెన్సర్, ఫైర్‌వాల్ లేదా TLS టర్మినేటర్ ఉంటే, VPN కాన్ఫిగరేషన్‌ను తాకే ముందు దాన్ని అనుమానితుల జాబితాలో చేర్చండి.
దశలను విడివిడిగా పరీక్షించండి
తనిఖీలను క్రమంగా అమలు చేసి మొదటి వైఫల్యం వద్ద ఆగండి, ఎందుకంటే ప్రతి దశ వేరే పొరను మినహాయిస్తుంది. క్రింది TLS ప్రోబ్ ధృవపత్రం గుర్తింపును SSTP చేసే అన్నింటి నుండి వేరు చేస్తుంది. హోస్ట్‌నామ్‌ను మీ చివరి బిందువుతో మార్చి అది ముద్రించే subject మరియు గొలుసును చదవండి.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comతర్వాత క్లయింట్ లోపం నుండి ఊహించకుండా మిగిలిన ఆధారాలను దశలకు సరిపోల్చండి. క్రింది పట్టిక టికెట్‌లో ఉదహరించడానికి చెక్‌లిస్ట్, ఒక వైఫల్యాన్ని తదుపరి దాని నుండి వేరు చేసే సంతకంతో.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
టికెట్‌లో "కనెక్ట్ కాలేము" అని రాయడానికి బదులు చివరి విజయవంతమైన దశను నమోదు చేయండి. MS-SSTP స్పెసిఫికేషన్ TLS హ్యాండ్‌షేక్ తర్వాత వచ్చే అభ్యర్థనను మరియు PPP మార్పిడిని నమోదు చేస్తుంది, బ్రౌజర్ పరీక్ష వాటిలో దేనినీ భర్తీ చేయలేని కారణానికి సూచన అదే.
మొదట గుర్తింపు, తర్వాత PPP
TLS గుర్తింపు మరియు PPP ప్రామాణీకరణ క్రమానుగతమైనవి, ప్రత్యామ్నాయం కాదు, వాటిని గందరగోళపరచడం ప్రజలను తప్పు సర్వర్ సెట్టింగ్‌కు పంపుతుంది. క్లయింట్ మొదట సర్వర్ ధృవపత్రాన్ని మరియు దాని ఉద్దేశిత ప్రయోజనాన్ని ధృవీకరించి, తర్వాత PPP తన స్థితిని చర్చించి వినియోగదారుని సవాలు-ప్రతిస్పందన పద్ధతి లేదా EAP ద్వారా ప్రామాణీకరిస్తుంది. ధృవపత్రం సమస్య తిరస్కరించబడిన పాస్‌వర్డ్ కంటే భిన్నమైన లోపాన్ని ఇస్తుంది, ఏ లోపం మరొకటి కవర్ చేసే దశను వివరించదు.
హోస్ట్‌నామ్‌ను చిరునామాతో మార్చడం, లేదా ధృవపత్ర హెచ్చరికను దాటి క్లిక్ చేయడం, విఫలమవుతున్న దశను గుర్తించే తనిఖీని సరిచేయడానికి బదులు తొలగిస్తుంది. హెచ్చరికను ఉంచి చదవండి. HTTP మార్పిడి ఎప్పుడూ SSTP ప్రవర్తనను చేరుకోనప్పుడు PPP పాస్‌వర్డ్‌ను రీసెట్ చేయవద్దు, ఎందుకంటే ఆధారాలు ఎప్పుడూ అడగబడలేదు.