SSTP mengambil port 443: mengapa Apache tidak mahu bermula

Apache berhenti menjawab pada 443 petang itu apabila seseorang mengaktifkan sambungan VPN masuk, dan log ralatnya menyalahkan bind dan bukan tempahan di belakangnya. Windows Routing and Remote Access menghidupkan SSTP pada saat itu, dan pendengar SSTP menuntut TCP 443 melalui tindanan HTTP sebelum mana-mana klien disahkan. Tuntutan itu kekal walaupun sijil tiada, nama salah atau setiap handshake ditolak, jadi VPN yang tiada siapa boleh masuk masih menduduki port itu. Baca jadual mendengar dahulu; PID yang memiliki 443 menentukan pembaikan mana di bawah ini yang terbuka kepada anda.

Tempahan itu hidup lebih lama daripada sijil yang rosak

SSTP membalut PPP di dalam sesi TLS, sebab itulah ia memerlukan 443 dan sebab itulah ia melalui proksi yang menggugurkan terowong lain. Pendengar bukan soket yang dibuka oleh perkhidmatan VPN untuk dirinya sendiri: SstpSvc mendaftarkannya dengan pemacu HTTP kernel, jadi port itu kekal ditempah selagi perkhidmatan berjalan. Pendaftaran itu tidak pernah merujuk sijil, bermakna nama yang luput, subject yang tidak sepadan atau tiada sijil langsung meninggalkan 443 diduduki. Kegagalan kemudian berpecah dua arah: handshake yang ditolak masuk ke log System di bawah RasSstp, manakala pelayan web hanya boleh melaporkan bahawa ia tidak dapat melakukan bind.

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

Baris pertama mengembalikan PID pemilik; baris kedua menamakan perkhidmatan di belakangnya, dan jawapannya biasanya perkhidmatan HTTP atau tindanan RRAS. Apabila tasklist menjawab dengan proses hos dikongsi, baca lajur perkhidmatan dan jangan meneka daripada nama proses.

Amaran RasSstp hanya bernilai dibaca selepas itu, kerana ia menerangkan handshake yang gagal dan tidak berkata apa-apa tentang tempahan yang menyebabkan pertembungan. Titik akhir VPN yang menolak setiap klien masih memiliki port itu. Anggap log itu soalan kedua, bukan yang pertama.

IIS berkongsi pemacu, Apache membuka soket

IIS menyerahkan bindings-nya kepada pemacu kernel yang sama yang digunakan SSTP, dan pemacu itu mengasingkan sambungan masuk mengikut nama hos dan awalan URL, jadi kedua-dua perkhidmatan boleh diminta mahukan 443 tanpa mana-mana daripadanya gagal. Apache dan nginx melakukan sebaliknya: mereka memanggil bind pada soket mereka sendiri, dan sistem pengendalian menolak kerana alamat itu sudah diduduki. Tiada apa yang salah dalam mana-mana konfigurasi; perbezaannya terletak pada API mana yang memiliki port itu. Itulah sebabnya mengaktifkan VPN menjatuhkan satu laman pada satu hos dan membiarkan laman yang serupa pada hos lain tidak terganggu.

Asimetri ini menentukan bentuk pembaikan. Jika IIS sudah menjadi pintu depan, pertembungan menjadi persoalan awalan, bindings dan sijil. Jika Apache pintu depan, sama ada ia beralih daripada 443 atau pendengar SSTP yang beralih, dan bahagian seterusnya merangkumi kedua-dua langkah.

Pilih perkhidmatan mana yang menyimpan 443

Port pendengar tinggal dalam satu nilai registri, DWORD perpuluhan di bawah kunci parameter Sstpsvc. Tukar nilai itu, mulakan semula Routing and Remote Access, dan sahkan daripada jadual mendengar bahawa port lama sudah bebas.

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

Pilih port yang tiada apa-apa lain pada hos mahukan, dan taip dalam perpuluhan: reg add menyimpan DWORD itu tepat seperti yang ditulis, jadi nilai yang dimaksudkan sebagai perenambelasan mendarat sebagai port lain. Jika pertanyaan mengatakan nilai itu tiada, baris kedua menciptanya. Restart-Service RemoteAccess memutuskan semua yang bersambung, yang wajar dirancang. Jalankan semula pemeriksaan mendengar selepas itu, kerana entri lama pada 443 bermakna perkhidmatan mengekalkan pendaftaran lamanya.

Mengalihkan pendengar mempunyai harga yang tidak ditunjukkan oleh suntingan registri. Klien SSTP biasa mendail 443, jadi setiap profil klien memerlukan port baharu, dan aliran berhenti menyerupai permintaan web kepada apa-apa yang memeriksa laluan. Pada rangkaian yang hanya bertolak ansur dengan trafik yang kelihatan seperti HTTPS, itu menghapuskan sebahagian besar sebab SSTP dipilih. Populasi klien kecil yang diurus menyerapnya; asas pengguna awam atau BYOD tidak.

Langkah lain mengekalkan 443 pada IIS dan menganggap Apache sebagai backend yang proksi teruskan. Ia mengekalkan lalai SSTP dan meninggalkan satu pemilik untuk port itu, dengan kos pengepala yang diteruskan, alamat klien yang tidak lagi dilihat aplikasi secara langsung, dan backend yang mesti bercakap protokol yang benar-benar dihantar oleh proksi.

Buktikan pemilik, sijil dan handshake mengikut urutan

Sambungan TCP yang selesai membuktikan bahawa pendengar wujud dan bukan apa-apa lagi, sebab itulah imbasan port boleh kelihatan sihat sedangkan terowong masih gagal. Empat peringkat gagal dengan cara berbeza, dan pembaikan yang ditujukan kepada peringkat yang anda tidak pecahkan biasanya mendalamkan pertembungan. Lakukan mengikut urutan dan berhenti di tempat jawapan itu berbeza.

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

Baris pertama menamakan PID yang memegang 443, dan ia sepatutnya perkhidmatan yang baru anda konfigurasikan. Baris kedua menyenaraikan sijil mesin dengan subjects mereka, jadi nama yang tidak sepadan dengan alamat dalam profil klien terus menonjol. Pertanyaan peristiwa mengembalikan rekod SSTP terkini, dan handshake yang tidak pernah sampai ke pengesahan PPP meninggalkan rekod berbeza daripada yang disahkan dan kemudian ditolak. Peringkat terakhir hanya kelihatan pada klien, di mana entri itu melaporkan bersambung atau menamakan ralat PPP.

Apabila satu hos perlu melakukan kedua-dua tugas, pilih pemilik 443 secara sedar dan tuliskan pilihan itu, kerana jika tidak orang seterusnya yang mengaktifkan sesuatu ciri akan menemui semula pertembungan ini. Memisahkan peranan kekal sebagai jawapan yang lebih bersih: pelayan web awam dan titik akhir akses jauh membawa kitaran tampalan, sijil dan permulaan semula yang berasingan, dan kitaran itu bertemu mengikut jadual mereka sendiri. Apa pun pilihannya, tinggalkan pemeriksaan mendengar, laluan registri dan port yang dipilih dalam nota penyerahan.