SSTP okupis pordon 443: kial Apache ne ekfunkcias

Apache ĉesas respondi sur 443 tiun posttagmezon, kiam iu ŝaltas envenantajn VPN-konektojn, kaj ĝia erarprotokolo kulpigas la ligon anstataŭ la rezervon malantaŭ ĝi. Windows Routing and Remote Access ŝaltas SSTP en tiu momento, kaj la SSTP-aŭskultanto postulas TCP 443 tra la HTTP-stako antaŭ ol iu ajn kliento aŭtentiĝos. La postulo restas valida eĉ kiam la atestilo mankas, la nomo estas malĝusta aŭ ĉiu manpremo estas rifuzata, do VPN, en kiun neniu povas ensaluti, ankoraŭ okupas la pordon. Legu unue la aŭskultan tabelon; la PID, kiu posedas 443, decidas, kiun el la subaj riparoj eĉ eblas por vi.

La rezervo postvivas rompitan atestilon

SSTP envolvas PPP en TLS-sesion, tial ĝi bezonas 443 kaj tial ĝi vojaĝas tra prokuriloj, kiuj forĵetas aliajn tunelojn. La aŭskultanto ne estas ingo, kiun la VPN-servo malfermas por si mem: SstpSvc registras ĝin ĉe la kerna HTTP-pelilo, do la pordo restas rezervita dum la servo funkcias. Tiu registrado neniam konsultas la atestilon, kio signifas, ke eksvalidiĝinta nomo, malkongrua subject aŭ tute nenia atestilo lasas 443 okupita. Fiaskoj poste dividiĝas en du direktojn: rifuzitaj manpremoj alteriĝas en la System-protokolo sub RasSstp, dum la reteja servilo povas nur raporti, ke la ligo malsukcesis.

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

La unua linio redonas la posedantan PID; la dua nomas la servon malantaŭ ĝi, kaj la respondo kutime estas la HTTP-servo aŭ la RRAS-stako. Kiam tasklist respondas per kunhava gastiganta procezo, legu la servokolonon anstataŭ diveni el la proceza nomo.

RasSstp-vertoj indas legi nur poste, ĉar ili priskribas manpremon, kiu fiaskis, kaj diras nenion pri la rezervo, kiu kaŭzis la kolizion. VPN-finpunkto, kiu rifuzas ĉiun klienton, ankoraŭ posedas la pordon. Traktu la protokolon kiel la duan demandon, ne la unuan.

IIS kunhavas la pelilon, Apache malfermas ingon

IIS transdonas siajn bindings al la sama kernpelilo, kiun uzas SSTP, kaj tiu pelilo dispartigas envenantajn konektojn laŭ gastiga nomo kaj URL-prefikso, do ambaŭ servoj povas esti petitaj voli 443 sen ke iu ajn el ili fiasku. Apache kaj nginx faras la malon: ili vokas bind sur sia propra ingo, kaj la operaciumo rifuzas, ĉar la adreso estas jam okupita. Nenio en iu ajn el la du agordoj estas malĝusta; la diferenco kuŝas en tio, kiu API posedas la pordon. Tial ankaŭ ŝalti la VPN faligas unu retejon ĉe unu gastiganto kaj lasas identan retejon ĉe alia gastiganto netuŝita.

Tiu nesimetrio decidas la formon de la ripeto. Se IIS jam estas la antaŭpordo, la kolizio fariĝas demando pri prefiksoj, bindings kaj atestiloj. Se Apache estas la antaŭpordo, aŭ ĝi moviĝas for de 443 aŭ la SSTP-aŭskultanto faras tion, kaj la sekva sekcio kovras ambaŭ movojn.

Elektu, kiu servo tenas 443

La aŭskulta pordo loĝas en unu sola registra valoro, dekuma DWORD sub la parametra ŝlosilo de Sstpsvc. Ŝanĝu la valoron, restartigu Routing and Remote Access, kaj konfirmu el la aŭskulta tabelo, ke la malnova pordo estas libera.

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

Elektu pordon, kiun nenio alia en la gastiganto volas, kaj tajpu ĝin dekume: reg add konservas la DWORD-on ĝuste kiel skribite, do valoro celita kiel deksesuma alteriĝas kiel alia pordo. Se la mendoscio diras, ke la valoro ne ekzistas, la dua linio kreas ĝin. Restart-Service RemoteAccess faligas ĉiujn, kiuj estas konektitaj, kio indas plani. Poste rerulu la aŭskultan kontrolon, ĉar malnova rikordo sur 443 signifas, ke la servo tenis sian malnovan registradon.

Movi la aŭskultanton havas prezon, kiun la registra ŝanĝo ne montras. Ordinaraj SSTP-klientoj vokas 443, do ĉiu klienta profilo bezonas la novan pordon, kaj la fluo ĉesas simili al reta peto por io ajn, kio inspektas la vojon. En reto, kiu toleras nur trafikon, kiu aspektas kiel HTTPS, tio forigas la plejparton de la kialo, pro kiu SSTP estis elektita. Malgranda, administrata klienta loĝantaro absorbas tion; publika aŭ BYOD-uzantaro ne.

La alia movo tenas 443 ĉe IIS kaj traktas Apache kiel backend, al kiu la prokurilo plusendas. Ĝi konservas la SSTP-defaŭlton kaj lasas unu posedanton por la pordo, je la kosto de plusenditaj kaplinioj, klienta adreso, kiun la aplikaĵo ne plu vidas rekte, kaj backend, kiu devas paroli la protokolon, kiun la prokurilo efektive sendas.

Pruvu la posedanton, la atestilon kaj la manpremon laŭorde

Kompletigita TCP-konekto pruvas, ke aŭskultanto ekzistas kaj nenion alian, tial pordoskano povas aspekti sana dum la tunelo ankoraŭ fiaskas. La kvar etapoj fiaskas laŭ diversaj manieroj, kaj ripeto celanta la etapon, kiun vi ne rompis, kutime profundigas la kolizion. Prilaboru ilin laŭorde kaj haltu tie, kie la respondo diverĝas.

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

La unua linio nomas la PID-on, kiu tenas 443, kaj ĝi devus esti la servo, kiun vi ĵus agordis. La dua listigas maŝinajn atestilojn kun siaj subjects, do nomo, kiu ne kongruas kun la adreso en la klienta profilo, tuj elstaras. La eventa mendoscio redonas lastatempajn SSTP-rikordojn, kaj manpremo, kiu neniam atingas PPP-aŭtentikigon, lasas alian rikordon ol tiu, kiu aŭtentiĝas kaj poste estas rifuzata. La lasta etapo videblas nur ĉe la kliento, kie la rikordo aŭ raportas konektite aŭ nomas la PPP-eraron.

Kiam unu gastiganto devas fari ambaŭ taskojn, elektu la posedanton de 443 konscie kaj skribu la elekton, ĉar alie la sekva persono, kiu ŝaltos funkcion, retrovos ĉi tiun kolizion. Disigi la rolojn restas la pli pura respondo: publika reta servilo kaj fora alira finpunkto portas apartajn ciklojn de flikaĵoj, atestiloj kaj restartoj, kaj tiuj cikloj renkontiĝas laŭ sia propra horaro. Ĉiel ajn, lasu la aŭskultan kontrolon, la registran vojon kaj la elektitan pordon en la transdona noto.