Einrichtung transparenter Squid + Susefirewall2

Das ist sehr löblich, dass du dir die Mühe gemacht hast, dein Problem so ausführlich zu schildern.
Hach, wäre das doch immer so!

Zur Sache:

Zitat von Susi2013

ch habe auf einen PC ein Suse 12.1 mit der KDE-Desktopoberfläche installiert.

Aktuell ist 12.2 und in Kürze 12.3 Upgrade würde ich auf jeden Fall empfehlen.

Zitat

Der Rechner besitzt 2 Netzwerkkarten.
eth0 = "internes" Netz, 192.168.10.1/24 (255.255.255.0), welches die Richtung zu den Clients darstellt
eth1 = "Internet", 192.168.2.80/24 (255.255.255.0), welches die Verbindung zum Internet aufbaut.

Beide Netzwerkkarten habe eine feste IP. Über yast Netzwerkeinstellungen habe ich die Netzwerkkarten konfiguriert. Dabei habe ich bei dem Gateway(Routing) die Schnittstelle "eth1" angegeben und meine IP des Routers mit der 192.168.2.1 eingegeben
Bei dem DNS Server habe ich unter "Nameserver1" ebenfalls meine Router-IP 192.168.2.1 eingetragen.

Da stellt sich die Frage, warum überhaupt zwei Subnetze, wenn doch Netzwerkdienste nur von der Maschine ausgeführt werden, die direkt am bösen Internet hängt? Das Ziel -nehme ich an- ist ja, beide Subnetze möglichst zu trennen, um eben das Interne vom Externen möglichst gut abzuschotten. Machen kann man das, fragwürdig bleibt es.

Zitat

Dort bin ich mir jedoch nicht sicher ob der Punkt Hostname/Domänenname eine Bedeutung hat oder ob diese Punkte der freien Bezeichnung dienen.

Jedes Linux ist prinzipiell fähig (und das ist auch das Haupteinsatzgebiet) riesige Netzwerke zu verwalten. Diese Punkte machen Sinn, wenn man z.B. unter einer bestimmten IP einen ganzen Cluster laufen lässt, Loadbalancing machen will, oder dergleichen mehr. Hier sind sie unerheblich.

Zitat

Nun gut. soweit funktioniert das Internet mit der festen IP.

Nun habe ich über yast die Susefirewall2, squid und yast2-squid installiert. Da zu dem Zeitpunkt eine yast2-firewall installiert war, habe ich diese danach entfernt.

Warum entfernst du die Firewall? Was bezweckst du damit?

Zitat

Konfiguration des Squid:

über den Midnightcommander habe ich unter /etc/squid/squid.conf den Punkt http_port 3128 editiert und zu http_port 192.168.10.1:3128 tranparent geändert.

Warum das? Was bezweckst du damit? Damit wird alles auf den Squid geschoben. Ziemlich sicher willst du genau das nicht.

Zitat

Andere Grundeinstellungen habe ich soweit nicht verändert.

In der Susefirewall2 unter /etc/sysconfig/SuSEfirewall2 habe ich folgende Einstellungen getätigt:
Dabei habe ich mich auf das HowTo von dieser Seite berufen: http://www.mpipks-dresden.mpg.…uide_de/html/ch26s03.html

FW_SERVICES_EXT_TCP="www"

FW_SERVICES_INT_TCP="domain www 3128"
FW_SERVICES_INT_UDP="domain"

Der Punkt: FW_SERVICE_DNS="yes", ist in der Firewallkonfiguration nicht zu finden, sodass ich diesen manuell eingetragen habe.
Bei den Firewallregeln soll laut des HowTo dieser Befehl angewendet werden. FW_REDIRECT_TCP="192.168.10.0/24,0/0,80,3128

Dieser Befehl soll die HTTP-Anfragen aus meinen "internen" Netz auf den Squid Port 3128 umleiten.

Da in der Susefirewall.conf Datei dieser Syntax anders dargestellt wird, steht er nun so in der Config:
FW_REDIRECT="192.168.10.0/24,0/0,tcp,80,3128"

Nun habe ich mit Root-Rechten über das Terminal mit den Befehl "rcsquid start" den Squid gestartet und mit "SuSEfirewall2 start" die Firewall gestartet.

Anschließen habe ich an die "interne" Netzwerkkarte ein Switch + Notebook angeschlossen. Dort habe ich eine manuelle IP Adresse vergeben. Das Notebook läuft mit einem Windows XP

IP: 192.168.10.10
Subnetz: 255.255.255.0
Gateway: 192.168.10.1
DNS: 192.168.10.1

