SSL Problem nach Squid Installation

Hallo,
habe seit der Installation von Squid über das App-Center massive Probleme auf meinem UCS-Master.
Nach der Installation ist mir erstmal nichts ungewöhnliches aufgefallen, ich wunderte mich erst, als der Slave Softwareupdates anstehen hatte und der Master nicht.
Das ist nun schon wieder ne Weile her. Damals habe ich auf dem Slave einen local repository mirror angelegt und habe den Master so eingerichtet, dass er sich die Errata-Updates vom local mirror holt. Damit konnte ich wunderbar weiter leben.

Mittlerweile sind meine Server alle bei Version 4.1-1 errata-level 156, der Master wurde von 4.0-x upgegraded, Slave wurde direkt mit 4.1 installiert. (erwähne das, weil ich was von einem “updater-problem” mit der alten Version gelesen habe…)

So weit, so gut. Jetzt wollte ich auf dem Master m23 aus dem AppCenter installieren.
Tja, da waren Sie wieder meine Probleme. Das AppCenter erreicht der Master nämlich nicht, da ich immer noch die besagten SSL Probleme habe.
Wenn ich in der WebGui das AppCenter aufrufe zeigt er mir immer eine alte gecachte Version.

in der Console kommt folgender Fehler:

root@ucs-dc1:# univention-app update Downloading "https://appcenter.software-univention.de/meta-inf/4.1/index.json.gz"... Die Verbindung wurde vom Kommunikationspartner zurückgesetzt

Also hab ich mich auf Fehlersuche begeben, viel hier im Forum gesucht und dann mal folgendes probiert:

root@ucs-dc1:# wget -vv https://appcenter.software-univention.de/meta-inf/4.1/index.json.gz --2016-04-22 11:56:15-- https://appcenter.software-univention.de/meta-inf/4.1/index.json.gz Auflösen des Hostnamen »appcenter.software-univention.de (appcenter.software-univention.de)«... 176.9.114.147, 2a01:4f8:151:6489::2 Verbindungsaufbau zu appcenter.software-univention.de (appcenter.software-univention.de)|176.9.114.147|:443... verbunden. GnuTLS: A TLS packet with unexpected length was received. Es ist nicht möglich, eine SSL-Verbindung herzustellen.

Es ist also kein DNS Problem sondern ein Problem mit der SSL Verbindung. Auf dem Slave klappt das alles übrigens einwandfrei. Habe dann also Konfigurationen verglichen, ich find keinen Unterschied, weiß aber auch ehrlich gesagt nicht mehr, wo ich noch gucken soll.
Squid deinstallieren bringt keine Änderung, egal ob ich Squid über die Console oder die WebGui deinstalliere.
Da muss irgendwo noch ein Unterschied sein.

Mit curl hab ich folgende Ausgabe:

[code]root@ucs-dc1:~# curl -vv https://appcenter.software-univention.de/meta-inf/4.1/index.json.gz

Ich weiß nicht mehr weiter. Sicherlich könnte ich m23 auch in das local repository spiegeln, aber dann ist der Fehler ja immer noch da.

Das ist wahrscheinlich nur ein winziges Konfigurationsproblem, ich suche jetzt schon ganze 2 Tage nach der Ursache, aber mittlerweile fühle ich mich schneeblind. Bitte dringend um Hilfe, sonst fühle ich mich das ganze Wochenende über doof.

Danke, für jeden Hinweis!

Gruß Matthias

Moin,

vorweg eine Frage: Haben Sie zwischen Ihrem Server und dem Internet irgendwelche Firewall-, Proxy-, Virenscan-Produkte sitzen? Z.B. Intrusion-Detection-Systeme, transparente Webproxies? Wir hatten in der Vergangenheit durchaus Probleme z.B. mit einer Sophos UTM und der darin integrierten Web Protection.

Nun zum Testen. Können Sie bitte mal das Paket »gnutls-bin« installieren und anschließend folgendes testen:

gnutls-cli -p 443 appcenter.software-univention.de

Es sollte eine Ausgabe kommen, die ungefährt so aussieht:

