Apache AllowCONNECT und HTTPS-Zielports

Ihr Apache-Proxy lauscht auf Port 3128. Ein Client erreicht ihn erfolgreich, aber ein HTTPS-Dienst auf Port 8443 schlägt fehl. Eine Änderung des Lauschports des Proxys wird diese spezielle Unterscheidung wahrscheinlich nicht beheben.

Der Client verbindet sich zuerst mit dem Proxy-Listener. Seine CONNECT-Anfrage nennt dann einen separaten Zielhost und -port. Apache kann die erste Verbindung annehmen und die zweite Operation ablehnen.

AllowCONNECT als Zielrichtlinie lesen

Für Apache 2.4 verarbeitet mod_proxy_connect eingehende CONNECT-Anfragen. Seine Direktive AllowCONNECT steuert die Zielports, die für diese Anfragen verfügbar sind. Der dokumentierte Standard ist 443 und 563.

AllowCONNECT 443 8443

Dieses Beispiel wählt diese beiden Zielports. Es ersetzt die Standardauswahl; es fügt nicht 8443 hinzu und behält dabei stillschweigend jeden Standardport. Verwenden Sie die Direktive in der zutreffenden Server- oder Virtual-Host-Konfiguration.

Belassen Sie die Client-Autorisierungsregeln des Proxys an ihrem Platz. Ein erlaubter Zielport sagt nichts darüber aus, welcher Client den Dienst nutzen darf, und ersetzt keine Zielhost-Beschränkung, wenn eine benötigt wird.

Ein Reverse-Proxy-Beispiel beantwortet eine andere Frage

Suchergebnisse zu Apache und HTTPS zeigen häufig eine öffentliche Website, die an ein festes Backend weiterleitet. Diese Konfiguration entspricht nicht der Art, wie ein Browser einen Forward-Proxy bittet, einen CONNECT-Tunnel zu einer ausgewählten Website zu öffnen. Das Kopieren ihrer Routing-Direktiven kann das ursprüngliche Proxyproblem unberührt lassen.

Wenn Sie einen Fehler diagnostizieren, halten Sie den erreichten Listener, die angeforderte CONNECT-Authority und die Antwort des Proxys fest. Wenn CONNECT gelingt und TLS danach fehlschlägt, hat die Zielport-Berechtigung ihren Teil bereits erledigt. Fahren Sie mit dem TLS-Fehler fort, statt AllowCONNECT wiederholt zu erweitern.