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 պետք և դրա համար է այն անցնում պրոքսիներով, որոնք դեն են նետում այլ թունելներ։ Լսողը այն socket-ը չէ, որ VPN ծառայությունը բացում է իր համար, քանի որ SstpSvc-ն այն գրանցում է միջուկի HTTP դրայվերի մոտ, ուստի պորտը վերապահված է մնում քանի դեռ ծառայությունը աշխատում է։ Այդ գրանցումը երբեք չի հարցնում վկայականին, ինչը նշանակում է, որ ժամկետանց անունը, անհամապատասխան subject-ը կամ ընդհանրապես վկայականի բացակայությունը 443-ը թողնում են զբաղված։ Այնուհետև խափանումները բաժանվում են երկու ուղղությամբ, քանի որ մերժված handshake-երը հայտնվում են System մատյանում RasSstp-ի տակ, մինչդեռ վեբ սերվերը կարող է միայն հայտնել, որ չի կարողացել 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-ը անում են հակառակը, նրանք bind են կանչում իրենց socket-ի վրա, և օպերացիոն համակարգը մերժում է, որովհետև հասցեն արդեն զբաղված է։ Ոչ մի սխալ չկա այդ երկու կոնֆիգուրացիաներից ոչ մեկում, տարբերությունը նրանում է, թե որ API-ն է տիրում պորտին։ Դա է պատճառը, որ VPN-ի միացումը գետնին է տալիս մի հոսթի վրա մի կայք և անվնաս է թողնում նույնական կայքը մյուս հոսթի վրա։

Այս ասիմետրիան որոշում է վերանորոգման ձևը։ Եթե IIS-ն արդեն առջևի դուռն է, բախումը դառնում է նախածանցերի, bindings-ների և վկայականների հարց։ Եթե Apache-ն է առջևի դուռը, ապա կամ այն տեղափոխվում է 443-ից, կամ SSTP լսողը, և հաջորդ բաժինը լուսաբանում է երկու քայլերը։

Ընտրեք, թե որ ծառայությունը պահի 443-ը

Լսողի պորտը ապրում է մեկ ռեեստրի արժեքում՝ տասնորդական DWORD Sstpsvc պարամետրերի բանալու տակ։ Փոխեք արժեքը, վերագործարկեք 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-ը, և դա պետք է լինի այն ծառայությունը, որը հենց նոր կարգավորեցիք։ Երկրորդը թվարկում է մեքենայի վկայականները իրենց subject-ներով, ուստի հաճախորդի պրոֆիլի հասցեին չհամապատասխանող անունը անմիջապես աչքի է ընկնում։ Իրադարձությունների հարցումը վերադարձնում է վերջին SSTP գրառումները, և այն handshake-ը, որը երբեք չի հասնում PPP նույնականացմանը, թողնում է այլ գրառում, քան այն, որ նույնականացվում և ապա մերժվում է։ Վերջին փուլը տեսանելի է միայն հաճախորդի վրա, որտեղ գրառումը կա՛մ հաղորդում է միացված, կա՛մ նշում է PPP սխալը։

Երբ մեկ հոսթ պետք է անի երկու աշխատանքն էլ, գիտակցաբար ընտրեք 443-ի տիրոջը և գրի առեք ընտրությունը, որովհետև հակառակ դեպքում հաջորդ մարդը, ով կմիացնի որևէ ֆունկցիա, նորից կհայտնաբերի այս բախումը։ Դերերի տարանջատումը մնում է ամենամաքուր պատասխանը, քանի որ հանրային վեբ սերվերը և հեռավոր մուտքի վերջնակետը կրում են առանձին կարկատանների, վկայականների և վերագործարկումների ցիկլեր, և այդ ցիկլերը հանդիպում են իրենց սեփական ժամանակացույցով։ Ամեն դեպքում, հանձնման նշման մեջ թողեք լսելու ստուգումը, ռեեստրի ուղին և ընտրված պորտը։