SSTP 443 portunu aldı: Apache neden başlamıyor

Apache, birinin gelen VPN bağlantılarını etkinleştirdiği o öğleden sonra 443’te yanıt vermeyi bırakır ve hata günlüğü arkasındaki ayırmayı değil bind’ı suçlar. Windows Routing and Remote Access o anda SSTP’yi etkinleştirir ve SSTP dinleyicisi herhangi bir istemci kimlik doğrulamasından önce HTTP yığını üzerinden TCP 443’ü talep eder. Sertifika eksik olsa, ad yanlış olsa ya da her handshake reddedilse bile talep geçerliliğini korur, bu yüzden kimsenin giremediği bir VPN bile portu işgal etmeye devam eder. Önce dinleme tablosunu okuyun; 443’e sahip PID, aşağıdaki düzeltmelerden hangisinin sizin için açık olduğunu belirler.

Ayırma bozuk bir sertifikadan daha uzun yaşar

SSTP, PPP’yi bir TLS oturumuna sarar, bu yüzden 443’e ihtiyaç duyar ve bu yüzden diğer tünelleri düşüren proxy’lerden geçer. Dinleyici, VPN hizmetinin kendisi için açtığı bir socket değildir: SstpSvc onu çekirdeğin HTTP sürücüsüne kaydeder, böylece hizmet çalıştığı sürece port ayrılmış kalır. Bu kayıt sertifikaya hiç danışmaz, yani süresi dolmuş bir ad, uyuşmayan bir subject ya da hiç sertifika olmaması 443’ü dolu bırakır. Hatalar sonra iki yöne ayrılır: reddedilen handshake’ler RasSstp altında System günlüğüne düşer, web sunucusu ise yalnızca bind yapamadığını bildirebilir.

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

İlk satır sahip PID’yi döndürür; ikincisi arkasındaki hizmeti adlandırır ve yanıt genellikle HTTP hizmeti ya da RRAS yığınıdır. Ne zaman tasklist paylaşılan bir ana bilgisayar süreciyle yanıt verirse, süreç adından tahmin etmek yerine hizmet sütununu okuyun.

RasSstp uyarılarını ancak ondan sonra okumaya değer, çünkü başarısız bir handshake’i anlatırlar ve çakışmaya yol açan ayırma hakkında hiçbir şey söylemezler. Her istemciyi reddeden bir VPN uç noktası portu yine de elinde tutar. Günlüğü ilk değil ikinci soru olarak ele alın.

IIS sürücüyü paylaşır, Apache bir socket açar

IIS, bindings’lerini SSTP’nin kullandığı aynı çekirdek sürücüsüne verir ve o sürücü gelen bağlantıları ana bilgisayar adına ve URL önekine göre ayırır, böylece her iki hizmetten de 443’ü istemeleri istenebilir ve hiçbiri başarısız olmaz. Apache ve nginx tersini yapar: kendi socket’lerinde bind çağırırlar ve adres zaten alınmış olduğu için işletim sistemi reddeder. İki yapılandırmanın hiçbirinde yanlış bir şey yoktur; fark, portun hangi API’ye ait olduğundadır: portun hangi API’ye ait olduğu. Bu yüzden VPN’i etkinleştirmek bir ana bilgisayardaki bir siteyi devirirken diğerindeki aynı siteye dokunmaz.

Bu asimetri onarımın biçimini belirler. IIS zaten ön kapıysa çakışma önekler, bindings ve sertifikalar sorununa dönüşür. Apache ön kapıysa ya o 443’ten çekilir ya da SSTP dinleyicisi çekilir ve sonraki bölüm iki hamleyi de kapsar.

443’ü hangi hizmetin tutacağını seçin

Dinleyici portu tek bir kayıt defteri değerinde yaşar, Sstpsvc parametre anahtarı altındaki ondalık bir DWORD. Değeri değiştirin, Routing and Remote Access’i yeniden başlatın ve dinleme tablosundan eski portun boş olduğunu doğrulayın.

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

Ana bilgisayarda başka hiçbir şeyin istemediği bir port seçin ve ondalık olarak yazın: reg add DWORD’ü tam yazıldığı gibi saklar, bu yüzden onaltılık olarak düşünülen bir değer başka bir port olarak düşer. Sorgu değerin olmadığını söylerse ikinci satır onu oluşturur. Restart-Service RemoteAccess bağlı olan herkesi atar, bunu planlamaya değer. Ardından dinleme denetimini yeniden çalıştırın, çünkü 443’te kalan eski bir giriş hizmetin eski kaydını koruduğu anlamına gelir.

Dinleyiciyi taşımanın, kayıt defteri değişikliğinin göstermediği bir bedeli vardır. Sıradan SSTP istemcileri 443’ü arar, bu yüzden her istemci profili yeni porta ihtiyaç duyar ve akış, yolu inceleyen her şey için web isteğine benzemeyi bırakır. Yalnızca HTTPS’e benzeyen trafiğe izin veren bir ağda bu, SSTP’nin seçilme nedeninin büyük kısmını ortadan kaldırır. Küçük ve yönetilen bir istemci kitlesi bunu kaldırır; herkese açık ya da BYOD kullanıcı tabanı kaldırmaz.

Diğer hamle 443’ü IIS’te tutar ve Apache’yi proxy’nin yönlendirdiği bir backend olarak görür. SSTP varsayılanını korur ve port için tek bir sahip bırakır; bedeli yönlendirilen başlıklar, uygulamanın artık doğrudan görmediği istemci adresi ve proxy’nin gerçekte gönderdiği protokolü konuşması gereken bir backend’dir.

Sahibi, sertifikayı ve handshake’i sırayla kanıtlayın

Tamamlanmış bir TCP bağlantısı yalnızca bir dinleyicinin var olduğunu kanıtlar, başka bir şeyi değil, bu yüzden tünel hâlâ başarısızken port taraması sağlıklı görünebilir. Dört aşama farklı biçimlerde başarısız olur ve sizin bozmadığınız aşamaya yönelen bir onarım genellikle çakışmayı derinleştirir. Bunları sırayla işleyin ve yanıtın ayrıldığı yerde durun.

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

İlk satır 443’ü tutan PID’yi adlandırır ve bu, az önce yapılandırdığınız hizmet olmalıdır. İkincisi makine sertifikalarını subject’leriyle listeler, bu yüzden istemci profilindeki adresle eşleşmeyen bir ad hemen göze çarpar. Olay sorgusu son SSTP kayıtlarını döndürür ve PPP kimlik doğrulamasına hiç ulaşmayan bir handshake, doğrulanıp sonra reddedilenden farklı bir kayıt bırakır. Son aşama yalnızca istemcide görünür; orada giriş ya bağlı olduğunu bildirir ya da PPP hatasını adlandırır.

Tek bir ana bilgisayar iki işi de yapmak zorundaysa 443’ün sahibini bilinçli olarak seçin ve seçimi yazın, çünkü aksi hâlde bir özelliği etkinleştiren sonraki kişi bu çakışmayı yeniden keşfeder. Rolleri ayırmak hâlâ daha temiz yanıttır: herkese açık bir web sunucusu ile uzaktan erişim uç noktası ayrı yama, sertifika ve yeniden başlatma döngüleri taşır ve bu döngüler kendi takvimlerine göre buluşur. Her durumda, devir notunda dinleme denetimini, kayıt defteri yolunu ve seçilen portu bırakın.