# Squid Problem mit Port 8080

## Evildad

Hallo zusammen, 

hab ein Problem mit Squid und https Seiten.

Squid läuft auf Port 3128 und 8080.

Wird als Proxy im Browser 3128 eingestellt funktioniert alles wunderbar.

Wird jedoch Port 8080 eingestellt, kann ich nicht mehr auf https Seiten zugreifen.

Es kommt keine Fehlermeldung von Squid aber die Seite wird auch nicht angezeigt. Es lädt sich einfach zu Tode...

Die Einstellungen sind für beide Ports identisch.

Testweise habe ich Port 8081 statt 8080 konfiguriert und dann funktioniert auch alles einwandfrei.

Grundsätzlich läuft kein Service der sich mit Port 8080 in die quere kommen sollte und iptables ist auch deaktiviert.

Hatte jmd. mal ein ähnliches Problem oder am besten eine Lösung?

----------

## think4urs11

a) wozu läßt du squid auf beiden Ports laufen?

b) transparenter oder expliziter Proxy?

c) zeig mal deine squid.conf

----------

## Evildad

 *Think4UrS11 wrote:*   

> a) wozu läßt du squid auf beiden Ports laufen?
> 
> b) transparenter oder expliziter Proxy?
> 
> c) zeig mal deine squid.conf

 

a) altlasten

b)explizierter Proxy

c) Für die Übersicht habe ich die Kommentare ausgelassen.

```

http_port 10.20.30.13:3128

http_port 10.20.30.13:8080

http_port 10.20.30.23:8081

https_port 10.20.30.23:8080

cache_peer 10.20.30.23 parent 8080 3128

hierarchy_stoplist cgi-bin ?

acl QUERY urlpath_regex cgi-bin \?

no_cache deny QUERY

cache_mem 64 MB

cache_swap_low 90

cache_swap_high 95

cache_dir ufs /var/cache/squid 100 16 256

cache_access_log /var/log/squid/access.log

cache_log /var/log/squid/cache.log

cache_store_log none

emulate_httpd_log on

mime_table /etc/squid/mime.conf

pid_filename /var/run/squid.pid

auth_param basic children 5

auth_param basic realm Squid proxy-caching web server

auth_param basic credentialsttl 2 hours

refresh_pattern ^ftp:      1440   20%   10080

refresh_pattern ^gopher:   1440   0%   1440

refresh_pattern .      0   20%   4320

acl localnet src 10.20.30.0/255.255.255.0

acl all src 0.0.0.0/0.0.0.0

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255

acl to_localhost dst 127.0.0.0/8

acl SSL_ports port 443 563

acl Safe_ports port 80      # http

acl Safe_ports port 21      # ftp

acl Safe_ports port 443 563   # https

acl Safe_ports port 70      # gopher

acl Safe_ports port 210      # wais

acl Safe_ports port 1025-65535   # unregistered ports

acl Safe_ports port 280      # http-mgmt

acl Safe_ports port 488      # gss-http

acl Safe_ports port 591      # filemaker

acl Safe_ports port 777      # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost

http_access deny manager

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access deny to_localhost

http_access allow localhost

http_access allow localnet

http_access deny all

http_reply_access allow all

icp_access allow all

miss_access allow all

tcp_outgoing_address 10.20.30.23

cache_effective_user squid

visible_hostname proxy.foo.de

error_directory /etc/squid/errors

snmp_port 0

coredump_dir /var/cache/squid

```

Auszug aus dem Logfile:

```

[07/Feb/2009:22:05:16 +0100] "CONNECT bugzilla.mozilla.org:443 HTTP/1.1" 200 82669 TCP_MISS:DIRECT
```

Die Seite erscheint jedoch nicht...

```

tcp        0      0 10.20.30.23:8080     0.0.0.0:*               LISTEN      

tcp        0      0 10.20.30.13:8080     0.0.0.0:*               LISTEN      

tcp        0      0 10.20.30.23:8081     0.0.0.0:*               LISTEN      

tcp        0      0 10.20.30.13:3128      0.0.0.0:*               LISTEN    

```

Als dirty fix hab ich mir auch schon überlegt alle connects auf Port 8080 via iptables auf 3128 umzuleiten aber das hab ich noch nicht versucht und ob es funktioniert ist noch eine andere Sache...

Könnte das funktionieren?

```

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j REDIRECT --to-port 3128

```

----------

## think4urs11

```

http_port 10.20.30.13:3128

http_port 10.20.30.13:8080

http_port 10.20.30.23:8081

https_port 10.20.30.23:8080

cache_peer 10.20.30.23 parent 8080 3128
```

 er soll sich selbst als parent benutzen noch dazu wird ein ICP-Port angegeben auf dem gar nichts lauscht?

