SSTP పోర్ట్ 443ని తీసుకుంది: Apache ఎందుకు ప్రారంభం కాదు

ఎవరైనా ఇన్‌కమింగ్ VPN కనెక్షన్లను ప్రారంభించిన ఆ మధ్యాహ్నం Apache 443పై సమాధానం ఇవ్వడం ఆపేస్తుంది, మరియు దాని లోపాల లాగ్ వెనుక ఉన్న రిజర్వేషన్‌ను కాకుండా bindని నిందిస్తుంది. Windows Routing and Remote Access ఆ క్షణంలో SSTP సేవను ప్రారంభిస్తుంది, మరియు SSTP లిజనర్ ఏ క్లయింట్ ప్రామాణీకరణ చెందకముందే HTTP స్టాక్ ద్వారా TCP 443ని క్లెయిమ్ చేస్తుంది. సర్టిఫికెట్ లేకపోయినా, పేరు తప్పయినా లేదా ప్రతి handshake తిరస్కరించబడినా క్లెయిమ్ అమలులో ఉంటుంది, కాబట్టి ఎవరూ లాగిన్ కాలేని VPN కూడా పోర్టునే ఆక్రమిస్తుంది. మొదట వినడం పట్టికను చదవండి; 443ని కలిగి ఉన్న PID క్రింది ఏ సరిదిద్దుడు మీకు తెరిచి ఉందో నిర్ణయిస్తుంది.

రిజర్వేషన్ విరిగిన సర్టిఫికెట్ కంటే ఎక్కువ కాలం నిలుస్తుంది

SSTP PPPని TLS సెషన్‌లో చుట్టుతుంది, అందుకే దానికి 443 అవసరం మరియు అందుకే అది ఇతర టన్నెళ్లను వదిలే ప్రాక్సీల గుండా వెళ్తుంది. లిజనర్ VPN సేవ తన కోసం తెరిచే socket కాదు: SstpSvc దానిని కర్నెల్ HTTP డ్రైవర్ వద్ద నమోదు చేస్తుంది, కాబట్టి సేవ నడిచేంత వరకు పోర్టు రిజర్వ్ చేయబడి ఉంటుంది. ఆ నమోదు ఎప్పుడూ సర్టిఫికెట్‌ను అడగదు, అంటే గడువు ముగిసిన పేరు, సరిపోని subject లేదా సర్టిఫికెట్ లేకపోవడం 443ని ఆక్రమించినట్లే ఉంచుతాయి. తర్వాత వైఫల్యాలు రెండు దిశలుగా చీలుతాయి: తిరస్కరించిన handshakeలు RasSstp కింద System లాగ్‌లోకి వెళ్తాయి, వెబ్ సర్వర్ మాత్రం bind చేయలేకపోయిందని మాత్రమే తెలియజేయగలదు.

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

మొదటి పంక్తి యజమాని PIDని తిరిగి ఇస్తుంది; రెండవది దాని వెనుక ఉన్న సేవను పేర్కొంటుంది, మరియు సమాధానం సాధారణంగా HTTP సేవ లేదా RRAS స్టాక్. ఎప్పుడు tasklist పంచుకున్న హోస్ట్ ప్రాసెస్‌తో సమాధానం ఇస్తుందో, ప్రాసెస్ పేరు నుండి ఊహించకుండా సేవ నిలువు వరుసను చదవండి.

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

IIS డ్రైవర్‌ను పంచుకుంటుంది, Apache socket తెరుస్తుంది

IIS తన bindingsని SSTP ఉపయోగించే అదే కర్నెల్ డ్రైవర్‌కు అప్పగిస్తుంది, ఆ డ్రైవర్ వచ్చే కనెక్షన్లను హోస్ట్ పేరు మరియు URL ఉపసర్గ ప్రకారం వేరు చేస్తుంది, కాబట్టి రెండు సేవలను 443 కావాలని అడగవచ్చు, ఏదీ విఫలం కాదు. Apache మరియు nginx దీనికి విరుద్ధంగా చేస్తాయి: తమ socketపై bind పిలుస్తాయి, చిరునామా ఇప్పటికే ఆక్రమించబడినందున ఆపరేటింగ్ సిస్టమ్ తిరస్కరిస్తుంది. రెండు కాన్ఫిగరేషన్లలోనూ తప్పు ఏమీ లేదు; తేడా ఏ API పోర్టును కలిగి ఉంది అనేదానిలో ఉంది. అందుకే VPNని ప్రారంభించడం ఒక హోస్ట్‌లో ఒక సైట్‌ను పడగొడుతుంది, మరో హోస్ట్‌లో అదే సైట్ తాకబడకుండా ఉంటుంది.