Im Internet-Explorer habe ich unter Verbindungen zunächst einmal den Proxy eingetragen ( 192.168.10.1 Port: 3128)

Mit diesen Einstellungen funktioniert das Internet einwandfrei. Sobald ich nun bei "Verbindungen" den Punkt "automatische Suche der Einstellungen" wähle funktioniert das Internet nicht mehr.

Alles anzeigen

Mit "Suche der Einstellungen" meinst du innerhalb eines Browsers?

Generell solltest du nicht nach Anleitungen verfahren, die für sehr alte Versionen gelten.
Da hat man sich schnell verfahren.

Um dieses kleine Chaos wieder zu bereinigen, sind aber vorher ein paar prinzipielle Fragen zu klären.

Was ist der Sinn dieses Proxies?

• Willst du die beiden Netzwerksegmente möglichst sauber trennen, weil du die Sicherheit im Focus hast?
• Oder willst du Netzwerktraffic sparen, weil alle Clients häufig auf dieselben Seiten zugreifen?
• Oder hast du weitere Gründe, warum du einen Squid willst?
• Oder willst du jeden Zugriff auf das Netz nur vollständig überwachen?

Wie viele Clients gibt es im internen Netz?
Was ist mit Multimedia? (Squid kann das nur bedingt mit üblen Verrenkungen) Sollen die Clients auch Streaming gucken können?

Dein Problem dürfte von sich widersprechenden Angaben für die Namensauflösung herrühren.
Ich behaupte, dass ein "ping 8.8.8.8" in jedem Fall geht.

Mit einem "ping IPadresse" kann man immer leicht testen, ob eine Verbindung physikalisch möglich ist.
Das sollte immer der erste Befehl bei der Fehlersuche in Netzwerken sein.
Geht so ein Ping auch bei "Suche der Einstellungen"? (auch jedes Win kann "ping")

Zitat von Susi2013

Ich habe auf einen PC ein Suse 12.1 mit der KDE-Desktopoberfläche installiert.

Zitat von Susi2013

Ich habe doch die Version 12.2 installiert.

Das ist jetzt ein Widerspruch.

Was uhelp meint ist folgendes:
Die openSUSE 12.1 wird offiziell bis 15. Mai unterstützt (Sicherheitsupdates usw.).
Bevor Du Dir jetzt die Arbeit machst, wäre es zu überlegen, eine länger unterstützte Version zu nehmen (12.2) oder ein paar Tage auf die neue 12.3 zu warten und dann darauf mit der Installation zu beginnen. Erspart Dir nachher das neue Einrichten.

Quelle:
https://en.opensuse.org/Lifetime

Die Version kann man mit:

cat /etc/SuSE-release

überprüfen.

Zitat von Susi2013

Der Ping funktioniert mit den Browsereinstellungen "Automatische Suche der Einstellungen" Ich errreiche damit die Netzwerkkarte: eth0: ping 192.168.10.1, sowie eth1: ping 192.168.2.80
Das gleiche funktioniert ebenfalls mit eingetragenen Proxy im Browser.

Ds war nicht die Frage. Die Frage war: kannst du 8.8.8.8 anpingen? Daß du deine Netzwerkkarten anpingen kannst ist logisch (sonst wären die Karten deaktiviert).

Wenn du 8.8.8.8 anpingen kannst, heise.de (z.B.) aber nicht, dann geht deine Namensauflösung in die Hecke, sprich es wird kein DNS gefunden.

Hast du einen DHCP- Server laufen? Wenn nein: das würde erklären, warum deine manuelle Konfiguration klappt, die automatische aber nicht. Wenn der läuft: ist der Port dafür in der Firewall freigegeben?
Deine Netzwerkaufbau ist mir noch nicht ganz klar.

Aber etwas anders, das mir VIEL mehr Bauchschmerzen bereitet: Du schreibst:

Zitat

In dem Rechnernetz liegen ca. 25 Pc's. Es ist ein Server 2003 vorhanden der als DHCP-Server und Datenspeicher dient. Jeder PC besitzt jeweils 7 Benutzerkonten. Die PC's sind nicht in eine Domäne integriert. Leider können wir den ehemaligen Admin auch nicht mehr dazu befragen. Somit kann man den Proxy nicht anhand von Gruppenrichtlinien übergeben. Der Proxyserver soll beide Netzwerksegmente sicher trennen, Netzwerktraffic einsparen und den Zugriff auf das Netz überwachen.

Da nun der Kunde nicht den Kostenaufwand in die Höhe treiben will, wollen wir einen transparenten Proxy-Server vor Ort installieren

