SSTP tomou a porta 443: por que o Apache não inicia

O Apache deixa de responder na 443 na tarde em que alguém ativa as conexões VPN de entrada, e o log de erros culpa o bind em vez da reserva por trás dele. O Windows Routing and Remote Access ativa o SSTP naquele momento, e o listener SSTP reivindica a TCP 443 pela pilha HTTP antes de qualquer cliente se autenticar. A reivindicação continua valendo mesmo quando falta o certificado, o nome está errado ou cada handshake é recusado, então uma VPN na qual ninguém consegue entrar continua ocupando a porta. Leia primeiro a tabela de escuta; o PID que possui a 443 decide qual das correções abaixo está sequer aberta para você.

A reserva sobrevive a um certificado quebrado

O SSTP encapsula PPP numa sessão TLS, por isso precisa da 443 e por isso atravessa proxies que descartam outros túneis. O listener não é um socket que o serviço VPN abre para si mesmo: o SstpSvc o registra no driver HTTP do núcleo, de modo que a porta fica reservada enquanto o serviço estiver em execução. Esse registro nunca consulta o certificado, o que significa que um nome vencido, um subject incompatível ou nenhum certificado deixam a 443 ocupada. As falhas então se dividem em duas direções: handshakes recusados caem no log System sob RasSstp, enquanto o servidor web só pode informar que não conseguiu fazer o bind.

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

A primeira linha devolve o PID proprietário; a segunda nomeia o serviço por trás dele, e a resposta costuma ser o serviço HTTP ou a pilha RRAS. Quando tasklist responde com um processo de host compartilhado, leia a coluna de serviço em vez de adivinhar pelo nome do processo.

Os avisos do RasSstp só valem a leitura depois disso, porque descrevem um handshake que falhou e não dizem nada sobre a reserva que causou a colisão. Um endpoint VPN que recusa todos os clientes ainda possui a porta. Trate o log como a segunda pergunta, não a primeira.

O IIS compartilha o driver, o Apache abre um socket

O IIS entrega os seus bindings ao mesmo driver do núcleo que o SSTP usa, e esse driver separa as conexões de entrada por nome de host e prefixo de URL, então ambos os serviços podem ser instruídos a querer a 443 sem que nenhum falhe. O Apache e o nginx fazem o contrário: chamam bind no próprio socket, e o sistema operacional recusa porque o endereço já está ocupado. Nada em nenhuma das configurações está errado; a diferença está em qual API possui a porta. É também por isso que ativar a VPN derruba um site num host e deixa intacto um site idêntico em outro.

Essa assimetria decide a forma do reparo. Se o IIS já é a porta de entrada, a colisão passa a ser uma questão de prefixos, bindings e certificados. Se o Apache é a porta de entrada, ou ele sai da 443 ou o listener SSTP sai, e a seção seguinte cobre os dois movimentos.

Escolha qual serviço fica com a 443

A porta do listener vive num único valor de registro, um DWORD decimal sob a chave de parâmetros do Sstpsvc. Altere o valor, reinicie o Routing and Remote Access e confirme pela tabela de escuta que a porta antiga está livre.

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

Escolha uma porta que nada mais no host queira, e digite-a em decimal: reg add guarda o DWORD exatamente como foi escrito, então um valor pensado como hexadecimal acaba como outra porta. Se a consulta disser que o valor não existe, a segunda linha o cria. Restart-Service RemoteAccess derruba todos os que estão conectados, o que vale a pena programar. Rode a verificação de escuta de novo depois, porque uma entrada obsoleta na 443 significa que o serviço manteve o registro antigo.

Mover o listener tem um preço que a edição do registro não mostra. Clientes SSTP comuns discam a 443, então todo perfil de cliente precisa da nova porta, e o fluxo deixa de parecer uma requisição web para qualquer coisa que inspecione o caminho. Numa rede que só tolera tráfego que parece HTTPS, isso remove a maior parte do motivo pelo qual o SSTP foi escolhido. Uma população de clientes pequena e gerenciada absorve isso; uma base de usuários pública ou BYOD não.

O outro movimento mantém a 443 no IIS e trata o Apache como um backend para o qual o proxy encaminha. Preserva o padrão do SSTP e deixa um único proprietário para a porta, ao custo de cabeçalhos encaminhados, um endereço de cliente que a aplicação já não vê diretamente e um backend que precisa falar o protocolo que o proxy realmente envia.

Comprove o proprietário, o certificado e o handshake na ordem

Uma conexão TCP concluída prova que existe um listener e nada mais, por isso uma varredura de portas pode parecer saudável enquanto o túnel continua falhando. As quatro etapas falham de maneiras diferentes, e um reparo voltado para a etapa que você não quebrou geralmente aprofunda a colisão. Trabalhe-as em ordem e pare onde a resposta divergir.

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

A primeira linha nomeia o PID que detém a 443, e ele deve ser o serviço que você acabou de configurar. A segunda lista os certificados de máquina com os seus subjects, então um nome que não bate com o endereço no perfil do cliente salta à vista de imediato. A consulta de eventos devolve registros SSTP recentes, e um handshake que nunca chega à autenticação PPP deixa um registro diferente daquele que se autentica e depois é recusado. A última etapa só é visível no cliente, onde a entrada relata conectado ou nomeia o erro PPP.

Quando um único host precisa fazer os dois trabalhos, escolha o proprietário da 443 de forma deliberada e escreva a escolha, porque de outro modo a próxima pessoa que ativar um recurso redescobrirá esta colisão. Separar os papéis continua sendo a resposta mais limpa: um servidor web público e um endpoint de acesso remoto carregam ciclos separados de patches, certificados e reinicializações, e esses ciclos se encontram conforme o próprio calendário. De qualquer forma, deixe a verificação de escuta, o caminho de registro e a porta escolhida na nota de passagem.