ఈ అసమతౌల్యం మరమ్మతు ఆకారాన్ని నిర్ణయిస్తుంది. IIS ఇప్పటికే ముందు తలుపు అయితే, ఘర్షణ ఉపసర్గలు, bindings మరియు సర్టిఫికెట్ల ప్రశ్నగా మారుతుంది. Apache ముందు తలుపు అయితే, అది 443 నుండి వైపు జరుగుతుంది లేదా SSTP లిజనర్ జరుగుతుంది, తదుపరి విభాగం రెండు చర్యలను కవర్ చేస్తుంది.

443ని ఏ సేవ ఉంచుతుందో ఎంచుకోండి

లిజనర్ పోర్టు ఒకే రిజిస్ట్రీ విలువలో నివసిస్తుంది, Sstpsvc పారామితి కీ కింద దశాంశ DWORD. విలువను మార్చండి, Routing and Remote Accessని పునఃప్రారంభించండి, పాత పోర్టు ఖాళీగా ఉందని వినడం పట్టిక నుండి నిర్ధారించండి.

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

హోస్ట్‌లో మరేదీ కోరుకోని పోర్టును ఎంచుకోండి, దానిని దశాంశంలో టైప్ చేయండి: reg add DWORDని రాసినట్లుగానే నిల్వ చేస్తుంది, కాబట్టి షోడశాంశంగా భావించిన విలువ మరో పోర్టుగా పడుతుంది. విలువ లేదని ప్రశ్న చెబితే, రెండవ పంక్తి దానిని సృష్టిస్తుంది. Restart-Service RemoteAccess కనెక్ట్ అయిన వారందరినీ బయటకు పంపుతుంది, దానిని ప్లాన్ చేయడం విలువైనది. తర్వాత వినడం తనిఖీని మళ్లీ నడపండి, ఎందుకంటే 443పై పాత నమోదు ఉంటే సేవ తన పాత నమోదును ఉంచుకున్నట్లు అర్థం.

లిజనర్‌ను తరలించడానికి రిజిస్ట్రీ మార్పు చూపని ధర ఉంది. సాధారణ SSTP క్లయింట్లు 443ని డయల్ చేస్తాయి, కాబట్టి ప్రతి క్లయింట్ ప్రొఫైల్‌కు కొత్త పోర్టు అవసరం, మరియు మార్గాన్ని పరిశీలించే ఏదైనా వెబ్ అభ్యర్థనలా ప్రవాహం కనిపించడం ఆపేస్తుంది. HTTPS లాగా కనిపించే ట్రాఫిక్‌ను మాత్రమే సహించే నెట్‌వర్క్‌లో, అది SSTP ఎంచుకోవడానికి గల చాలా కారణాన్ని తీసివేస్తుంది. చిన్న, నిర్వహిత క్లయింట్ జనాభా దీనిని స్వీకరిస్తుంది; పబ్లిక్ లేదా BYOD వినియోగదారు ఆధారం కాదు.

మరో చర్య 443ని IIS వద్ద ఉంచి, Apacheని ప్రాక్సీ ఫార్వార్డ్ చేసే backendగా పరిగణిస్తుంది. ఇది SSTP డిఫాల్ట్‌ను కాపాడుతుంది మరియు పోర్టుకు ఒకే యజమానిని వదిలిస్తుంది, కానీ ఫార్వార్డ్ చేయబడిన శీర్షికలు, అప్లికేషన్ ఇకపై నేరుగా చూడని క్లయింట్ చిరునామా మరియు ప్రాక్సీ నిజంగా పంపే ప్రోటోకాల్‌ను మాట్లాడవలసిన backend ధరకు.

యజమాని, సర్టిఫికెట్ మరియు handshakeను వరుసగా నిరూపించండి

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

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

మొదటి పంక్తి 443ని కలిగి ఉన్న PIDను పేర్కొంటుంది, మరియు అది మీరు ఇప్పుడే కాన్ఫిగర్ చేసిన సేవ అయి ఉండాలి. రెండవది మెషీన్ సర్టిఫికెట్లను వాటి subjectsతో జాబితా చేస్తుంది, కాబట్టి క్లయింట్ ప్రొఫైల్‌లోని చిరునామాతో సరిపోని పేరు వెంటనే కంటికి తగులుతుంది. ఈవెంట్ ప్రశ్న ఇటీవలి SSTP రికార్డులను తిరిగి ఇస్తుంది, మరియు PPP ప్రామాణీకరణను ఎప్పుడూ చేరని handshake ప్రామాణీకరణ చెంది తర్వాత తిరస్కరించబడిన దానికంటే భిన్నమైన రికార్డును వదిలిస్తుంది. చివరి దశ క్లయింట్‌పై మాత్రమే కనిపిస్తుంది, అక్కడ నమోదు కనెక్ట్ అయినట్లు నివేదిస్తుంది లేదా PPP లోపాన్ని పేర్కొంటుంది.

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