SSTP mengambil port 443: mengapa Apache tidak mau menyala

Apache berhenti menjawab di 443 pada sore ketika seseorang mengaktifkan koneksi VPN masuk, dan log galatnya menyalahkan bind alih-alih reservasi di baliknya. Windows Routing and Remote Access menyalakan SSTP pada saat itu, dan listener SSTP mengklaim TCP 443 lewat tumpukan HTTP sebelum ada klien yang diautentikasi. Klaim itu tetap berlaku bahkan ketika sertifikatnya hilang, namanya salah, atau setiap handshake ditolak, jadi VPN yang tidak bisa dimasuki siapa pun tetap menempati port itu. Baca dulu tabel mendengarkan; PID yang memegang 443 menentukan perbaikan mana di bawah ini yang bahkan terbuka untuk Anda.

Reservasi bertahan lebih lama daripada sertifikat rusak

SSTP membungkus PPP di dalam sesi TLS, itulah sebabnya ia butuh 443 dan itulah sebabnya ia melewati proxy yang membuang terowongan lain. Listener bukan socket yang dibuka layanan VPN untuk dirinya sendiri: SstpSvc mendaftarkannya ke driver HTTP kernel, sehingga port tetap dipesan selama layanan itu berjalan. Pendaftaran itu tidak pernah menanyakan sertifikat, artinya nama yang kedaluwarsa, subject yang tidak cocok, atau tidak ada sertifikat sama sekali tetap meninggalkan 443 terpakai. Kegagalan lalu terbelah dua arah: handshake yang ditolak masuk ke log System di bawah RasSstp, sementara server web hanya bisa melaporkan bahwa ia tidak bisa melakukan bind.

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

Baris pertama mengembalikan PID pemiliknya; baris kedua menyebut layanan di belakangnya, dan jawabannya biasanya layanan HTTP atau tumpukan RRAS. Ketika tasklist menjawab dengan proses host bersama, baca kolom layanan alih-alih menebak dari nama proses.

Peringatan RasSstp layak dibaca hanya setelah itu, karena peringatan itu menjelaskan handshake yang gagal dan tidak mengatakan apa pun tentang reservasi yang menyebabkan bentrokan. Titik akhir VPN yang menolak setiap klien tetap memiliki port itu. Perlakukan log sebagai pertanyaan kedua, bukan yang pertama.

IIS berbagi driver, Apache membuka socket

IIS menyerahkan bindings-nya kepada driver kernel yang sama yang dipakai SSTP, dan driver itu memisahkan koneksi masuk berdasarkan nama host dan prefiks URL, sehingga kedua layanan bisa diminta menginginkan 443 tanpa salah satunya gagal. Apache dan nginx melakukan sebaliknya: mereka memanggil bind pada socket mereka sendiri, dan sistem operasi menolak karena alamatnya sudah terpakai. Tidak ada yang salah pada kedua konfigurasi itu; bedanya terletak pada API mana yang memiliki port. Itu juga sebabnya mengaktifkan VPN menjatuhkan satu situs di satu host dan membiarkan situs yang identik di host lain tanpa terganggu.

Asimetri ini menentukan bentuk perbaikannya. Jika IIS sudah menjadi pintu depan, bentrokan menjadi soal prefiks, bindings, dan sertifikat. Jika Apache yang menjadi pintu depan, entah ia pindah dari 443 atau listener SSTP yang pindah, dan bagian berikutnya mencakup kedua langkah itu.

Pilih layanan mana yang tetap memegang 443

Port listener hidup dalam satu nilai registri, DWORD desimal di bawah kunci parameter Sstpsvc. Ubah nilainya, jalankan ulang Routing and Remote Access, dan pastikan dari tabel mendengarkan bahwa 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 tidak diinginkan hal lain di host, dan ketik dalam desimal: reg add menyimpan DWORD persis seperti yang ditulis, jadi nilai yang dimaksudkan sebagai heksadesimal mendarat sebagai port lain. Jika kueri mengatakan nilainya tidak ada, baris kedua membuatnya. Restart-Service RemoteAccess memutus semua yang terhubung, yang layak dijadwalkan. Jalankan lagi pemeriksaan mendengarkan sesudahnya, karena entri basi di 443 berarti layanan mempertahankan pendaftaran lamanya.

Memindahkan listener punya harga yang tidak ditunjukkan oleh penyuntingan registri. Klien SSTP biasa memanggil 443, jadi setiap profil klien perlu port baru, dan alirannya berhenti menyerupai permintaan web bagi apa pun yang memeriksa jalurnya. Di jaringan yang hanya menoleransi lalu lintas yang tampak seperti HTTPS, itu menghapus sebagian besar alasan SSTP dipilih. Populasi klien kecil yang terkelola menyerapnya; basis pengguna publik atau BYOD tidak.

Langkah lain mempertahankan 443 pada IIS dan memperlakukan Apache sebagai backend tempat proxy meneruskan. Ini mempertahankan bawaan SSTP dan menyisakan satu pemilik untuk port itu, dengan biaya header yang diteruskan, alamat klien yang tidak lagi dilihat aplikasi secara langsung, dan backend yang harus berbicara protokol yang benar-benar dikirim proxy.

Buktikan pemilik, sertifikat, dan handshake secara berurutan

Koneksi TCP yang selesai membuktikan bahwa ada listener dan bukan apa-apa lagi, itulah sebabnya pemindaian port bisa tampak sehat sementara terowongan tetap gagal. Keempat tahap gagal dengan cara berbeda, dan perbaikan yang diarahkan ke tahap yang tidak Anda rusak biasanya memperdalam bentrokan. Kerjakan berurutan dan berhentilah di titik jawabannya bercabang.

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

Baris pertama menyebut PID yang memegang 443, dan seharusnya layanan yang baru Anda konfigurasi. Baris kedua mendaftar sertifikat mesin beserta subject-nya, sehingga nama yang tidak cocok dengan alamat di profil klien langsung menonjol. Kueri peristiwa mengembalikan catatan SSTP terbaru, dan handshake yang tidak pernah mencapai autentikasi PPP meninggalkan catatan berbeda dari yang terautentikasi lalu ditolak. Tahap terakhir hanya terlihat di klien, tempat entri itu melaporkan tersambung atau menyebut galat PPP.

Ketika satu host harus melakukan kedua pekerjaan, pilih pemilik 443 dengan sengaja dan tuliskan pilihannya, karena kalau tidak, orang berikutnya yang mengaktifkan fitur akan menemukan kembali bentrokan ini. Memisahkan peran tetap menjadi jawaban yang lebih bersih: server web publik dan titik akhir akses jarak jauh membawa siklus tambalan, sertifikat, dan mulai ulang yang terpisah, dan siklus itu bertemu menurut jadwalnya sendiri. Apa pun pilihannya, tinggalkan pemeriksaan mendengarkan, jalur registri, dan port yang dipilih di catatan serah terima.