Migrieren des Apache-Reverse-Proxys zu Squid3 mithilfe von pfSense

Migrieren des Apache-Reverse-Proxys zu Squid3 mithilfe von pfSense

Ich habe derzeit eine pfSenseFirewall, die Port 80 und 443 auf einen internen Apache umleitet, der als Reverse-Proxy für mehrere Subdomänen in unserem Unternehmen fungiert.

Da pfSenseüber Squid3 ein Reverse-Proxy bereitgestellt wird, würde ich gerne den Apache-Server loswerden und pfSensestattdessen alles mit weiterleiten.

Meine aktuelle Apache-Konfiguration sieht ungefähr so ​​aus:

<VirtualHost *:80 *:443>
    RewriteEngine   on
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

    ServerName trac.mycompany.com
    SSLProxyEngine on

    SetEnv force-proxy-request-1.0 1
    SetEnv proxy-nokeepalive 1

    ProxyPreserveHost On
    ProxyPass / https://trac.mycompany.com/
    ProxyPassReverse / https://trac.mycompany.com/
    ProxyVia on
</VirtualHost>

<VirtualHost *:80 *:443>
    ServerName svn.mycompany.com
    ProxyPass / http://svn.mycompany.com/
    ProxyPassReverse / http://svn.mycompany.com/
    ProxyVia On
</VirtualHost>

Wie Sie sehen, sind beide ziemlich unkompliziert. Ich weiß, dass die Verwendung virtueller Hosts mit HTTPS und einer einzelnen externen IP-Adresse mich auf die Verwendung selbst signierter Zertifikate beschränkt, und ich bin mir der Risiken bewusst, aber im Moment ist mir das egal (ich möchte nur, dass Benutzernamen und Passwort verschlüsselt gesendet werden).

Am pfSensehabe ich es wie folgt konfiguriert:

Bildbeschreibung hier eingeben

Bildbeschreibung hier eingeben

Der Reverse-Proxy ist eingeschaltet. Beide traclaufen svnauf demselben lokalen Server (192.168.0.26). Das Problem ist, dass, wenn der Proxy den internen Server erreicht, der lokale Server Apache immer versucht, die tracSubdomäne zu bedienen, anstatt nach Namen abzugleichen.

Kann ich dies mit dem Reverse-Proxy-Modul von erreichen pfSense? Übersehe ich hier etwas Offensichtliches?

Antwort1

ich weiß, das ist eine späte Antwort, aber besser spät als nie :) Sie haben das Problem wahrscheinlich inzwischen gelöst, aber falls nicht: Erstellen Sie eine sekundäre IP-Adresse auf dem lokalen Server, der über dieselbe Netzwerkkarte läuft, und führen Sie jede Website über eine separate IP aus.

ich hätte nicht gedacht, dass man zwei https-Sites jemals über dieselbe IP-Adresse und dieselben Ports bereitstellen kann, da die Header bei der Verschlüsselung verloren gehen und man immer auf der standardmäßigen Hauptsite landet. Zwei http-Sites sind in Ordnung, aber zwei https-Sites benötigen unterschiedliche Ports oder unterschiedliche IPs.

verwandte Informationen