SSTP ieņēma 443. portu: kāpēc Apache neieslēdzas

Apache pārstāj atbildēt uz 443 tajā pēcpusdienā, kad kāds ieslēdz ienākošos VPN savienojumus, un tā kļūdu žurnāls vaino bind, nevis rezervāciju, kas ir aiz tā. Windows Routing and Remote Access tajā brīdī ieslēdz SSTP, un SSTP klausītājs caur HTTP steku pieprasa TCP 443 vēl pirms jebkurš klients autentificējas. Pieprasījums paliek spēkā arī tad, ja trūkst sertifikāta, nosaukums ir nepareizs vai katrs handshake tiek noraidīts, tāpēc VPN, kurā neviens nevar ielogoties, joprojām aizņem portu. Vispirms izlasiet klausīšanās tabulu; PID, kuram pieder 443, nosaka, kura no zemāk minētajām labojumiem jums vispār ir pieejama.

Rezervācija pārdzīvo salauztu sertifikātu

SSTP iesaiņo PPP TLS sesijā, tāpēc tam vajag 443 un tāpēc tas iet caur starpniekserveriem, kas izmet citus tuneļus. Klausītājs nav socket, ko VPN pakalpojums atver sev: SstpSvc to reģistrē kodola HTTP draiverī, tāpēc ports paliek rezervēts, kamēr pakalpojums darbojas. Šī reģistrācija nekad nevaicā sertifikātam, kas nozīmē, ka beidzies nosaukums, neatbilstošs subject vai vispār nav sertifikāta atstāj 443 aizņemtu. Tad kļūmes sadalās divos virzienos: noraidītie handshake nonāk System žurnālā zem RasSstp, bet tīmekļa serveris var tikai ziņot, ka nevarēja piesaistīties.

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

Pirmā rinda atgriež īpašnieka PID; otrā nosauc pakalpojumu aiz tā, un atbilde parasti ir HTTP pakalpojums vai RRAS steks. Kad tasklist atbild ar kopīgu resursdatora procesu, lasiet pakalpojuma kolonnu, nevis miniet no procesa nosaukuma.

RasSstp brīdinājumus ir vērts lasīt tikai pēc tam, jo tie apraksta neizdevušos handshake un neko nepasaka par rezervāciju, kas izraisīja sadursmi. VPN galapunkts, kas noraida katru klientu, joprojām pārvalda portu. Uztveriet žurnālu kā otro jautājumu, nevis pirmo.

IIS dala draiveri, Apache atver socket

IIS nodod savus bindings tai pašai kodola draiverim, ko izmanto SSTP, un šis draiveris sadala ienākošos savienojumus pēc resursdatora nosaukuma un URL prefiksa, tāpēc abiem pakalpojumiem var likt gribēt 443, nevienam neizgāžoties. Apache un nginx dara pretējo: tie izsauc bind uz sava socket, un operētājsistēma atsakās, jo adrese jau ir aizņemta. Nevienā no konfigurācijām nav nekā nepareiza; atšķirība ir tajā, kurš API pārvalda portu. Tāpēc arī VPN ieslēgšana nogāž vienu vietni vienā resursdatorā un atstāj identisku vietni citā neskartu.

Šī asimetrija nosaka labošanas formu. Ja IIS jau ir priekšdurvis, sadursme kļūst par prefiksu, bindings un sertifikātu jautājumu. Ja Apache ir priekšdurvis, vai nu tas pārvietojas nost no 443, vai to dara SSTP klausītājs, un nākamā sadaļa aptver abas kustības.

Izvēlieties, kurš pakalpojums patur 443

Klausītāja ports dzīvo vienā reģistra vērtībā, decimālā DWORD zem Sstpsvc parametru atslēgas. Mainiet vērtību, restartējiet Routing and Remote Access un apstipriniet klausīšanās tabulā, ka vecais ports ir brīvs.

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

Izvēlieties portu, ko nekas cits resursdatorā nevēlas, un ierakstiet to decimāli: reg add saglabā DWORD tieši tā, kā tas rakstīts, tāpēc vērtība, kas domāta kā heksadecimāla, nokļūst kā cits ports. Ja vaicājums saka, ka vērtības nav, otrā rinda to izveido. Restart-Service RemoteAccess atmet visus, kas ir savienoti, ko ir vērts ieplānot. Pēc tam vēlreiz palaidiet klausīšanās pārbaudi, jo novecojis ieraksts uz 443 nozīmē, ka pakalpojums paturēja savu veco reģistrāciju.

Klausītāja pārvietošanai ir cena, ko reģistra izmaiņas neparāda. Parastie SSTP klienti izsauc 443, tāpēc katram klienta profilam vajag jauno portu, un plūsma pārstāj līdzināties tīmekļa pieprasījumam jebkam, kas pārbauda ceļu. Tīklā, kas pieļauj tikai HTTPS līdzīgu satiksmi, tas noņem lielāko daļu iemesla, kāpēc SSTP tika izvēlēts. Maza, pārvaldīta klientu populācija to absorbē; publiska vai BYOD lietotāju bāze ne.

Otra kustība patur 443 pie IIS un uzskata Apache par backend, uz kuru starpniekserveris pārsūta. Tā saglabā SSTP noklusējumu un atstāj vienu porta īpašnieku, par cenu pārsūtītām galvenēm, klienta adresi, ko lietojumprogramma vairs neredz tieši, un backend, kuram jārunā protokolā, ko starpniekserveris faktiski sūta.

Pierādiet īpašnieku, sertifikātu un handshake secībā

Pabeigts TCP savienojums pierāda, ka klausītājs eksistē, un neko citu, tāpēc portu skenēšana var izskatīties vesela, kamēr tunelis joprojām neizdodas. Četri posmi neizdodas dažādi, un labojums, kas vērsts uz posmu, kuru jūs nesalauzāt, parasti padziļina sadursmi. Apstrādājiet tos secībā un apstājieties tur, kur atbilde sazarojas.

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

Pirmā rinda nosauc PID, kas tur 443, un tam vajadzētu būt pakalpojumam, kuru tikko konfigurējāt. Otrā uzskaita mašīnas sertifikātus ar to subject, tāpēc vārds, kas neatbilst adresei klienta profilā, uzreiz krīt acīs. Notikumu vaicājums atgriež jaunākos SSTP ierakstus, un handshake, kas nekad nesasniedz PPP autentifikāciju, atstāj citu ierakstu nekā tas, kas autentificējas un pēc tam tiek noraidīts. Pēdējais posms ir redzams tikai klientā, kur ieraksts vai nu ziņo savienots, vai nosauc PPP kļūdu.

Kad vienam resursdatoram jāveic abi darbi, apzināti izvēlieties 443 īpašnieku un pierakstiet izvēli, jo citādi nākamais cilvēks, kurš ieslēgs kādu funkciju, šo sadursmi atklās no jauna. Lomu atdalīšana paliek tīrākā atbilde: publiskam tīmekļa serverim un attālās piekļuves galapunktam ir atsevišķi ielāpu, sertifikātu un restartēšanas cikli, un šie cikli satiekas pēc sava grafika. Jebkurā gadījumā nodošanas piezīmē atstājiet klausīšanās pārbaudi, reģistra ceļu un izvēlēto portu.