[code]Resolving ‘appcenter.software-univention.de’…
Connecting to ‘2a01:4f8:151:6489::2:443’…

  • Ephemeral Diffie-Hellman parameters

  • Using prime: 2048 bits

  • Secret key: 2045 bits

  • Peer’s public key: 2048 bits

  • Certificate type: X.509

  • Got a certificate list of 3 certificates.

  • Certificate[0] info:

  • subject C=DE,postalCode=28359,ST=Bremen,L=Bremen,STREET=Mary-Somerville Str. 1,O=Univention GmbH,OU=PremiumSSL Wildcard,CN=*.software-univention.de', issuerC=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Organization Validation Secure Server CA’, RSA key 2048 bits, signed using RSA-SHA256, activated 2015-08-31 00:00:00 UTC', expires2018-11-28 23:59:59 UTC’, SHA-1 fingerprint `787da481f93c9785c843bce1bbcb6d7fac8684d4’

  • Certificate[1] info:

  • subject C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Organization Validation Secure Server CA', issuerC=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Certification Authority’, RSA key 2048 bits, signed using RSA-SHA384, activated 2014-02-12 00:00:00 UTC', expires2029-02-11 23:59:59 UTC’, SHA-1 fingerprint `104c63d2546b8021dd105e9fba5a8d78169f6b32’

  • Certificate[2] info:

  • subject C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Certification Authority', issuerC=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root’, RSA key 4096 bits, signed using RSA-SHA384, activated 2000-05-30 10:48:38 UTC', expires2020-05-30 10:48:38 UTC’, SHA-1 fingerprint `f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0’

  • The hostname in the certificate matches ‘appcenter.software-univention.de’.

  • Peer’s certificate issuer is unknown

  • Peer’s certificate is NOT trusted

  • Version: TLS1.2

  • Key Exchange: DHE-RSA

  • Cipher: AES-128-CBC

  • MAC: SHA1

  • Compression: NULL

  • Handshake was completed

  • Simple Client Mode:[/code]

Wenn das bis dahin noch klappt, dann geben Sie mal direkt dort die folgenden zwei Zeilen gefolgt von einer Leerzeileeine:

[code]GET /meta-inf/4.1/index.json.gz HTTP/1.1
Host: appcenter.software-univention.de

[/code]

Das sollte dann eigentlich folgende Antwort liefern (gefolgt von Binärdaten):

HTTP/1.1 200 OK Date: Mon, 25 Apr 2016 07:42:13 GMT Server: Apache/2.2.22 (Debian) Last-Modified: Sun, 24 Apr 2016 20:43:19 GMT ETag: "93c1726-96db-531411c2e87c0" Accept-Ranges: bytes Content-Length: 38619 Content-Type: application/x-gzip

Sollte das klappen, dann als nächstes bitte folgendes probieren:

curl --noproxy -v -v https://appcenter.software-univention.de/meta-inf/4.1/index.json.gz > /dev/null

Gruß,
mosu

Hallo,

erstmal Danke für die ausführliche Beschreibung. Nach der Installation von gnutls-bin hab ich das erste Kommando rausgehauen und direkt Fehler bekommen:

root@ucs-dci1:~# gnutls-cli -p 443 appcenter.software-univention.de Resolving 'appcenter.software-univention.de' ... Connecting to '176.9.114.147:443'... *** Fatal error: A TLS packet with unexpected length was received. *** Handshake has failed GnuTLS error: A TLS packet with unexpected length was received. root@ucs-dc1:~#

Also, nicht wirklich anders als vorher… :frowning:

Als Gateway ist eine PFSense Maschine im Einsatz, die aber den UCS Systemen eine direkte Verbindung ins Internet ermöglicht. Die PFSense Büchse macht eigentlich nur WAN Load-Balancing, um mehrere DSLer in Lastverteilung zu benutzen.
Den Slave beeinträchtigt das ja auch nicht. Der Slave benutzt die selben Netzwerk / Gateway Einstellungen wie der Master. Nur der Master hat die TLS / SSL Probleme.
Wie gesagt, ich verstehe es nicht. Das ganze seit der Installation (und auch wieder Deinstallation) von Squid auf dem Master…

Gruß
Matthias

Huhu,

Squid unter Univention unterstützt auch transparentes Proxying, bei dem alle Webverbindungen über den lokalen Proxy erzwungen werden. Schauen Sie doch mal nach, ob die UCR-Variable squid/transparentproxy auf true oder yes gesetzt ist.

Gruß,
mosu

root@ucs-dc1:~# ucr get squid/transparentproxy false

Squid ist jetzt aktuell auch gar nicht installiert.

Sollte ich vielleicht mal die ganzen squid betreffenden variablen aus der registry entfernen? Macht das einen Unterschied?

Moin,

sind Sie sicher, dass Squid nicht installiert ist? Was sagt denn dpkg -l|grep squid?

Schauen Sie auch bitte mal nach, was die Firewall so sagt, genauer: iptables -t nat -L -nv und iptables -t mangle -L -nv.

Gruß,
mosu

Hier die Ausgaben der Befehler:

root@ucs-dc1:~# dpkg -l|grep squid rc squid3 3.1.20-2.2.23.201509021143 amd64 Full featured Web Proxy cache (HTTP proxy) rc univention-nagios-squid 5.0.1-1.30.201511040009 all nagios plugin for monitoring squid daemon and webservice rc univention-squid 9.0.1-1.228.201511040706 all UCS Squid web proxy integration

[code]root@ucs-dc1:~# iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 1802 packets, 498K bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 1787 packets, 495K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 1564 packets, 128K bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 1564 packets, 128K bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination
[/code]

[code]root@ucs-dc1:~# iptables -t mangle -L -nv
Chain PREROUTING (policy ACCEPT 20161 packets, 21M bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 20146 packets, 21M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 17987 packets, 21M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 18001 packets, 21M bytes)
pkts bytes target prot opt in out source destination
[/code]

Gruß
Matthias

Moin,

mir gehen langsam die Ideen aus :frowning:

Bitte schalten Sie Ihre PFSense mal fest auf eine Leitung, um auch die Lastverteilung als mögliche Ursache auszuschließen.

Gruß,
mosu

Auch das hab ich schon versucht, keine Veränderung im Verhalten.
Würde ja auch keinen Sinn ergeben, das eine UCS Maschine damit ein Problem hat, und die andere nicht. Aber ich weiß, Logik und Computer muss nicht immer was miteinander zu tun haben…

Ich vermute, dass da irgendwo etwas von der Squid Installation verbogen wurde, bei der Installation nicht rückgängig gemacht wurde, und ich es jetzt nicht finde. Irgend eine Idee, was das sein könnte??

Sehr ärgerlich. Möchte aber die Holzhammermethode “Neuinstallation” vermeiden, grade weil es der Master ist.

Gruß
Matthias

Moin,

da fallen mir keine wirklich tollen Sachen mehr ein. Was sagen denn Dinge wie

[ul][li]dpkg --audit[/li]
[li]dpkg --configure -a[/li]
[li]ps uaxw|grep squid[/li][/ul]

Haben Sie den Server seit der Deinstallation neu gestartet?

Läuft der Server in einer virtuellen Maschine? Falls ja, können Sie ihn mal auf eine physikalische umziehen? Und umgekehrt, falls er auf physikalischer Hardware läuft?

Haben Sie eine Möglichkeit, den Server kurzfristig direkt ans Internet zu hängen, ohne dass eine Firewall (pfsense) dazwischen ist?

Können Sie mal kurzfristig die IP des Servers ändern (nicht umkonfigurieren, nur kurz) und es dann erneut probieren? Also grob so:

ip addr del 192.168.x.y/24 dev eth0 ip addr add 192.168.x.z/24 dev eth0 ip route add default via 192.168.x.1

Anschließend den gnutls-cli-Test wiederholen, danach dann einmal rebooten, um die richtige Konfiguration wiederherzustellen.

Gruß,
mosu

Mastodon