SSTP tomou o porto 443: por que Apache non arrinca

Apache deixa de responder no 443 a tarde en que alguén activa as conexións VPN entrantes, e o seu rexistro de erros culpa o bind en lugar da reserva que hai detrás. Windows Routing and Remote Access activa SSTP nese momento, e o oínte de SSTP reclama o TCP 443 a través da pila HTTP antes de que se autentique ningún cliente. A reclamación mantense mesmo cando falta o certificado, o nome é incorrecto ou se rexeita cada handshake, así que unha VPN na que ninguén pode entrar segue ocupando o porto. Lea primeiro a táboa de escoita; o PID que posúe o 443 decide cal das solucións seguintes está sequera aberta para vostede.

A reserva sobrevive a un certificado roto

SSTP envolve PPP dentro dunha sesión TLS, por iso necesita o 443 e por iso atravesa proxies que descartan outros túneles. O oínte non é un socket que o servizo VPN abra para si mesmo: SstpSvc rexístrao no controlador HTTP do núcleo, de modo que o porto queda reservado mentres o servizo se execute. Ese rexistro nunca consulta o certificado, o que significa que un nome caducado, un subject que non coincide ou ningún certificado deixan o 443 ocupado. As fallas divídense entón en dúas direccións: os handshakes rexeitados van ao rexistro System baixo RasSstp, mentres que o servidor web só pode informar de que non puido enlazar.

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

A primeira liña devolve o PID propietario; a segunda nomea o servizo que hai detrás, e a resposta adoita ser o servizo HTTP ou a pila RRAS. Cando tasklist responde cun proceso de host compartido, lea a columna de servizo en lugar de adiviñar polo nome do proceso.

Os avisos de RasSstp só merecen lerse despois diso, porque describen un handshake que fallou e non din nada da reserva que causou a colisión. Un extremo VPN que rexeita a todos os clientes segue posuíndo o porto. Trate o rexistro como a segunda pregunta, non a primeira.

IIS comparte o controlador, Apache abre un socket

IIS entrega os seus bindings ao mesmo controlador do núcleo que usa SSTP, e ese controlador demultiplexa as conexións entrantes por nome de host e prefixo de URL, de modo que a ambos servizos se lles pode pedir que queiran o 443 sen que ningún falle. Apache e nginx fan o contrario: chaman a bind sobre o seu propio socket, e o sistema operativo rexeita porque o enderezo xa está ocupado. Nada en ningunha das dúas configuracións está mal; a diferenza está en que API posúe o porto. Iso é tamén por que activar a VPN derruba un sitio nun host e deixa intacto un sitio idéntico noutro.

Esta asimetría decide a forma da reparación. Se IIS xa é a porta de entrada, a colisión pasa a ser unha cuestión de prefixos, bindings e certificados. Se Apache é a porta de entrada, ou se move do 443 ou faino o oínte de SSTP, e a sección seguinte cobre ambos movementos.

Elixa que servizo queda co 443

O porto do oínte vive nun único valor do rexistro, un DWORD decimal baixo a clave de parámetros de Sstpsvc. Cambie o valor, reinicie Routing and Remote Access e confirme na táboa de escoita que o porto antigo 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

Elixa un porto que nada máis no host queira, e escriba o en decimal: reg add garda o DWORD exactamente como se escribe, así que un valor pensado como hexadecimal acaba como un porto distinto. Se a consulta di que o valor non existe, a segunda liña créao. Restart-Service RemoteAccess expulsa a todos os que están conectados, o que merece programarse. Volva executar a comprobación de escoita despois, porque unha entrada obsoleta no 443 significa que o servizo conservou o seu rexistro antigo.

Mover o oínte ten un prezo que a edición do rexistro non mostra. Os clientes SSTP correntes marcan o 443, así que cada perfil de cliente necesita o porto novo, e o fluxo deixa de parecer unha petición web para calquera cousa que inspeccione a ruta. Nunha rede que só tolera tráfico que parece HTTPS, iso elimina a maior parte do motivo polo que se elixiu SSTP. Unha poboación de clientes pequena e xestionada absórbeo; unha base de usuarios pública ou BYOD non.

O outro movemento conserva o 443 en IIS e trata Apache como un backend ao que o proxy reenvía. Preserva o valor predeterminado de SSTP e deixa un só propietario para o porto, a costa de cabeceiras reenviadas, un enderezo de cliente que a aplicación xa non ve directamente e un backend que debe falar o protocolo que o proxy envía realmente.

Demostre o propietario, o certificado e o handshake en orde

Unha conexión TCP completada demostra que existe un oínte e nada máis, por iso un escaneo de portos pode parecer san mentres o túnel segue fallando. As catro etapas fallan de maneiras distintas, e unha reparación dirixida á etapa que non rompeu adoita afondar a colisión. Trabálleas en orde e detéñase onde a resposta diverxe.

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

A primeira liña nomea o PID que ten o 443, e debería ser o servizo que acaba de configurar. A segunda lista os certificados de máquina cos seus subjects, así que un nome que non coincide co enderezo do perfil do cliente destaca de inmediato. A consulta de eventos devolve rexistros SSTP recentes, e un handshake que nunca chega á autenticación PPP deixa un rexistro distinto do que se autentica e logo se rexeita. A última etapa só é visible no cliente, onde a entrada ou ben informa de conectado ou ben nomea o erro PPP.

Cando un só host debe facer os dous traballos, elixa o propietario do 443 deliberadamente e escriba a elección, porque doutro xeito a seguinte persoa que active unha función volverá descubrir esta colisión. Separar os roles segue sendo a resposta máis limpa: un servidor web público e un extremo de acceso remoto levan ciclos separados de parches, certificados e reinicios, e eses ciclos atópanse segundo o seu propio calendario. En calquera caso, deixe a comprobación de escoita, a ruta do rexistro e o porto elixido na nota de traspaso.