SSTP துறைமுகம் 443ஐ எடுத்துக்கொண்டது: Apache ஏன் தொடங்குவதில்லை

தோல்வியடையும் தளம் 443ஐப் பிடித்திருப்பது அல்ல. Windows SSTP HTTP அடுக்கு வழியாக துறைமுகத்தை ஒதுக்குகிறது: கேட்பானை நகர்த்துங்கள், அதன் முன் IIS வையுங்கள், அல்லது தளத்தை நகர்த்துங்கள்.

யாராவது உள்வரும் 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 அதை kernelன் 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 பயன்படுத்தும் அதே kernel இயக்கியிடம் ஒப்படைக்கிறது, அந்த இயக்கி உள்வரும் இணைப்புகளை புரவலன் பெயர் மற்றும் URL முன்னொட்டின் அடிப்படையில் பிரிக்கிறது, எனவே இரு சேவைகளையும் 443 வேண்டும் என்று கேட்கலாம், எதுவும் தோல்வியடையாது. Apache மற்றும் nginx நேர்மாறாகச் செய்கின்றன: தங்கள் socketஇல் bind அழைக்கின்றன, முகவரி ஏற்கனவே ஆக்கிரமிக்கப்பட்டுள்ளதால் இயங்குதளம் மறுக்கிறது. இரு அமைப்புகளிலும் தவறு எதுவுமில்லை; வேறுபாடு எந்த API துறைமுகத்தை வைத்திருக்கிறது என்பதில் உள்ளது. அதனால்தான் VPNஐ இயக்குவது ஒரு புரவலனில் ஒரு தளத்தை வீழ்த்தி மற்றொரு புரவலனில் அதே தளத்தைத் தொடாமல் விடுகிறது.

இந்த சமச்சீரற்ற தன்மை பழுதுநீக்கத்தின் வடிவத்தைத் தீர்மானிக்கிறது. IIS ஏற்கனவே முன் கதவாக இருந்தால், மோதல் முன்னொட்டுகள், bindings மற்றும் சான்றிதழ்களின் கேள்வியாகிறது. Apache முன் கதவாக இருந்தால், ஒன்று அது 443இலிருந்து விலகுகிறது அல்லது SSTP கேட்பான் விலகுகிறது, அடுத்த பகுதி இரு நடவடிக்கைகளையும் உள்ளடக்குகிறது.

443ஐ எந்தச் சேவை வைத்திருக்கும் என்பதைத் தேர்ந்தெடுங்கள்

கேட்பானின் துறைமுகம் ஒரே rejista மதிப்பில் வாழ்கிறது, 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இல் பழைய பதிவு இருந்தால் சேவை தன் பழைய பதிவை வைத்துக்கொண்டது என்பதே பொருள்.

கேட்பானை நகர்த்துவதற்கு rejista திருத்தம் காட்டாத விலை உண்டு. சாதாரண 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இன் உரிமையாளரை வேண்டுமென்றே தேர்ந்தெடுத்து தேர்வை எழுதி வையுங்கள், இல்லையெனில் ஏதேனும் அம்சத்தை இயக்கும் அடுத்த நபர் இந்த மோதலை மீண்டும் கண்டுபிடிப்பார். பாத்திரங்களைப் பிரிப்பதே தூய்மையான பதிலாக இருக்கிறது: பொது வலை சேவையகமும் தொலை அணுகல் முனைப்புள்ளியும் தனித்தனி patch, சான்றிதழ் மற்றும் மறுதொடக்க சுழற்சிகளைக் கொண்டுள்ளன, அந்தச் சுழற்சிகள் தங்கள் சொந்த அட்டவணைப்படி சந்திக்கின்றன. எப்படியிருந்தாலும், கேட்டல் சரிபார்ப்பு, rejista பாதை மற்றும் தேர்ந்தெடுத்த துறைமுகத்தை ஒப்படைப்புக் குறிப்பில் விடுங்கள்.

தொடர்புடைய கட்டுரைகள்