SSTP tomó el puerto 443: por qué Apache no arranca

Apache deja de responder en el 443 la tarde en que alguien habilita las conexiones VPN entrantes, y su registro de errores culpa al bind en lugar de a la reserva que hay detrás. Windows Routing and Remote Access activa SSTP en ese momento, y el listener de SSTP reclama el TCP 443 a través de la pila HTTP antes de que se autentique ningún cliente. La reclamación se mantiene incluso cuando falta el certificado, el nombre es incorrecto o se rechaza cada handshake, así que una VPN en la que nadie puede entrar sigue ocupando el puerto. Lea primero la tabla de escucha; el PID que posee el 443 decide cuál de las soluciones siguientes está siquiera abierta para usted.

La reserva sobrevive a un certificado roto

SSTP envuelve PPP dentro de una sesión TLS, por eso necesita el 443 y por eso atraviesa proxies que descartan otros túneles. El listener no es un socket que el servicio VPN abra para sí mismo: SstpSvc lo registra en el controlador HTTP del núcleo, de modo que el puerto queda reservado mientras el servicio se ejecute. Ese registro nunca consulta el certificado, lo que significa que un nombre caducado, un subject que no coincide o ningún certificado dejan el 443 ocupado. Los fallos se dividen entonces en dos direcciones: los handshakes rechazados van al registro System bajo RasSstp, mientras que el servidor web solo puede informar de que no pudo enlazar.

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

La primera línea devuelve el PID propietario; la segunda nombra el servicio que hay detrás, y la respuesta suele ser el servicio HTTP o la pila RRAS. Cuando tasklist responde con un proceso de host compartido, lea la columna de servicio en lugar de adivinar por el nombre del proceso.

Las advertencias de RasSstp solo merecen leerse después de eso, porque describen un handshake que falló y no dicen nada de la reserva que causó la colisión. Un extremo VPN que rechaza a todos los clientes sigue poseyendo el puerto. Trate el registro como la segunda pregunta, no la primera.

IIS comparte el controlador, Apache abre un socket

IIS entrega sus bindings al mismo controlador del núcleo que usa SSTP, y ese controlador demultiplexa las conexiones entrantes por nombre de host y prefijo de URL, de modo que a ambos servicios se les puede pedir que quieran el 443 sin que ninguno falle. Apache y nginx hacen lo contrario: llaman a bind sobre su propio socket, y el sistema operativo lo rechaza porque la dirección ya está ocupada. Nada en ninguna de las dos configuraciones está mal; la diferencia está en qué API posee el puerto. Eso es también por lo que habilitar la VPN derriba un sitio en un host y deja intacto un sitio idéntico en otro.

Esta asimetría decide la forma de la reparación. Si IIS ya es la puerta de entrada, la colisión pasa a ser una cuestión de prefijos, bindings y certificados. Si Apache es la puerta de entrada, o se mueve del 443 o lo hace el listener de SSTP, y la sección siguiente cubre ambos movimientos.

Elija qué servicio se queda con el 443

El puerto del listener vive en un único valor del registro, un DWORD decimal bajo la clave de parámetros de Sstpsvc. Cambie el valor, reinicie Routing and Remote Access y confirme en la tabla de escucha que el puerto antiguo está libre.

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

Elija un puerto que nada más en el host quiera, y escríbalo en decimal: reg add guarda el DWORD exactamente como se escribe, así que un valor pensado como hexadecimal acaba como un puerto distinto. Si la consulta dice que el valor no existe, la segunda línea lo crea. Restart-Service RemoteAccess expulsa a todos los que están conectados, lo que merece programarse. Vuelva a ejecutar la comprobación de escucha después, porque una entrada obsoleta en el 443 significa que el servicio conservó su registro antiguo.

Mover el listener tiene un precio que la edición del registro no muestra. Los clientes SSTP corrientes marcan el 443, así que cada perfil de cliente necesita el puerto nuevo, y el flujo deja de parecer una petición web para cualquier cosa que inspeccione la ruta. En una red que solo tolera tráfico que parece HTTPS, eso elimina la mayor parte del motivo por el que se eligió SSTP. Una población de clientes pequeña y gestionada lo absorbe; una base de usuarios pública o BYOD no.

El otro movimiento conserva el 443 en IIS y trata Apache como un backend al que el proxy reenvía. Preserva el valor predeterminado de SSTP y deja un solo propietario para el puerto, a costa de cabeceras reenviadas, una dirección de cliente que la aplicación ya no ve directamente y un backend que debe hablar el protocolo que el proxy envía realmente.

Demuestre el propietario, el certificado y el handshake en orden

Una conexión TCP completada demuestra que existe un listener y nada más, por eso un escaneo de puertos puede parecer sano mientras el túnel sigue fallando. Las cuatro etapas fallan de maneras distintas, y una reparación dirigida a la etapa que no rompió suele profundizar la colisión. Trabájelas en orden y deténgase donde la respuesta diverja.

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

La primera línea nombra el PID que tiene el 443, y debería ser el servicio que acaba de configurar. La segunda lista los certificados de máquina con sus subjects, así que un nombre que no coincide con la dirección del perfil del cliente destaca de inmediato. La consulta de eventos devuelve registros SSTP recientes, y un handshake que nunca llega a la autenticación PPP deja un registro distinto del que se autentica y luego se rechaza. La última etapa solo es visible en el cliente, donde la entrada o bien informa de conectado o bien nombra el error PPP.

Cuando un solo host debe hacer los dos trabajos, elija el propietario del 443 deliberadamente y escriba la elección, porque de lo contrario la siguiente persona que habilite una función volverá a descubrir esta colisión. Separar los roles sigue siendo la respuesta más limpia: un servidor web público y un extremo de acceso remoto llevan ciclos separados de parches, certificados y reinicios, y esos ciclos se encuentran según su propio calendario. En cualquier caso, deje la comprobación de escucha, la ruta del registro y el puerto elegido en la nota de traspaso.