SSTP го зазеде портот 443: зошто Apache не стартува

Apache престанува да одговара на 443 во попладнето кога некој ќе вклучи дојдовни VPN врски, а неговиот дневник на грешки го обвинува bind наместо резервацијата што стои зад него. Windows Routing and Remote Access во тој момент вклучува SSTP, а SSTP слушачот бара TCP 443 преку HTTP стекот пред воопшто да се автентицира некој клиент. Барањето важи дури и кога сертификатот недостасува, името е погрешно или секој handshake е одбиен, па VPN во кој никој не може да влезе сѐ уште го држи портот. Прво прочитајте ја табелата за слушање; PID-от што го држи 443 одлучува која од долунаведените поправки воопшто ви е отворена.

Резервацијата го надживува скршениот сертификат

SSTP го завиткува PPP во TLS сесија, затоа му треба 443 и затоа поминува низ прокси сервери што ги отфрлаат другите тунели. Слушачот не е socket што VPN услугата го отвора за себе: SstpSvc го регистрира кај HTTP драјверот на јадрото, па портот останува резервиран сѐ додека услугата работи. Таа регистрација никогаш не го прашува сертификатот, што значи дека истечено име, несоодветен subject или воопшто нема сертификат го оставаат 443 заземен. Потоа грешките се делат во две насоки: одбиените handshake завршуваат во System дневникот под RasSstp, додека веб-серверот може само да пријави дека не можел да се врзе.

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

Првиот ред го именува PID-от што го држи 443, а тоа треба да биде услугата што штотуку ја конфигуриравте. Вториот ги набројува сертификатите на машината со нивните subjects, па име што не се совпаѓа со адресата во клиентскиот профил веднаш паѓа во очи. Барањето за настани враќа неодамнешни SSTP записи, а handshake што никогаш не стасува до PPP автентикација остава поинаков запис од оној што се автентицира и потоа е одбиен. Последната фаза е видлива само на клиентот, каде ставката или пријавува поврзано или го именува PPP теророт.

Кога еден хост мора да ги врши двете работи, свесно изберете го сопственикот на 443 и запишете ја одлуката, бидејќи инаку следниот човек што ќе вклучи некоја функција повторно ќе го открие овој судир. Раздвојувањето на улогите останува почист одговор: јавен веб-сервер и крајна точка за далечински пристап носат одделни циклуси на закрпи, сертификати и рестартирања, и тие циклуси се среќаваат по сопствен распоред. Во секој случај, во белешката за предавање оставете ја проверката за слушање, патеката во регистри и избраниот порт.