4
2 Subnetze, eine Internetverbindung - Squid will nicht
Hallo zusammen,
wir haben zwei Subnetze an zwei verschiedenen Standorten. Der zweitstandort ist über eine Standleitung mit dem Hauptstatndort verbunden. Im Hauptstandorte steht eine Debian-Firewall die unter anderem einen Squid inkl. Squidguard laufen hat. Soweit so gut.
Gehe ich über den Hauptstandort ins Netz funktioniert alles wunderbar. Bestimmte Seiten werden herausgefiltert und die gängigen ip-checks (z.B. heise.de/ip) zeigen mir auch an, dass ich mit proxy unterwegs bin.
Gehe ich hingegen vom zweitstandort - also über die standleitung richtung standort 1 - ins Netz, geht das Internet ebenso problemlos. Doch leider verwendet er keinen Proxy zum surfen, sondern geht ohne gefiltert zu werden direkt ins www (der ip-check erkennt ebenfalls keinen Proxy).
Ich würde sagen, dass es nicht an der Konfiguration des Squids liegt, sondern eher allgemein mit dem Routing zusammenhngt, ganz ausschließen kann ich es jedoch nicht. Auch ist in der Squid-ACL nur das erste Netz (192.168.6.0/24) auf Allow gesetzt und alle anderen sidn auf deny. Da das Netz trotzdem ging wird es wie gesagt wohl nicht daran liegen.
Ich weiss leider nicht, was ich noch für Informationen zur Verfügung stellen kann/soll/muss. Also wenn ihr was wissen wollt, was zur Lösung des Problems wichtig ist, fragt einfach. Ich werde versuchen so gut es geht zu antworten.
Hoffe jemandne ist ein derartiges Problem schon mal untergekommen und es kann eine Lösung gefunden werden.
Danke vielmals und Gruß, LL
wir haben zwei Subnetze an zwei verschiedenen Standorten. Der zweitstandort ist über eine Standleitung mit dem Hauptstatndort verbunden. Im Hauptstandorte steht eine Debian-Firewall die unter anderem einen Squid inkl. Squidguard laufen hat. Soweit so gut.
Gehe ich über den Hauptstandort ins Netz funktioniert alles wunderbar. Bestimmte Seiten werden herausgefiltert und die gängigen ip-checks (z.B. heise.de/ip) zeigen mir auch an, dass ich mit proxy unterwegs bin.
Gehe ich hingegen vom zweitstandort - also über die standleitung richtung standort 1 - ins Netz, geht das Internet ebenso problemlos. Doch leider verwendet er keinen Proxy zum surfen, sondern geht ohne gefiltert zu werden direkt ins www (der ip-check erkennt ebenfalls keinen Proxy).
Ich würde sagen, dass es nicht an der Konfiguration des Squids liegt, sondern eher allgemein mit dem Routing zusammenhngt, ganz ausschließen kann ich es jedoch nicht. Auch ist in der Squid-ACL nur das erste Netz (192.168.6.0/24) auf Allow gesetzt und alle anderen sidn auf deny. Da das Netz trotzdem ging wird es wie gesagt wohl nicht daran liegen.
Ich weiss leider nicht, was ich noch für Informationen zur Verfügung stellen kann/soll/muss. Also wenn ihr was wissen wollt, was zur Lösung des Problems wichtig ist, fragt einfach. Ich werde versuchen so gut es geht zu antworten.
Hoffe jemandne ist ein derartiges Problem schon mal untergekommen und es kann eine Lösung gefunden werden.
Danke vielmals und Gruß, LL
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: 121972
Url: https://administrator.de/forum/2-subnetze-eine-internetverbindung-squid-will-nicht-121972.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
4 Kommentare
Neuester Kommentar
Um deine Frage umfassend beantworten zu können müsste man wissen ob du ein natives Routing über die Standleitung machst, also ohne irgendwelches NAT. (IP Adress Translation)
Leider lieferst du diese Information wie auch die der IP Adressierung nicht, so das man wieder mal leider raten muss
Ok, raten wir mal das du ein natives Routing ohne jegliches NAT machst.
Der erste sinnvolle Test wäre dann mal zu sehen ob von einem remoten Client der Proxy angepingt werden kann und auch rückwärts.
Ist das der Fall funktioniert das Routing dann sauber,m sollte ja auch bei einem solchen einfachen Banalnetz.
Es ist vollkommen klar das AUCH das remote Subnetz im Squid Proxy in die PERMIT Liste aufgenommen werden muss, ansonsten ignoriert der Proxy dieses Netz, das ist doch klar ! Es ist also ein Trugschluss, das du denkst das das auch ohne klappt !!
Als 2te Maßnahme ist auch klar das am remoten Standort natürlich der Proxy mit seiner IP Adresse und dem Proxy Port im Browser zwangsweise eingetragen werden muss. Anders ist eine proxy Nutzung ja gar nicht möglich.
Wenn der Squid Proxy dann nicht erreichbar wäre (Routing Problem etc.) dann wäre ein Internet Zugriff technisch gar nicht möglich.
In der Beziehung ist es also vollkommen unverständlich was du oben beschreibst und lässt eigentlich nur den einfachen Schluss zu das du ganz banal vergessen hast die Proxy IP im Client im remoten Netz einzutragen und den Client auf Proxybetrieb zu schalten !!
Ein guter Netzwerk Admin implementiert außerdem einen Access Listen Filter im Router der sämtlichen Port TCP 80 Traffic blockiert und nur für die Proxy IP zulässt.
Damit hättest du dann jeglichen direkten Verkehr ins Internet so oder so unterbunden.
Deine Probleme liegen vermutlich also ganz woanders...
Leider lieferst du diese Information wie auch die der IP Adressierung nicht, so das man wieder mal leider raten muss
Ok, raten wir mal das du ein natives Routing ohne jegliches NAT machst.
Der erste sinnvolle Test wäre dann mal zu sehen ob von einem remoten Client der Proxy angepingt werden kann und auch rückwärts.
Ist das der Fall funktioniert das Routing dann sauber,m sollte ja auch bei einem solchen einfachen Banalnetz.
Es ist vollkommen klar das AUCH das remote Subnetz im Squid Proxy in die PERMIT Liste aufgenommen werden muss, ansonsten ignoriert der Proxy dieses Netz, das ist doch klar ! Es ist also ein Trugschluss, das du denkst das das auch ohne klappt !!
Als 2te Maßnahme ist auch klar das am remoten Standort natürlich der Proxy mit seiner IP Adresse und dem Proxy Port im Browser zwangsweise eingetragen werden muss. Anders ist eine proxy Nutzung ja gar nicht möglich.
Wenn der Squid Proxy dann nicht erreichbar wäre (Routing Problem etc.) dann wäre ein Internet Zugriff technisch gar nicht möglich.
In der Beziehung ist es also vollkommen unverständlich was du oben beschreibst und lässt eigentlich nur den einfachen Schluss zu das du ganz banal vergessen hast die Proxy IP im Client im remoten Netz einzutragen und den Client auf Proxybetrieb zu schalten !!
Ein guter Netzwerk Admin implementiert außerdem einen Access Listen Filter im Router der sämtlichen Port TCP 80 Traffic blockiert und nur für die Proxy IP zulässt.
Damit hättest du dann jeglichen direkten Verkehr ins Internet so oder so unterbunden.
Deine Probleme liegen vermutlich also ganz woanders...
Hallo, Danke für deine Antwort.
Da ich den ganzen Spaß nicht eingerichtet habe udn noch recht neu in dem Gebiet bin, tut es mir leid, dass ich nicht alles so beschreiben kann, wie benötigt.
Pingen kann ich die Firewall aus dem zweiten netz auch problemlos.
Habe ich bereits eingetragen. ich wollte nur sagen, dass das Netz auch das www erreichen konnte, BEVOR es im Squid eingetragen war, woraus man schließen kann, dass der Traffic nicht durch den Squid sondern diret nach aussen ging.
Also der Proxy funktioniert im Hauptnetz auch ohne, dass er dem Browser mitgegeben wird. Ich nahm eigentlich an, dass es damit zusammenhängt, dass die FW alles automatisch durch den Squid lenkt. Und es tut ja auch im Hauptnetz so wie es soll. Und diese funktion des umlenkens möchte ich nun auch ins zweite Netzs implementieren.
Wie oben schon gesagt, kann ich die Firewall (192.168.6.254) problemlos aus dem remotenetz anpingen. Trage ich diese IP mit dem entsprechende Port jedoch als Proxy ein, wird mir die Verbindung verweigert.
Trage ich die selbe Daten im Hauptnetz ein, funktioniert der Proxy ganz normal (genau so wie wenn man keinen proxy einträgt).
Gruß
Zitat von @aqui:
Um deine Frage umfassend beantworten zu können müsste man
wissen ob du ein natives Routing über die Standleitung machst,
also ohne irgendwelches NAT. (IP Adress Translation)
Leider lieferst du diese Information wie auch die der IP Adressierung
nicht, so das man wieder mal leider raten muss
Ok, raten wir mal das du ein natives Routing ohne jegliches NAT
machst.
Um deine Frage umfassend beantworten zu können müsste man
wissen ob du ein natives Routing über die Standleitung machst,
also ohne irgendwelches NAT. (IP Adress Translation)
Leider lieferst du diese Information wie auch die der IP Adressierung
nicht, so das man wieder mal leider raten muss
Ok, raten wir mal das du ein natives Routing ohne jegliches NAT
machst.
Da ich den ganzen Spaß nicht eingerichtet habe udn noch recht neu in dem Gebiet bin, tut es mir leid, dass ich nicht alles so beschreiben kann, wie benötigt.
Der erste sinnvolle Test wäre dann mal zu sehen ob von einem
remoten Client der Proxy angepingt werden kann und auch
rückwärts.
Ist das der Fall funktioniert das Routing dann sauber,m sollte ja
auch bei einem solchen einfachen Banalnetz.
remoten Client der Proxy angepingt werden kann und auch
rückwärts.
Ist das der Fall funktioniert das Routing dann sauber,m sollte ja
auch bei einem solchen einfachen Banalnetz.
Pingen kann ich die Firewall aus dem zweiten netz auch problemlos.
Es ist vollkommen klar das AUCH das remote Subnetz im Squid Proxy in
die PERMIT Liste aufgenommen werden muss, ansonsten ignoriert der
Proxy dieses Netz, das ist doch klar ! Es ist also ein Trugschluss,
das du denkst das das auch ohne klappt !!
die PERMIT Liste aufgenommen werden muss, ansonsten ignoriert der
Proxy dieses Netz, das ist doch klar ! Es ist also ein Trugschluss,
das du denkst das das auch ohne klappt !!
Habe ich bereits eingetragen. ich wollte nur sagen, dass das Netz auch das www erreichen konnte, BEVOR es im Squid eingetragen war, woraus man schließen kann, dass der Traffic nicht durch den Squid sondern diret nach aussen ging.
Als 2te Maßnahme ist auch klar das am remoten Standort
natürlich der Proxy mit seiner IP Adresse und dem Proxy Port im
Browser zwangsweise eingetragen werden muss. Anders ist eine proxy
Nutzung ja gar nicht möglich.
Wenn der Squid Proxy dann nicht erreichbar wäre (Routing Problem
etc.) dann wäre ein Internet Zugriff technisch gar nicht
möglich.
In der Beziehung ist es also vollkommen unverständlich was du
oben beschreibst und lässt eigentlich nur den einfachen Schluss
zu das du ganz banal vergessen hast die Proxy IP im Client im remoten
Netz einzutragen und den Client auf Proxybetrieb zu schalten !!
natürlich der Proxy mit seiner IP Adresse und dem Proxy Port im
Browser zwangsweise eingetragen werden muss. Anders ist eine proxy
Nutzung ja gar nicht möglich.
Wenn der Squid Proxy dann nicht erreichbar wäre (Routing Problem
etc.) dann wäre ein Internet Zugriff technisch gar nicht
möglich.
In der Beziehung ist es also vollkommen unverständlich was du
oben beschreibst und lässt eigentlich nur den einfachen Schluss
zu das du ganz banal vergessen hast die Proxy IP im Client im remoten
Netz einzutragen und den Client auf Proxybetrieb zu schalten !!
Also der Proxy funktioniert im Hauptnetz auch ohne, dass er dem Browser mitgegeben wird. Ich nahm eigentlich an, dass es damit zusammenhängt, dass die FW alles automatisch durch den Squid lenkt. Und es tut ja auch im Hauptnetz so wie es soll. Und diese funktion des umlenkens möchte ich nun auch ins zweite Netzs implementieren.
Ein guter Netzwerk Admin implementiert außerdem einen Access
Listen Filter im Router der sämtlichen Port TCP 80 Traffic
blockiert und nur für die Proxy IP zulässt.
Damit hättest du dann jeglichen direkten Verkehr ins Internet so
oder so unterbunden.
Deine Probleme liegen vermutlich also ganz woanders...
Listen Filter im Router der sämtlichen Port TCP 80 Traffic
blockiert und nur für die Proxy IP zulässt.
Damit hättest du dann jeglichen direkten Verkehr ins Internet so
oder so unterbunden.
Deine Probleme liegen vermutlich also ganz woanders...
Wie oben schon gesagt, kann ich die Firewall (192.168.6.254) problemlos aus dem remotenetz anpingen. Trage ich diese IP mit dem entsprechende Port jedoch als Proxy ein, wird mir die Verbindung verweigert.
Trage ich die selbe Daten im Hauptnetz ein, funktioniert der Proxy ganz normal (genau so wie wenn man keinen proxy einträgt).
Gruß
.
"Also der Proxy funktioniert im Hauptnetz auch ohne, dass er dem Browser mitgegeben wird. .."
Dieser Satz sollte dich stutzig machen, denn das bedeutet das scheinbar keine browserbasierte Proxy Technik im klassischen Sinn verwendet wird.
Es gibt 2 Möglichkeiten:
1.) Ein Policy Based Routing der Firewall die allen Port TCP 80 Traffic an den Squid Cache rerouted
2.) Sowas wie z.B. das Cisco WCCP wo der Router den TCP 80 Traffic zentral abfängt und an den Squid sendet.
Da du ja leider scheinbar keinen Durchblick über die Installation oder die Funktion hast ist eine Hilfe weiterhin sehr schwierig, denn sie zwingt einen wiederum zum Raten hier
Als erstes solltest du mal klären ob der remote Standort NUR die Standleitung zu euch hat, also gar keine eigene Internet Anbindung und immer über die Standleitung und euren Router zwangsweise ins Internet muss.
Wenn er natürlich ebeso einen direkten Internet Zugang hat hast du ja ein Schlupfloch dort. Hier hilft ein tracert oder pathping weiter zur Wegefindung !
Dann wäre ein Klärung sehr hilfreich WIE der Proxy Redirect funktioniert. Das solltest du also dringend klären !
Gesetzt den Fall es ist 1.) mit einem Policy Based Routing in der FW, dann muss in der FW natürlich eine Regel angegeben werden die den TCP Port 80 Traffic mit der Quell IP 192.168.6.x an den Squid redirected.
Analog geschieht das mit WCCP im Router.
Du solltest einmal einen traceroute (tracert bei Win) oder pathping machen vom remoten Netz auf einem Webserver wie z.B. www.heise.de oder www.spiegel.de um mal genau zu sehen wie die Wege sind die die Packete gehen...dann kann man mal weitersehen ohne hier wild raten zu müssen !!
"Also der Proxy funktioniert im Hauptnetz auch ohne, dass er dem Browser mitgegeben wird. .."
Dieser Satz sollte dich stutzig machen, denn das bedeutet das scheinbar keine browserbasierte Proxy Technik im klassischen Sinn verwendet wird.
Es gibt 2 Möglichkeiten:
1.) Ein Policy Based Routing der Firewall die allen Port TCP 80 Traffic an den Squid Cache rerouted
2.) Sowas wie z.B. das Cisco WCCP wo der Router den TCP 80 Traffic zentral abfängt und an den Squid sendet.
Da du ja leider scheinbar keinen Durchblick über die Installation oder die Funktion hast ist eine Hilfe weiterhin sehr schwierig, denn sie zwingt einen wiederum zum Raten hier
Als erstes solltest du mal klären ob der remote Standort NUR die Standleitung zu euch hat, also gar keine eigene Internet Anbindung und immer über die Standleitung und euren Router zwangsweise ins Internet muss.
Wenn er natürlich ebeso einen direkten Internet Zugang hat hast du ja ein Schlupfloch dort. Hier hilft ein tracert oder pathping weiter zur Wegefindung !
Dann wäre ein Klärung sehr hilfreich WIE der Proxy Redirect funktioniert. Das solltest du also dringend klären !
Gesetzt den Fall es ist 1.) mit einem Policy Based Routing in der FW, dann muss in der FW natürlich eine Regel angegeben werden die den TCP Port 80 Traffic mit der Quell IP 192.168.6.x an den Squid redirected.
Analog geschieht das mit WCCP im Router.
Du solltest einmal einen traceroute (tracert bei Win) oder pathping machen vom remoten Netz auf einem Webserver wie z.B. www.heise.de oder www.spiegel.de um mal genau zu sehen wie die Wege sind die die Packete gehen...dann kann man mal weitersehen ohne hier wild raten zu müssen !!
Zitat von @aqui:
Als erstes solltest du mal klären ob der remote Standort NUR
die Standleitung zu euch hat, also gar keine eigene Internet Anbindung
und immer über die Standleitung und euren Router zwangsweise ins
Internet muss.
Wenn er natürlich ebeso einen direkten Internet Zugang hat hast
du ja ein Schlupfloch dort. Hier hilft ein tracert oder
pathping weiter zur Wegefindung !
Ja, der Standort hat definitiv nur die Standleitung und keinen anderen Weg nach draussen.Als erstes solltest du mal klären ob der remote Standort NUR
die Standleitung zu euch hat, also gar keine eigene Internet Anbindung
und immer über die Standleitung und euren Router zwangsweise ins
Internet muss.
Wenn er natürlich ebeso einen direkten Internet Zugang hat hast
du ja ein Schlupfloch dort. Hier hilft ein tracert oder
pathping weiter zur Wegefindung !
Dann wäre ein Klärung sehr hilfreich WIE der Proxy
Redirect funktioniert. Das solltest du also dringend klären !
Gesetzt den Fall es ist 1.) mit einem Policy Based Routing in der FW,
dann muss in der FW natürlich eine Regel angegeben werden die den
TCP Port 80 Traffic mit der Quell IP 192.168.6.x an den Squid
redirected.
Analog geschieht das mit WCCP im Router.
Gibt es denn eine Möglichkeit (linux-befehl), mit dem man sowas überprüfen kann?
Du solltest einmal einen traceroute (tracert bei Win) oder pathping
machen vom remoten Netz auf einem Webserver wie z.B. www.heise.de oder
www.spiegel.de um mal genau zu sehen wie die Wege sind die die Packete
gehen...dann kann man mal weitersehen ohne hier wild raten zu
müssen !!
machen vom remoten Netz auf einem Webserver wie z.B. www.heise.de oder
www.spiegel.de um mal genau zu sehen wie die Wege sind die die Packete
gehen...dann kann man mal weitersehen ohne hier wild raten zu
müssen !!
Direkter Standort mit Leitung:
Routenverfolgung zu www.heise.de [193.99.144.85] über maximal 30 Abschnitte:
1 * * * Zeitüberschreitung der Anforderung.
2 <1 ms <1 ms <1 ms router.domaene.de [192.168.1.1]
3 10 ms 7 ms 7 ms 217.0.118.148
4 6 ms 6 ms 6 ms 87.186.247.118
5 13 ms 13 ms 13 ms 217.239.39.34
6 182 ms 209 ms 218 ms 217.243.218.38
7 13 ms 13 ms 13 ms heise2.f.de.plusline.net [82.98.98.106]
8 13 ms 13 ms 14 ms www.heise.de [193.99.144.85]
Ablaufverfolgung beendet.Nebenstandort:
Routenverfolgung zu www.heise.de [193.99.144.85] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms 192.168.4.251
2 6 ms 5 ms 5 ms 10.0.2.1
3 * * * Zeitüberschreitung der Anforderung.
4 29 ms 20 ms 26 ms router.domaene.de [192.168.1.1]
5 14 ms 13 ms 12 ms 217.0.118.148
6 11 ms 15 ms 11 ms 87.186.247.118
7 44 ms 29 ms 26 ms 217.239.39.34
8 26 ms 17 ms 17 ms 217.243.218.38
9 32 ms 21 ms 29 ms heise2.f.de.plusline.net [82.98.98.106]
10 18 ms 18 ms 18 ms www.heise.de [193.99.144.85]
Ablaufverfolgung beendet.Ich nehme mal stark an, dass an der Stelle, wo die Zeitüberschreitung auftritt die Firewall sitzt und entsprechende Ports blockt, sodass der tracert dort nicht durchkommt (?).
Danke für die Hilfe.
Gruß, LL
EDIT: hab nun etwa szu diesme policy based routing rausgesucht: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.html
Laut der DOku soll man durch "ip rule list" die Liste bekommen.
firewall:~# ip rule list
-su: ip: command not foundEDIT2: wie es ausiseht, wird es durch das hier geregelt: firewall:/var/lib/iptables# ... dort ist der redirect eingetragen:
-A PREROUTING -p tcp -m tcp -s 192.168.6.0/255.255.255.0 ! -d 123.123.123.123 -i eth0 --dport 80 -j REDIRECT --to-ports 3128
doch wenn ich die 6 durch eine 4 ersetze und die Konfiguration neu lade, tut's noch nicht. Aber ich bleibe dran... und bastel noch etwas herum.
EDIT3: soo hat nun doch geklappt über die iptables. Danke für den shcibser in die richtige Richtung!
