SSTP a pris le port 443 : pourquoi Apache ne démarre pas

Apache cesse de répondre sur le 443 l’après-midi où quelqu’un active les connexions VPN entrantes, et son journal d’erreurs accuse le bind plutôt que la réservation qui se trouve derrière. Windows Routing and Remote Access active SSTP à ce moment-là, et l’écouteur SSTP revendique le TCP 443 via la pile HTTP avant qu’aucun client ne s’authentifie. La revendication tient même lorsque le certificat manque, que le nom est faux ou que chaque handshake est rejeté, si bien qu’un VPN auquel personne ne peut se connecter occupe toujours le port. Lisez d’abord la table d’écoute ; le PID qui possède le 443 décide laquelle des correctifs ci-dessous vous est seulement ouverte.

La réservation survit à un certificat cassé

SSTP enveloppe PPP dans une session TLS, c’est pourquoi il a besoin du 443 et pourquoi il traverse les proxys qui abandonnent les autres tunnels. L’écouteur n’est pas un socket que le service VPN ouvre pour lui-même : SstpSvc l’enregistre auprès du pilote HTTP du noyau, si bien que le port reste réservé tant que le service tourne. Cet enregistrement ne consulte jamais le certificat, ce qui signifie qu’un nom expiré, un subject incohérent ou aucun certificat du tout laissent le 443 occupé. Les échecs se divisent alors en deux directions : les handshakes rejetés atterrissent dans le journal System sous RasSstp, tandis que le serveur web ne peut que signaler qu’il n’a pas pu se lier.

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

La première ligne renvoie le PID propriétaire ; la seconde nomme le service derrière lui, et la réponse est généralement le service HTTP ou la pile RRAS. Quand tasklist répond par un processus hôte partagé, lisez la colonne du service plutôt que de deviner d’après le nom du processus.

Les avertissements RasSstp ne valent la lecture qu’après cela, car ils décrivent un handshake qui a échoué et ne disent rien de la réservation qui a causé la collision. Un point de terminaison VPN qui rejette chaque client possède toujours le port. Traitez le journal comme la seconde question, pas la première.

IIS partage le pilote, Apache ouvre un socket

IIS confie ses bindings au même pilote de noyau que SSTP, et ce pilote démultiplexe les connexions entrantes par nom d’hôte et préfixe d’URL, si bien qu’on peut demander aux deux services de vouloir le 443 sans que l’un d’eux échoue. Apache et nginx font l’inverse : ils appellent bind sur leur propre socket, et le système d’exploitation refuse parce que l’adresse est déjà prise. Rien n’est faux dans l’une ou l’autre configuration ; la différence tient à quelle API possède le port. C’est aussi pourquoi activer le VPN fait tomber un site sur un hôte et laisse intact un site identique sur un autre.

Cette asymétrie décide de la forme de la réparation. Si IIS est déjà la porte d’entrée, la collision devient une question de préfixes, de bindings et de certificats. Si Apache est la porte d’entrée, soit il quitte le 443, soit l’écouteur SSTP le fait, et la section suivante couvre les deux mouvements.

Choisissez quel service garde le 443

Le port de l’écouteur vit dans une seule valeur de registre, un DWORD décimal sous la clé de paramètres de Sstpsvc. Changez la valeur, redémarrez Routing and Remote Access et confirmez à partir de la table d’écoute que l’ancien port 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

Choisissez un port que rien d’autre sur l’hôte ne veut, et saisissez-le en décimal : reg add stocke le DWORD exactement comme il est écrit, si bien qu’une valeur pensée en hexadécimal se retrouve comme un autre port. Si la requête dit que la valeur n’existe pas, la seconde ligne la crée. Restart-Service RemoteAccess déconnecte tous ceux qui sont connectés, ce qui mérite d’être planifié. Relancez ensuite la vérification d’écoute, car une entrée périmée sur le 443 signifie que le service a conservé son ancien enregistrement.

Déplacer l’écouteur a un prix que la modification du registre ne montre pas. Les clients SSTP ordinaires composent le 443, donc chaque profil client a besoin du nouveau port, et le flux cesse de ressembler à une requête web pour tout ce qui inspecte le chemin. Sur un réseau qui ne tolère que le trafic qui ressemble à HTTPS, cela supprime l’essentiel de la raison pour laquelle SSTP a été choisi. Une petite population de clients gérée l’absorbe ; une base d’utilisateurs publique ou BYOD non.

L’autre mouvement garde le 443 avec IIS et traite Apache comme un backend vers lequel le proxy transfère. Il préserve la valeur par défaut de SSTP et laisse un seul propriétaire pour le port, au prix d’en-têtes transférés, d’une adresse client que l’application ne voit plus directement et d’un backend qui doit parler le protocole que le proxy envoie réellement.

Prouvez le propriétaire, le certificat et le handshake dans l’ordre

Une connexion TCP terminée prouve qu’un écouteur existe et rien de plus, c’est pourquoi un scan de ports peut sembler sain alors que le tunnel échoue encore. Les quatre étapes échouent de manières différentes, et une réparation visant l’étape que vous n’avez pas cassée approfondit généralement la collision. Traitez-les dans l’ordre et arrêtez-vous là où la réponse diverge.

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

La première ligne nomme le PID qui détient le 443, et ce devrait être le service que vous venez de configurer. La seconde liste les certificats machine avec leurs subjects, si bien qu’un nom qui ne correspond pas à l’adresse du profil client ressort tout de suite. La requête d’événements renvoie les enregistrements SSTP récents, et un handshake qui n’atteint jamais l’authentification PPP laisse un enregistrement différent de celui qui s’authentifie puis est refusé. La dernière étape n’est visible que sur le client, où l’entrée signale soit connecté, soit le nom de l’erreur PPP.

Quand un seul hôte doit faire les deux tâches, choisissez le propriétaire du 443 délibérément et écrivez le choix, car la personne suivante qui active une fonctionnalité redécouvrira sinon cette collision. Séparer les rôles reste la réponse la plus propre : un serveur web public et un point de terminaison d’accès distant portent des cycles distincts de correctifs, de certificats et de redémarrages, et ces cycles se rencontrent selon leur propre calendrier. Dans tous les cas, laissez la vérification d’écoute, le chemin de registre et le port choisi dans la note de passation.