27
Squid oder IPtables Portumleitung
Moin Moin,
folgendes Problem:
Unser Proxyserver ist ein Debian mit installiertem Squid. Er lauscht auf Port 3128. Alle Standardwebseiten mit Port 80 & 443 funktionieren. Sobald ich aber versuche auf einen umgeleiteten Port per Browser zuzugreifen, klappts nicht. Beispiel: test.testseite.de:2009
Wo muss ich was einstellen, dass ich auf die Webseite mit dem umgeleiteten Port komme? Ist das eine Einstellung in der squid.conf oder hat das was mit iptables zutun?
Vielen Dank!
folgendes Problem:
Unser Proxyserver ist ein Debian mit installiertem Squid. Er lauscht auf Port 3128. Alle Standardwebseiten mit Port 80 & 443 funktionieren. Sobald ich aber versuche auf einen umgeleiteten Port per Browser zuzugreifen, klappts nicht. Beispiel: test.testseite.de:2009
Wo muss ich was einstellen, dass ich auf die Webseite mit dem umgeleiteten Port komme? Ist das eine Einstellung in der squid.conf oder hat das was mit iptables zutun?
Vielen Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 240145
Url: https://administrator.de/contentid/240145
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
27 Kommentare
Neuester Kommentar
Moin,
das ist eine Einstellung in Squid. Es gibt eine ACL in der die Ports festgelegt sind, die benutzt werden können In dem Beispiel hier ist dsa die ACL Safe_Ports. Du müsstest deinen Squid in öähnlicher weise konfigurieren.
lg,
Slainte
das ist eine Einstellung in Squid. Es gibt eine ACL in der die Ports festgelegt sind, die benutzt werden können In dem Beispiel hier ist dsa die ACL Safe_Ports. Du müsstest deinen Squid in öähnlicher weise konfigurieren.
lg,
Slainte
Hi Slainte,
danke für deine schnelle Antwort. Hier sind die acl's aus der squid.conf:
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # 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 Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
Normalerweise wäre doch dann der Port 2009 bei den unregistered Ports dabei oder?
danke für deine schnelle Antwort. Hier sind die acl's aus der squid.conf:
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
acl SSL_ports port 873 # rsync
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # 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 Safe_ports port 631 # cups
acl Safe_ports port 873 # rsync
acl Safe_ports port 901 # SWAT
Normalerweise wäre doch dann der Port 2009 bei den unregistered Ports dabei oder?
Hallo,
die ACLs greifen natürlich erst, wenn die Anfragen beim Squid ankommen. Schau mal, ob sich bei der Browser-Anfrage etwas in /var/log/squid3/access.log tut.
Wenn nicht, müssten n.m.M. die Anfragen an Squid umgeleitet werden:
Gruß,
Gersen
die ACLs greifen natürlich erst, wenn die Anfragen beim Squid ankommen. Schau mal, ob sich bei der Browser-Anfrage etwas in /var/log/squid3/access.log tut.
Wenn nicht, müssten n.m.M. die Anfragen an Squid umgeleitet werden:
iptables -t nat -A PREROUTING -p tcp --dport 2009 -j REDIRECT --to-ports 3128Gruß,
Gersen
@carponizer
Ja, richtig, sollte eigentlich schon funktionieren. Was genau spuckt denn der Squid für eine Fehlermeldung aus, wenn ihr per HTTP(S) auf port 2009 zugreifen wollt?
@Gersen
Die Anfragen kommen IMMER an den Squid, da der Client ja explizit ALLE Anfragen - unabhängig vom Port - an den Squid auf Port 3128 schickt. Iptable Regeln sind am Server NICHT notwendig.
Ja, richtig, sollte eigentlich schon funktionieren. Was genau spuckt denn der Squid für eine Fehlermeldung aus, wenn ihr per HTTP(S) auf port 2009 zugreifen wollt?
@Gersen
Die Anfragen kommen IMMER an den Squid, da der Client ja explizit ALLE Anfragen - unabhängig vom Port - an den Squid auf Port 3128 schickt. Iptable Regeln sind am Server NICHT notwendig.
Hi Gersen,
danke für deinen Beitrag. Der Eintrag existierte schon bei uns in der Firewall (hat ein Kollege schon vor ein paar Wochen eingetragen)
In der access.log taucht nichts auf... Kommen wir denn auch mit dem Port 2009 bei denen an oder münzt der Squid den Port wieder auf 80 um?
danke für deinen Beitrag. Der Eintrag existierte schon bei uns in der Firewall (hat ein Kollege schon vor ein paar Wochen eingetragen)
In der access.log taucht nichts auf... Kommen wir denn auch mit dem Port 2009 bei denen an oder münzt der Squid den Port wieder auf 80 um?
Zitat von @carponizer:
In der access.log taucht nichts auf... Kommen wir denn auch mit dem Port 2009 bei denen an oder münzt der Squid den Port
wieder auf 80 um?
In der access.log taucht nichts auf... Kommen wir denn auch mit dem Port 2009 bei denen an oder münzt der Squid den Port
wieder auf 80 um?
Und was steht inn dem errolog?
Wenn der Client Port 2009 anfragt, wid der squid, sofern die acl stimmt, auch Port 2009 anfragen. snifft doch einfach mal mit, ob die Anfragen rausgeht.
lks
PS. Könnte natürlich sein, daß eure Firewall die hinter/vor dem squid steht, nur die Standard-Ports (25, 80, 443) rausläßt und ungewöhnliche Ports gleich blockt.
@SlainteMhath
Danke für den Hinweis. Nach meinem Verständnis ist das doch nur so, wenn es in den Client-Browser-Einstellungen so konfiguriert ist oder der Squid als transparenter Proxy läuft. Oder nicht?
Gruß,
Gersen
Danke für den Hinweis. Nach meinem Verständnis ist das doch nur so, wenn es in den Client-Browser-Einstellungen so konfiguriert ist oder der Squid als transparenter Proxy läuft. Oder nicht?
Gruß,
Gersen
Hallo,
wenn der Kollege den Eintrag in der FW gemacht hat, gehe ich davon aus, dass Squid und die FW auf dem gleichen Server laufen?
Gruß,
Gersen
wenn der Kollege den Eintrag in der FW gemacht hat, gehe ich davon aus, dass Squid und die FW auf dem gleichen Server laufen?
Gruß,
Gersen
Ein Error.log gibt es nicht, per Wireshark konnte ich zwar was sniffen, aber da verstehe ich auch nur Bahnhof -.-
Die Firewall dahinter schränkt nicht ein. Unser Proxy ist kein transparenter sondern als Single-Sign-On eingerichtet. Spielt das eine Rolle?
Die Firewall dahinter schränkt nicht ein. Unser Proxy ist kein transparenter sondern als Single-Sign-On eingerichtet. Spielt das eine Rolle?
Zitat von @Gersen:
Danke für den Hinweis. Nach meinem Verständnis ist das doch nur so, wenn es in den Client-Browser-Einstellungen so
konfiguriert ist oder der Squid als transparenter Proxy läuft. Oder nicht?
Von transparent steht da aber nichts Danke für den Hinweis. Nach meinem Verständnis ist das doch nur so, wenn es in den Client-Browser-Einstellungen so
konfiguriert ist oder der Squid als transparenter Proxy läuft. Oder nicht?
Zitat von @carponizer:
Ein Error.log gibt es nicht, per Wireshark konnte ich zwar was sniffen, aber da verstehe ich auch nur Bahnhof -.-
Ein Error.log gibt es nicht, per Wireshark konnte ich zwar was sniffen, aber da verstehe ich auch nur Bahnhof -.-
Kannst Du wenigstens herauslesen, ob zu der Webseite überhaupt ein request rausgeht?
Die Firewall dahinter schränkt nicht ein. Unser Proxy ist kein transparenter sondern als Single-Sign-On eingerichtet. Spielt
das eine Rolle?
das eine Rolle?
Ja, für die ACLs.
Oben hast du ja nur ein paar ACl-definitionen für safe_ports. hast Du denn auch entsprechend http_access allow oder http_access deny-Regeln wie z.B. hier?
lks
Zitat von @carponizer:
Ein Error.log gibt es nicht, per Wireshark konnte ich zwar was sniffen, aber da verstehe ich auch nur Bahnhof -.-
Ok, ich frage nochmal:Ein Error.log gibt es nicht, per Wireshark konnte ich zwar was sniffen, aber da verstehe ich auch nur Bahnhof -.-
- Was genau spuckt denn der Squid für eine Fehlermeldung bzw. Fehlerseite aus, wenn ihr per HTTP(S) auf port 2009 zugreifen wollt?
- Die Proxyeinstellungen am Client sind ja korrekt, oder?
Das steht in der squid.conf:
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
Das klingt doch so, als würden die Ports geblockt werden oder? :D
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
Das klingt doch so, als würden die Ports geblockt werden oder? :D
Ja die Proxyeinstellungen sind korrekt. Das spuckt der Firefox aus:
ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL: http://url.url.de:2009/
Connection to 79.194.195.196 failed.
The system returned: (110) Connection timed out
The remote host or network may be down. Please try the request again.
Your cache administrator is webmaster.
ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL: http://url.url.de:2009/
Connection to 79.194.195.196 failed.
The system returned: (110) Connection timed out
The remote host or network may be down. Please try the request again.
Your cache administrator is webmaster.
Das hier vebietet Verbindungen zu Ports die nciht als safe_part definiert sind.
http_access deny CONNECT !SSL_ports
Das klingt doch so, als würden die Ports geblockt werden oder? :D
Das klingt doch so, als würden die Ports geblockt werden oder? :D
Das verbietet CONNECTs zu nicht-SSL-Ports. Wenn ihr per SSL auf Port 2009 gehen wollt, wird das natürlich geblockt. Normale http-Verbindugen sind davon nicht betroffen, außer es gibt irgendwo noch andere Regeln, die das verbieten.
lks
The system returned: (110) Connection timed out
The remote host or network may be down. Please try the request again.
Das Problem liegt nicht am Squid, sondern an einer eurer Firewalls. Entweder am iptables AUF dem Squid und/oider an der FW zum Internet.The remote host or network may be down. Please try the request again.
Da muss an beiden der Squid.Server:port * an *:2009 für ausgehende (tcp) Verbindungen freigeschalten werden.
Die Firewall (iptables) liegt auf dem selben Server.
Der Eintrag ist doch schon gesetzt in den iptables oder muss der Befehl anders lauten?
Du solltest die IP-Adresse eventuell maskieren
kannst du von der squid-kiste eine telnet-verbindung dorthin machen?
telnet xy.ayb.ayc.ayd 2009
lsk
Zitat von @carponizer:
Der Eintrag ist doch schon gesetzt in den iptables oder muss der Befehl anders lauten?
Der Eintrag ist doch schon gesetzt in den iptables oder muss der Befehl anders lauten?
Welcher eintrag? Der oben iptables -t nat -A PREROUTING -p tcp --dport 2009 -j REDIRECT --to-ports 3128 ist falsch. Der routet um nur lokal auf den Port 3128. Du mußt ausgehende Pakete an port 2009 erlauben.
lks
mit telnet vom proxy bekomme ich ebenfalls einen connection timeout
Dann hast Du ein Firewall-Problem.
ich kann auf das o.g. system ohne Probleme auf Port 2009 zugreifen und sehe die Webshare-Oberfläche.
lks:
PS: Ich frage mal nicht, warum Ihr mozart offen ins Web stellt.
Anonymisier die IP-Adresse! Jetzt!
1
iptables -A PREROUTING -i eth0 -p tcp -m tcp --dport 2009 -j REDIRECT --to-ports 3128
So lautet der Eintrag bei uns
So lautet der Eintrag bei uns
Zitat von @carponizer:
iptables -A PREROUTING -i eth0 -p tcp -m tcp --dport 2009 -j REDIRECT --to-ports 3128
So lautet der Eintrag bei uns
iptables -A PREROUTING -i eth0 -p tcp -m tcp --dport 2009 -j REDIRECT --to-ports 3128
So lautet der Eintrag bei uns
Dann wird alles was an Port 2009 geht auf Port 3128 geerdet. pech gehabt.
lks
also muss der Eintrag auf jeden Fall wieder raus?
Ich verstehe den test mit telnet irgendwie nicht. wieso sollte das mit telnet überhaupt klappen?
Ich verstehe den test mit telnet irgendwie nicht. wieso sollte das mit telnet überhaupt klappen?
Hm, vielleicht solltet ihr mal wen besorgern der sihc mit (linux)-Firewalls auskennt anstatt blind am lebenden System herum zu konfigueiren...aber naja, ist nicht mein System
Das muss in etwa so lauten:
Das muss in etwa so lauten:
iptables -A OUTPUT -i <dein interface richtung internet> -p tcp --dport 2009 -j ACCEPTZitat von @carponizer:
also muss der Eintrag auf jeden Fall wieder raus?
Ich verstehe den test mit telnet irgendwie nicht. wieso sollte das mit telnet überhaupt klappen?
also muss der Eintrag auf jeden Fall wieder raus?
Ich verstehe den test mit telnet irgendwie nicht. wieso sollte das mit telnet überhaupt klappen?
darum:
lks@roku:~$ telnet server 2009
Trying server...
Connected to server.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 200 Apple WebObjects
cache-control: private
cache-control: no-cache
cache-control: no-store
cache-control: must-revalidate
cache-control: max-age=0
expires: Mon, 28-Apr-2014 16:41:11 GMT
content-type: text/html; charset=UTF-8; encoding=UTF-8
vary: Accept-Encoding, Accept-Language
pragma: no-cache
x-webobjects-loadaverage: 5
date: Mon, 28-Apr-2014 16:41:11 GMT
content-length: 2749
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<!--
Copyright (C) 1999 - 2012 HELIOS Software GmbH
HELIOS WebShare - www.helios.de
-->
<title>HELIOS WebShare</title>
<style type="text/css">
.fixedWidth { width: 15em; }
> ...
</html>
Siehe auch http://www.thomas-krenn.com/de/wiki/TCP_Port_80_%28http%29_Zugriff_mit_ ...
lks
PS. Sucht euch jemanden, der davon etwas versteht. Sonst habt Ihr sehr viele Besucher bei Euch.