----------

## Evildad

http_port 10.20.30.23:8081  ist mein Fehler. Eigentlich ist hier Port 3128 angegeben dann würde es wieder passen.

Und, dass er sich selbst als parent benutzen soll ist auch ne Altlast. Ursprünglich waren es mal 2 Maschinen jetzt 1.

Könnte ich auch weglassen...

Was mich stutzig mach ist, dass es mit  Port 3128 funktioniert und eben nur mit 8080 nicht.

Selbst wenn ich wie oben gesagt 8081 konfigiuriere tut es.

----------

## think4urs11

Das ist doch was ich sage - eine Konfig die auf sich selbst als Parent zeigt und das noch dazu falsch kann nicht zielführend sein.

schmeiß https_port und cache_peer raus dann sollte es gehen.

----------

## Evildad

 *Think4UrS11 wrote:*   

> Das ist doch was ich sage - eine Konfig die auf sich selbst als Parent zeigt und das noch dazu falsch kann nicht zielführend sein.
> 
> schmeiß https_port und cache_peer raus dann sollte es gehen.

 

Ok ist raus aber es geht noch immer nicht richtig.

Ich glaub ich muss ein wenig präziser werden.

Es geht aus einem Dial-Pool nicht.

Der User wählt sich via ISDN auf einem MAX6000 ein bekommt eine IP aus dem Dial-In Netz welches über den MAX6000 geroutet wird.

Benutzt dieser User den Proxy auf Port 8080 funktionieren alle http Seiten jedoch keinerlei https Seiten.

Nimmt er Port 3128 funktionieren alle http UND https Seiten   :Rolling Eyes: 

Benutze ich den Proxy und komme nicht via ISDN und Dial-In Netz, sprich einem anderen Netz, funktioniert auch Port 8080 fehlerfrei.

Alles in allem habe ich wohl den MAX6000 als Fehlerquelle lokalisiert. Das Problem ist nur, dass ich dort noch nicht fündig geworden bin.

Haste ne Idee?

Achja der Thread kann wegen mir auch ins Diskussionsforum verschoben werden. 

Ist ja jetzt nicht mehr wirklich ein Gentoo only Problem.

----------

## think4urs11

Hmm, riecht irgendwie nach MTU. Via ISDN wird i.d.R. mit 576 Bytes gearbeitet, im LAN dagegen mit 1500 bzw. wenn ADSL mitspielt 1492 max.

Wenn du mir jetzt noch erklärst warum du auf einem https_port bestehst anstatt den Proxy lediglich http machen zu lassen... Denn wie die Doku sagt:

 *Quote:*   

> This is really only useful for situations where you are running squid in accelerator mode and you want to do the SSL work at the accelerator level.

 

Oder anders gesagt - im Einsatz als Forwarding-Proxy wie in deinem Fall eher 'not really useful'

 *Evildad wrote:*   

> Ist ja jetzt nicht mehr wirklich ein Gentoo only Problem.

 

Das war es eigentlich nie. Genaugenommen ist alles!="Installation (eines Pakets)" kein Gentooproblem  :Wink: 

----------

## Evildad

```
http_port 10.20.30.13:3128

http_port 10.20.30.13:8080 
```

habe ich eingestellt. Den Rest verworfen.

MTU dachte ich am Anfang auch aber wieso funktioniert es dann mit einem anderen Port problemlos?

 *Quote:*   

> Das war es eigentlich nie. Genaugenommen ist alles!="Installation (eines Pakets)" kein Gentooproblem 

 

 :Smile:  Stimmt genau!

----------

## think4urs11

Kann ich mir momentan nur durch den Mix https_port erklären. Wenn der allerdings definitiv raus ist, nur http_port aktiv ist und squid neu gestartet wurde ... dann liegts an etwas das von hier aus bisher nicht sichtbar ist.

----------

## Evildad

Ja ich bin dann langsam auch mit meinem Latein am Ende. 

Es macht halt einfach keinen Sinn wieso es nur mit 8080 nicht tut.

Alles andere würde Sinn machen aber dann sollte es mit gar keinem Port funktionieren.

Ist hier denn kein MAX6000 Profi   :Very Happy: 

----------

## Max Steel

Würde es denn weh tun wenn du den 8080 Port transparent stellst, zum ausprobiern?

----------

## m.b.j.

Warum schaust du nicht einmal mit einem Packet-Sniffer alla tcpdump nach ob du irgendwas erkennen kannst?

Sicher https ist nicht gerade das am besten geeignete Protokoll dafür, aber vielleicht bekommst du etwas sinvolles...

Mfg

----------