Ich formuliere mal, wie ich das verstehe, bitte korrigiere mich wenn ich falsch liege:
Du bist als Dienstleister in einer Firma, deren Admin nicht mehr da ist, hast geringe bis keine Kenntnisse von Netzwerk, Firewall und Proxy und versuchst, einen Proxy mit Firewall aufzubauen.

Wenn das so ist: Schau daß das jemand macht, der wirklich weiß, was er macht. So geht das ziemlich bald in die Hecke und die finanziellen Folgen können sowohl für die Firma als auch für dich verheerend sein.

Kosten niedrig halten wollen ist prinzipiell ok, aber in diesem Fall kann das zur Existenzgefährdung führen.

Wie mir gerade auffällt: Du arbeitest mit einer Anleitung für eine Suse 9.2 und willst damit auf einer 12.2 ein solches System aufsetzen? Mir läuft gerade ein kalter Schauer den Rücken runter. Da hat sich mit Sicherheit einiges bei der Konfiguration geändert. Die jeweiligen Release Notes hast du alle gelesen und die Änderungen in der Config umgesetzt?

Ich fürchte, ich werde nichts weiter zu diesem Thema schreiben, schon alleine um dich und den Kunden zu schützen. Denn: Wenn du jetzt nicht weiterkommst, wird jemand anderes geholt, der sich hoffentlich mit der Materie auskennt. Bekommst du das Ding irgendwie zum laufen, knallt es später so richtig - u.a. weil du nicht gewährleisten kannst, daß deine Firewall irgendjemand standhält, der sich damit auskennt. Dann wäre u.a. die Kundendatenbank beim Konkurrenten oder sonstwo...

Sag dem Kunden, daß du das nicht leisten kannst und hole einen Profi. Das ist am Ende deutlich billiger und sicherer.

flo

Warum fragst Du dann nicht Deinen Ausbilder?
Der kann in den configs sehen woran es liegt, du kannst nachfragen warum nicht bzw. was der Befehl bewirkt usw. Wäre auf jeden Fall sinnvoller als irgendwas einfach nur abzutippen.

Fragen kostet nichts.

Wie schon geschrieben: Anleitung für 9.x brauchst du NIE wieder versuchen.
Frag vorher lieber hier. Spart enorm Ärger.

Die "yast-Fireewall" IST die Susefirewall.
Eine Neue und eine alte Version macht nicht nur Ärger.
Es wäre eher löblich, wenn das Ärger machen würde. Es ist wohl nur noch defunct.
Ganz sicher nicht, was du willst.

Ich interpretiere das Szenario so, dass du ein locales Netzwerk komplett unter Kontrolle halten willst.
Mit einem Squid kannst du gerade mal eine handvoll Protokolle EIN KLEINWENIG kontrollieren.
Vergiss diese Idee.
Es gibt unzählige Protokolle. Und all die können munter weitermchen und scheren sich einen *ZENSUR* um deine Sicherheitsbemühungen.

Und du schießt dir jedes mal selbst in's Knie, wenn ein Rechner aus dem lokalen Netz mit Diensten von außerhalb kommunizieren kann.

Das anzuratende Szenario wäre:

• Der WAN Router liegt in der externen Zone.
• Eine Linuxkiste in der DMZ (entmilitarisierte Zone) spielt die Firewall, die rigoros restriktiv filtert und das Gateway für alle lokalen Rechner und für alle Dienste spielt.

Jetzt wird es etwas undurchsichtig und hängt von den Kosten versus der gewünschten Sicherheitsstufe ab. Lies mal das als Einführung über Firewalls und DMZ

Bevor ich dieses Setup skizziere, mag ich eine deutliche Warnung vorweg geben:
Wenn die WinServer nicht mehr wartbar sind, ist Sicherheit und Überwachung das Letzte, was anzugehen ist. Zuallererst mit höchster Priorität sind ALLE Netzwerkdienste, die die WinServer leisten, sauber auf Linux zu migrieren. Samt Echtzeit-Failover.

Ist das nicht gewährleistet, LASS DIE FINGER DAVON!!
Das wird bitter und bitter teuer. Und eure Reputation ist nicht nur bei diesem Kunden Geschichte.
Jeder Versuch nicht wartbare WinServer "irgendwie" weiterzuverwenden UND die gesamte Netztopologie zu ändern, ist VORSÄTZLICHER SELBSTMORD!! LASS DIE FINGER DAVON!!

Man könnte jetzt regalfüllende Abhandlungen über sanfte Migration schreiben.
Lass besser einfach die Finger davon. Oder denke in Ruhe nach, simuliere dein daraus entstehendes Konzept und LASS NOCH IMMER DIE FINGER DAVON!!

