Nach einem Forschungstag entdecke ich endlich den Weg, um das Problem zu lösen. Der Tipp ist: Die Clientseite muss sich wie die Serverseite in zwei Abschnitte trennen. Also ändere ich die clientseitige Konfiguration folgendermaßen:
[local_psk] client = yes accept = 127.0.0.1:8443 connect = 192.168.169.152:443 PSKsecrets = psk.txt [local_proxy] client = yes accept = 127.0.0.1:8089 connect = 127.0.0.1:8443 sslVersion = all options = NO_SSLv2 options = NO_SSLv3
Der Vorgang ist also folgendermaßen:
browser <--> [local_proxy] <--> [local_psk] <==> [server_psk] <--> [server_proxy] <==> website
Dabei -
bedeutet lokaler Verkehr, =
Internetverkehr und []
die Konfigurationsabschnitte in stunnel
Und ich aktualisieren Sie die Serverkonfiguration [squid]
Abschnitt accept
Option 8443
zu 127.0.0.1:8443
. Dieser Tellstunnel akzeptiert nur die Verbindung von localhost, andernfalls wird der [PSK]
Abschnitt unbrauchbar. So sieht es nach der Veränderung aus:
[server_proxy] accept = 127.0.0.1:8443 connect = 127.0.1:3128 sslVersion = all ciphers = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PS options = NO_SSLv2 options = NO_SSLv3 options = CIPHER_SERVER_PREFERENCE
HINWEIS
Diese Konfigurationen dienen nur zur Entwicklung / zum Testen. Wenn Sie einen hochsicheren anonymen Proxy-Server wünschen, müssen Sie debug = 0
die Protokollierung und die foreground = no
Daemon-Konfiguration in der Stunnel-Konfigurationsdatei deaktivieren, indem Sie die Squid-Konfigurations- und iptables-Regeln richtig einstellen.