SSTP ha preso la porta 443: perché Apache non parte

Apache smette di rispondere sulla 443 il pomeriggio in cui qualcuno abilita le connessioni VPN in entrata, e il suo log degli errori incolpa il bind invece della prenotazione che gli sta dietro. Windows Routing and Remote Access attiva SSTP in quel momento, e il listener SSTP rivendica la TCP 443 attraverso lo stack HTTP prima che qualsiasi client si autentichi. La rivendicazione resta valida anche quando manca il certificato, il nome è sbagliato o ogni handshake viene rifiutato, così una VPN in cui nessuno riesce a entrare occupa comunque la porta. Leggete prima la tabella di ascolto; il PID che possiede la 443 decide quale dei rimedi qui sotto vi è persino aperto.

La prenotazione sopravvive a un certificato rotto

SSTP incapsula PPP in una sessione TLS, per questo ha bisogno della 443 e per questo attraversa proxy che scartano altri tunnel. Il listener non è un socket che il servizio VPN apre per sé: SstpSvc lo registra presso il driver HTTP del kernel, quindi la porta resta prenotata finché il servizio è in esecuzione. Quella registrazione non consulta mai il certificato, il che significa che un nome scaduto, un subject incoerente o nessun certificato lasciano la 443 occupata. I guasti si dividono poi in due direzioni: gli handshake rifiutati finiscono nel registro System sotto RasSstp, mentre il server web può solo segnalare che non è riuscito a fare il bind.

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

La prima riga restituisce il PID proprietario; la seconda nomina il servizio che gli sta dietro, e la risposta di solito è il servizio HTTP o lo stack RRAS. Quando tasklist risponde con un processo host condiviso, leggete la colonna del servizio invece di indovinare dal nome del processo.

Gli avvisi RasSstp vale la pena leggerli solo dopo, perché descrivono un handshake fallito e non dicono nulla della prenotazione che ha causato il conflitto. Un endpoint VPN che rifiuta ogni client possiede comunque la porta. Trattate il registro come la seconda domanda, non la prima.

IIS condivide il driver, Apache apre un socket

IIS consegna i suoi bindings allo stesso driver del kernel usato da SSTP, e quel driver demultiplexa le connessioni in entrata per nome host e prefisso URL, così si può chiedere a entrambi i servizi di volere la 443 senza che nessuno dei due fallisca. Apache e nginx fanno il contrario: chiamano bind sul proprio socket, e il sistema operativo rifiuta perché l’indirizzo è già occupato. Niente in nessuna delle due configurazioni è sbagliato; la differenza sta in quale API possiede la porta. È anche per questo che abilitare la VPN fa cadere un sito su un host e lascia intatto un sito identico su un altro.

Questa asimmetria decide la forma della riparazione. Se IIS è già la porta d’ingresso, il conflitto diventa una questione di prefissi, bindings e certificati. Se Apache è la porta d’ingresso, o si sposta dalla 443 o lo fa il listener SSTP, e la sezione successiva copre entrambi i movimenti.

Scegliete quale servizio tiene la 443

La porta del listener vive in un solo valore di registro, un DWORD decimale sotto la chiave dei parametri di Sstpsvc. Cambiate il valore, riavviate Routing and Remote Access e confermate dalla tabella di ascolto che la vecchia porta è 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

Scegliete una porta che nient’altro sull’host voglia, e digitatela in decimale: reg add memorizza il DWORD esattamente come è scritto, quindi un valore pensato come esadecimale finisce come un’altra porta. Se la query dice che il valore non esiste, la seconda riga lo crea. Restart-Service RemoteAccess butta fuori tutti quelli che sono connessi, cosa che vale la pena pianificare. Rieseguite poi il controllo di ascolto, perché una voce obsoleta sulla 443 significa che il servizio ha mantenuto la sua vecchia registrazione.

Spostare il listener ha un prezzo che la modifica al registro non mostra. I client SSTP ordinari compongono la 443, quindi ogni profilo client ha bisogno della nuova porta, e il flusso smette di somigliare a una richiesta web per qualunque cosa ispezioni il percorso. Su una rete che tollera solo traffico che sembra HTTPS, ciò toglie gran parte del motivo per cui SSTP è stato scelto. Una popolazione di client piccola e gestita lo assorbe; una base di utenti pubblica o BYOD no.

L’altro movimento tiene la 443 su IIS e tratta Apache come un backend verso cui il proxy inoltra. Preserva il valore predefinito di SSTP e lascia un solo proprietario per la porta, al costo di intestazioni inoltrate, un indirizzo client che l’applicazione non vede più direttamente e un backend che deve parlare il protocollo che il proxy invia davvero.

Dimostrate proprietario, certificato e handshake in ordine

Una connessione TCP completata dimostra che esiste un listener e nulla più, per questo una scansione delle porte può sembrare sana mentre il tunnel continua a fallire. Le quattro fasi falliscono in modi diversi, e una riparazione mirata alla fase che non avete rotto di solito approfondisce il conflitto. Affrontatele in ordine e fermatevi dove la risposta diverge.

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

La prima riga nomina il PID che tiene la 443, e dovrebbe essere il servizio che avete appena configurato. La seconda elenca i certificati macchina con i loro subjects, così un nome che non corrisponde all’indirizzo nel profilo client salta subito all’occhio. La query degli eventi restituisce i record SSTP recenti, e un handshake che non arriva mai all’autenticazione PPP lascia un record diverso da quello che si autentica e poi viene rifiutato. L’ultima fase è visibile solo sul client, dove la voce riporta connesso oppure nomina l’errore PPP.

Quando un solo host deve svolgere entrambi i compiti, scegliete deliberatamente il proprietario della 443 e scrivete la scelta, perché altrimenti la prossima persona che abilita una funzione riscoprirà questo conflitto. Separare i ruoli resta la risposta più pulita: un server web pubblico e un endpoint di accesso remoto portano cicli separati di patch, certificati e riavvii, e quei cicli si incontrano secondo il proprio calendario. In ogni caso, lasciate il controllo di ascolto, il percorso di registro e la porta scelta nella nota di passaggio.