SSTP va ocupar el port 443: per què Apache no arrenca

Apache deixa de respondre al 443 la tarda que algú activa les connexions VPN entrants, i el seu registre d’errors culpa el bind en lloc de la reserva que hi ha al darrere. Windows Routing and Remote Access activa SSTP en aquell moment, i l’oient SSTP reclama el TCP 443 a través de la pila HTTP abans que cap client s’autentiqui. La reclamació es manté fins i tot quan falta el certificat, el nom és incorrecte o es rebutja cada handshake, de manera que una VPN a la qual ningú no pot entrar continua ocupant el port. Llegiu primer la taula d’escolta; el PID que posseeix el 443 decideix quina de les solucions següents us és oberta.

La reserva sobreviu a un certificat trencat

SSTP embolcalla PPP dins d’una sessió TLS, i per això necessita el 443 i per això travessa proxys que descarten altres túnels. L’oient no és un socket que el servei VPN obri per a si mateix: SstpSvc el registra al controlador HTTP del nucli, de manera que el port queda reservat mentre el servei s’executi. Aquest registre no consulta mai el certificat, cosa que significa que un nom caducat, un subject desajustat o cap certificat deixen el 443 ocupat. Les fallades es divideixen llavors en dues direccions: els handshakes rebutjats van al registre del sistema sota RasSstp, mentre que el servidor web només pot informar que no ha pogut fer el bind.

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

La primera línia retorna el PID propietari; la segona nomena el servei que hi ha al darrere, i la resposta sol ser el servei HTTP o la pila RRAS. Quan tasklist respon amb un procés amfitrió compartit, llegiu la columna de servei en lloc d’endevinar-ho pel nom del procés.

Els avisos de RasSstp només val la pena llegir-los després d’això, perquè descriuen un handshake que ha fallat i no diuen res de la reserva que va causar la col·lisió. Un extrem VPN que rebutja tots els clients continua posseint el port. Tracteu el registre com la segona pregunta, no la primera.

IIS comparteix el controlador, Apache obre un socket

IIS lliura els seus bindings al mateix controlador del nucli que fa servir SSTP, i aquest controlador demultiplexa les connexions entrants pel nom d’amfitrió i el prefix d’URL, de manera que tots dos serveis poden rebre l’ordre de voler el 443 sense que cap falli. Apache i nginx fan el contrari: criden bind sobre el seu propi socket, i el sistema operatiu ho rebutja perquè l’adreça ja està ocupada. No hi ha res incorrecte en cap de les dues configuracions; la diferència rau en quin API posseeix el port. És també per això que activar la VPN tomba un lloc en un amfitrió i deixa intacte un lloc idèntic en un altre.

Aquesta asimetria decideix la forma de la reparació. Si IIS ja és la porta d’entrada, la col·lisió es converteix en una qüestió de prefixos, bindings i certificats. Si Apache és la porta d’entrada, o bé es mou del 443 o ho fa l’oient SSTP, i la secció següent cobreix tots dos moviments.

Trieu quin servei es queda el 443

El port de l’oient viu en un sol valor del registre, un DWORD decimal sota la clau de paràmetres de Sstpsvc. Canvieu el valor, reinicieu Routing and Remote Access i confirmeu a la taula d’escolta que el port antic queda lliure.

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

Trieu un port que ningú més a l’amfitrió no vulgui i escriviu-lo en decimal: reg add desa el DWORD exactament tal com s’escriu, de manera que un valor pensat com a hexadecimal acaba com un port diferent. Si la consulta diu que el valor no existeix, la segona línia el crea. Restart-Service RemoteAccess expulsa tothom qui està connectat, cosa que val la pena programar. Torneu a executar la comprovació d’escolta després, perquè una entrada obsoleta al 443 vol dir que el servei ha conservat la seva registració antiga.

Moure l’oient té un preu que l’edició del registre no mostra. Els clients SSTP corrents marquen el 443, així que cada perfil de client necessita el port nou, i el flux deixa de semblar una petició web per a qualsevol cosa que inspeccioni el camí. En una xarxa que només tolera trànsit que sembla HTTPS, això elimina la major part del motiu pel qual es va triar SSTP. Una població de clients petita i gestionada ho absorbeix; una base d’usuaris pública o BYOD no.

L’altre moviment conserva el 443 a IIS i tracta Apache com un backend al qual el proxy reenvia. Preserva el valor per defecte d’SSTP i deixa un sol propietari per al port, a costa de capçaleres reenviades, una adreça de client que l’aplicació ja no veu directament i un backend que ha de parlar el protocol que el proxy envia realment.

Demostreu el propietari, el certificat i el handshake per ordre

Una connexió TCP completada demostra que hi ha un oient i res més, i per això un escaneig de ports pot semblar saludable mentre el túnel continua fallant. Les quatre etapes fallen de maneres diferents, i una reparació adreçada a l’etapa que no heu trencat normalment aprofundeix la col·lisió. Feu-les per ordre i atureu-vos on la resposta divergeix.

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

La primera línia nomena el PID que té el 443, i hauria de ser el servei que acabeu de configurar. La segona llista els certificats de màquina amb els seus subjects, així que un nom que no coincideix amb l’adreça del perfil del client destaca de seguida. La consulta d’esdeveniments retorna registres SSTP recents, i un handshake que no arriba mai a l’autenticació PPP deixa un registre diferent del que s’autentica i després es rebutja. L’última etapa només és visible al client, on l’entrada o bé informa de connectat o bé nomena l’error PPP.

Quan un sol amfitrió ha de fer les dues feines, trieu el propietari del 443 deliberadament i escriviu l’elecció, perquè la propera persona que activi una funció tornarà a descobrir aquesta col·lisió si no ho feu. Separar els papers continua sent la resposta més neta: un servidor web públic i un extrem d’accés remot porten cicles separats de pedaços, certificats i reinicis, i aquests cicles es troben segons el seu propi calendari. De qualsevol manera, deixeu la comprovació d’escolta, el camí del registre i el port triat a la nota de traspàs.