Erst, wenn du alle Client Konten von EGAL WELCHEM Dienst samt ALLEN Daten SICHER hast, kannst du es mit geringer (und das heißt von Freitag früh bis Montag früh) Downzeit wagen.

Aber zur Sache zurück:
Im Weiteren kürze ich der Einfachheit halber das
lokale Netz mit LZ, die DMZ mit DZ und das "externe" Netz mit EZ ab. Die
zugehörige Netzwerkkarte bezeichne ich schlicht mit "n". DZn ist also
die Netzwerkkarte, die die DMZ bedient.

Der sichere und relativ einfache Weg, dieses Netz wirklich zu kontrollieren, setzt zwei Linuxkisten voraus.
Die "bessere" sitzt in der DZ und stellt allen Rechnern in der LZ alle Dienste bereit.

Die "kleinere" Linuxkiste macht nur die Firewall UND das Protokollieren des Netzwerkverkehrs, in der gewünschten "Inspektionstiefe". Sie hat eine LZn und eine DZn. Damit ist die LZ schon ganz gut nach außen in die EZ abschirmt.
Die "bessere" Linuxkiste kümmert sich um alles, was für die LZ an Diensten benötigt wird und kommuniziert mit der EZ. Sie hat eine DZn und eine LZn

Was hier noch fehlt, ist die zweite Firewall. Die kannst du entweder auf der kleinen ODER der großen laufen lassen.
Da man unter Linux einer physikalischen Netzwerkkarte mehrere IPs betreiben kann, lässt ich auf beiden dieser Segmentübergang leicht simulieren. Sicherer ist hier natürlich diese Firewall noch der "besseren" Linuxkiste zuzumuten.

Die kleine Linuxkiste bedient mit einer Firewall die Segmente DZ und EZ, hat also DZn und EZn.
Und -sofern die Netzwerk-Bruttolast und die Größe der HDs es hergeben- die gewünschte Netzwerkprotokollierung. (ggf. kann man eine eigene Kiste dafür einsetzen, oder die Protokollierung -nach sorgfältig analysierter Netzlast- auf verschiedene Kisten splitten. Die dann natürlich für diesen Zweck mit eigenen Netzwerkkarten ein eigenes Protokollnetzwerk abbilden sollten.)

Auf der großen würde dein Squid (zusätzlich) laufen, damit du Netzwerktraffic sparen kannst.
Bist du dir sicher, dass sich dieser Aufwand lohnt?
Hast du verlässliche Daten über die Nutzung von URIs des gesammten Netzwerks?.
Ich schreibe bewusst URI - nicht URL.
Es macht keinen Sinn, wenn drei Rechner auf eine URL zugreifen, auf dem Zielserver aber mit verschiedenen "Session-Cookies" zugreifen. Da würde dein Squid alles brav cachen, um bei jedem Zugriff doch wieder den ZielServer anzuklingeln. Also sinnloses Caching mit sinnlosem Rechenaufwand.
Ich denke, das ist der Normalfall. Ein Squid also nur scheinbar hilfreich.
In der Praxis wird meist das Gegenteil erreicht.
Aber wie gesagt:
Ohne verlässliche Analyse nur wieder Eintopf von Gemüse
Sind die Daten Kraut und Rüben, muss der Admin fleißig üben.

Etwas billiger wäre dieses Konzept der zweistufigen Firewall durch den Einbau einer dritten Netzwerkkarte in jetzt nur noch eine benötigte Kiste. Hier werden die drei Zonen auf einer Linuxkiste simuliert, laufen aber auf einem Rechner. Der muss dann aber auch alles machen.
Die
Idee ist, dass dieser Linuxserver gleichzeitig alle Rollen übernimmt
und das zweistufige Konzept mittels DNS Zauberei und Firewallrules
emuliert wird.

Oder noch billiger -ohne dritte Netzwerkkarte- alles auf die zwei phsikalischen Netzwerke verteilen.
Die Routingregeln werden umso komlexer, je weniger Geld ausgegeben wird.
(Was i.d. R. teuerer ist, weil Mannzeit teurer als etwas Hardware und einfacher Setup ist)

Das war jetzt alles nur Vorgeplänkel und sicher keine befriedigende Antwort.
Nur für eine solche fehlen noch immer alle Fakten.
Das ist auch -nimmt man es Ernst- viel zu komplex.
Wenn du funktionierenden Sound und Micro hast, solltest du dir nach Trekkie00s Post mumble installieren.
So etwas lässt sich viel leichter und sinnvoller im Voicechat belabern...