SSTP පෝට් 443 ගත්තා: Apache ඇයි පටන් ගන්නේ නැත්තේ

Apache 443 මත පිළිතුරු දීම නවත්වන්නේ යමෙක් එන VPN සම්බන්ධතා සක්‍රීය කරන එදා දහවල් ය, සහ එහි දෝෂ ලොගය පිටුපස ඇති වෙන් කිරීම වෙනුවට 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 හිමිකරු දැනුවත්ව තෝරා තේරීම ලියා තබන්න, එසේ නොමැති නම් ඊළඟ පුද්ගලයා කිසියම් විශේෂාංගයක් සක්‍රීය කරන විට මෙම ගැටුම නැවත සොයා ගනු ඇත. භූමිකා වෙන් කිරීම පිරිසිදුම පිළිතුර ලෙස පවතී: පොදු වෙබ් සේවාදායකයක් සහ දුරස්ථ ප්‍රවේශ අන්ත ලක්ෂ්‍යයක් වෙන වෙනම patch, සහතික සහ නැවත ආරම්භ කිරීමේ චක්‍ර දරයි, එම චක්‍ර ඔවුන්ගේම කාලසටහනට අනුව හමු වේ. කෙසේ වුවත්, සවන් දීමේ පරීක්ෂාව, රෙජිස්ට්‍රි මාර්ගය සහ තෝරාගත් පෝට් එක භාර දීමේ සටහනේ තබන්න.