SuSE 9.1 als Server und Router für Netzwerk

Mit der Firewall habe ich es auch schon probiert, geht aber nicht, weil soweit die Firewall aktiviert ist, kann ich mich nicht mehr einwählen.

Zum Vergrößern anklicken....

Was muss ich bei den Clients als Router-IP eintragen? Die IP der Netzwerkkarte des Servers oder was?

Zum Vergrößern anklicken....

game-freak schrieb:

Hi Leutz, bin das erste mal hier im Forum und komme gleich mit einer wichtigen Bitte.

Folgendes:

Ein Netzwerk mit mehreren Linux-Rechnern. Einer davon ist der Netzwerkserver, über den alle anderen ins Internet gehen sollen.

Hallo game-freak,

hier zwei Texte die mir geholfen haben.

Erst der Text zur Einrichtung des Gateways, dann die Konfiguration der SuSE Firewall2.

DSL-Gateway für private Netzwerke ab SuSE Linux 8.0

Bezieht sich auf: SUSE LINUX 8.0 (ich habe alles mit Linuxversion SuSE 9 realisiert).

Anliegen

Sie haben einen Rechner mit DSL über einen PPPoE-Anschluss, z.B.T-DSL von T-Online oder Arcor-DSL Flatrate. Diesen möchten Sie als Internet Gateway für Ihr lokales Netzwerk verwenden.

Vorgehen

Da solch komplexe Themen nicht durch den Installationsupport abgedeckt sind, soll diese kurze Anleitung Ihnen beim Aufbau eines solchen Gateways behilflich sein.
Bitte beachten sie, dass dieser Artikel nicht die Grundlagen über Firewalling und Systemsicherheit vermitteln kann. Literatur zu diesen finden Sie z.B. in unserem Verlag "SuSE Press" im Internet http://www.susepress.de/.

Wir können keine Gewährleistung für Schäden übernehmen, die aufgrund des Gebrauchs eines Gateways an Ihren Daten oder lokalem Netzwerk entstehen.

Hier eine Schritt für Schritt Anleitung inklusive einiger Tests der Konfiguration.

Anmerkung:
Im folgenden wird der Rechner, der als Gateway funktionieren soll, Gateway genannt, die Rechner in Ihrem internen LAN Clients.

Im Gateway brauchen Sie 2 Netzwerkkarten. Eine für den DSL Anschluss und eine für das interne Netzwerk. Diese richten Sie bitte mit dem YaST2 ein. YaST2 -> Netzwerk Basis -> Konfiguration der Netzwerkkarte. Zuerst richten Sie die Netzwerkkarte für das interne LAN ein. Vergeben Sie eine statische IP Adresse.

IP Adresse: 192.168.0.1 Subnetzmaske: 255.255.255.0

Am Rechnernamen und am Routing brauchen Sie nichts zu verändern. Speichern Sie die Konfiguration ab.

Anmerkung:
Wenn Sie ein bestehendes internes Netzwerk haben, muß die IP Adresse eine Adresse aus Ihrem bestehendem internen Netzwerk sein. Eine gute Wahl für Ihr internes Netzwerk sind die Adressen aus dem 192.168er Bereich. In unserem Beispiel hat das interne Netzwerk IP Adressen aus dem Bereich 192.168.0.0 bis 192.168.0.255.

Test der Netzwerkkarte für das interne LAN

Pingen Sie die soeben eingerichtet Netzwerkkarte mit dem Befehl ping -c 2 192.168.0.1. Sie sollten ungefähr folgende Ausgabe bekommen:

PING 192.168.0.1 (192.168.0.1) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.655 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.329 ms

--- 192.168.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1008ms
rtt min/avg/max/mdev = 0.329/0.492/0.655/0.163 ms


Sollten Sie diese Ausgabe nicht erhalten, hat etwas bei der Konfiguration der Netzwerkkarte nicht geklappt und Sie sollten diese noch einmal vornehmen. Sie können übrigens den Befehl ping jederzeit mit der Tastenkombination STRG + C abbrechen.

Nun wird die zweite Netzwerkkarte für die Kommunikation mit dem DSL Modem eingerichtet. Starten Sie wieder YaST2 -> Netzwerk Basis -> Konfiguration der Netzwerkkarte. Geben Sie dieser Karte eine IP Adresse aus einem anderen Subnetz. Damit schließen Sie Störungen des internen Netzwerks aus.

IP Adresse: 192.168.2.22 Subnetzmaske: 255.255.255.0

Auch hier brauchen Sie am Rechnernamen und am Routing nichts verändern. Speichern Sie die Konfiguration ab.

Test der Netzwerkkarte für das DSL Modem

Pingen Sie die soeben eingerichtet Netzwerkkarte mit dem Befehl ping -c 2 192.168.2.22. Sie sollten ungefähr folgende Ausgabe bekommen:

PING 192.168.0.22 (192.168.2.22) from 192.168.2.22 : 56(84) bytes of data.
64 bytes from 192.168.2.22: icmp_seq=1 ttl=255 time=0.655 ms
64 bytes from 192.168.2.22: icmp_seq=2 ttl=255 time=0.329 ms

--- 192.168.2.22 ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 1008ms
rtt min/avg/max/mdev = 0.329/0.492/0.655/0.163 ms

Sollten Sie diese Ausgabe nicht erhalten, hat etwas bei der Konfiguration der Netzwerkkarte nicht geklappt und Sie sollten diese noch einmal vornehmen.

Test der Verbindung zum internen LAN

Sind die Tests der Netzwerkkarte erfolgreich gewesen, sollten Sie testen, ob Sie vom Gateway die Clients erreichen können. Dies können Sie wiederum mit dem Befehl ping tun. Auf den Befehl ping -c 3 -b 192.168.0.255 sollten Sie von einigen Clients eine Antwort erhalten. Die Ausgabe dieses Befehls sollte ungefähr so aussehen wie unten stehendes Beispiel.

WARNING: pinging broadcast address
PING 192.168.0.255 (192.168.0.255) from 192.168.0.1 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.774 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.19 ms (DUP!)
64 bytes from 192.168.0.3: icmp_seq=1 ttl=255 time=1.30 ms (DUP!)
64 bytes from 192.168.0.4: icmp_seq=1 ttl=64 time=1.57 ms (DUP!)

--- 192.168.0.255 ping statistics ---
2 packets transmitted, 2 received, +3 duplicates, 0% loss, time 1010ms
rtt min/avg/max/mdev = 0.325/1.033/1.573/0.438 ms


Wie Sie hier sehen, antworten die Rechner mit den IP Adressen 192.168.0.1 (Gateway) und 192.168.0.2 bis 192.168.0.4 (Clients). Wenn Sie die IP Adresse eines Clients kennen, können Sie diese auch direkt pingen, um die Verbindung zu testen.

Es ist essentiell, dass Sie vom Gateway aus die Clients erreichen können und anders herum. Sollte diese Verbindung nicht funktionieren, brauchen Sie gar nicht erst weiter zu machen. Beheben Sie zuerst die Probleme im internen LAN und kümmern Sich dann um die Verbindung des LANs mit dem Internet.

Richten Sie auf dem Gateway Ihren DSL Zugang gemäß dem Referenz Handbuch, Seite 440 beziehungsweise für Benutzer der SuSE Linux Personal Version, gemäß dem Basis Handbuch, Seite 103/104 ein. Verwenden Sie als Ethernetkarte hierbei eth1. Die Firewall aktivieren Sie bitte nicht. Wenn Sie Dial on Demand aktivieren, stellt der Gateway eine Verbindung ins Internet her, sobald eine Anfrage ins Internet, vom Gateway oder von einem Client aus, gestellt wird. Beachten Sie bitte, dass dies nur sinnvoll ist, wenn Sie eine Flatrate haben.

Test der Verbindung ins Internet

Testen Sie die Verbindung ins Internet vom Gateway. Mit dem Befehl cinternet können Sie die Verbindung manuell aufbauen (cinternet -start) und abbauen (cinternet -stop). Bauen Sie die Verbindung auf, warten 30 Sekunden und testen dann wieder mit dem Befehl ping die Verbindung. Pingen Sie zum Beipiel unseren Webserver www.suse.de mit ping -c 4 www.suse.de. Die Ausgabe sollte ungefähr wie folgt aussehen.

ping -c 4 www.suse.de
PING www.suse.de (213.95.15.200) from 217.225.119.194 : 56(84) bytes of data.
64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=1 ttl=251 time=23.9 ms
64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=2 ttl=251 time=23.7 ms
64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=3 ttl=251 time=24.0 ms
64 bytes from Turing.suse.de (213.95.15.200): icmp_seq=4 ttl=251 time=24.0 ms

--- www.suse.de ping statistics ---
4 packets transmitted, 4 received, 0% loss, time 3030ms
rtt min/avg/max/mdev = 23.775/23.941/24.035/0.184 ms

Es ist genauso essentiell, dass diese Verbindung funktioniert, wie dass die Verbindung zu den Clients funktioniert. Sollte diese Verbindung nicht funktionieren, sollten Sie erstmal die Probleme bei der Internet-Verbindung lösen und sich dann um die Verbindung des LANs mit dem Internet kümmern.

Nun müssen Sie den Gateway darauf vorbereiten, Anfragen vom internen LAN ins Internet weiterzuleiten. Die einfachste Lösung ist die SuSE personal-firewall. Dies ist ein einfacher, iptables-basierter Paketfilter, der alle unerlaubte Pakete aus dem Internet abweist und dafür Sorge tragen kann, dass Anfragen aus dem internen LAN ins Internet weitergeleitet werden. Die SuSE personal-firewall hat eine Konfigurationsdatei

/etc/sysconfig/personal-firewall

mit einer Konfigurationsvariable REJECT_ALL_INCOMING_CONNECTIONS. Editieren sie diese Datei und nehmen bitte folgende Einstellung vor.

REJECT_ALL_INCOMING_CONNECTIONS="ppp0 masq"

Zusätzlich müssen Sie noch dem Kernel mitteilen, dass Sie gerne Pakete weiterleiten möchten. Dies tun Sie in der Datei

/etc/sysconfig/sysctl

Editieren Sie diese Datei und ändern die Variable IP_FORWARD in

IP_FORWARD="yes"

Als letztes müssen Sie noch dafür sorgen, dass die SuSE personal-firewall beim Booten Ihres Gateways gestartet wird. Dies tun Sie mit den Befehlen:

insserv personal-firewall.initial
insserv personal-firewall.final

Damit diese Einstellungen ohne einen Reboot übernommen werden, führen Sie bitte folgende Befehle aus:


echo "1" > /proc/sys/net/ipv4/ip_forward

rcpersonal-firewall start


Ab SuSE Linux 8.1:
Ab SuSE Linux 8.1 gibt es die SuSE personal-firewall nicht mehr. Dafür hat die SuSEfirewall2 einen SuSE personal-firewall legacy Mode. Das heißt Sie müssen nicht mehr dafür sorgen das die SuSE personal-firewall beim Booten gestartet wird sondern SuSEfirewall2. Dies tun Sie mit den Befehlen:

insserv SuSEfirewall2_final
insserv SuSEfirewall2_init
insserv SuSEfirewall2_setup

Die SuSEfirewall2 starten Sie mit dem Befehl:

rcSuSEfirewall2 start

Test der Verbindung ins Internet mit der SuSE personal-firewall

Starten Sie noch einmal die Verbindung in das Internet mit dem Befehl cinternet -start und prüfen Sie mit dem Befehl ping, wie im letzen Test-Abschnitt beschrieben, die Internet Verbindung.

Im letzten Schritt müssen Sie den Clients mitteilen, dass ab sofort der Gateway eine Internet Verbindung zur Verfügung stellt. Dies tun Sie auf einem SuSE Linux 8.0 Client, indem Sie in YaST2 -> Netzwerk/Erweitert -> Routing die IP Adresse des Gateway als Standard Gateway angeben. In diesem Fall wäre das

Standardgateway: 192.168.0.1

Zusätzlich müssen Clients noch wissen, wie sie einen Nameserver erreichen können, um Domainnamen in IP Adressen auflösen zu können. Hierzu lesen Sie aus der Datei

/etc/resolv.conf

auf dem Gateway bei bestehender Internetverbindung die Nameserver aus. In diesem Beispiel ist es ein Nameserver von T-Online. Tragen Sie diesen auf den Clients ein. Auf einem SuSE Linux 8.0 Client können Sie hierzu YaST2 -> Netzwerk/Erweitert -> Hostname und DNS verwenden. Den Host und Domainnamen lassen Sie so, wie er ist.


Liste der Nameserver: 217.89.23.137
Domain-Suchliste: .de


Test der Internet Verbindung von einem Client

Nachdem Sie auf Ihren Clients den Standardgateway und den Nameserver gesetzt haben, testen Sie mit dem Befehl ping die Verbindung ins Internet, wie im letzten Test-Abschnitt beschrieben.


Sind alle diese Tests erfolgreich verlaufen, steht ab sofort den Clients die Internet Verbindung des Gateways zur Verfügung.

Jetzt der Text zur Konfiguration der SuSE Firewall2 auf dem Gateway.

Bemerkung:
Nach jeder manuellen Änderung der Konfigurationsdatei "SuSEfirewall2" in "/etc/sysconfig/",
sollte die SuSEfirewall via Konsole neu gestartet werden (mit "root" anmelden):

rcSuSEfirewall2 restart --> Neustart
rcSuSEfirewall2 status --> Funktionsabfrage
rcSuSEfirewall2 stop --> Beendet die Firewall
rcSuSEfirewall2 start --> Sartet die Firewall


Konfigurieren eines Linux-Routers (mit Hilfe von SuSEfirewall2)

Im folgenden gehe ich von einem bereits installierten SuSE Linux (in meinem Fall ein SuSE Linux 8.0) aus. Außerdem sollten natürlich die beiden dafür benötigten Netzwerkkarten schon eingebaut und bereit sein.

Mit der SuSEfirewall2 bietet SuSE eine sehr gute firewall, mit der sich Dinge wie routing, masquerading usw. leicht verwirklichen lassen. Oft jedoch stoße ich auf Anfragen wie man denn jetzt die einzelnen Punkte konfigurieren muss. Hierzu schreibe ich jetzt dieses Tutorial.

Seit SuSE 8.0 liegt die Config-File für die SuSEfirewall2 in /etc/sysconfig/SuSEfirewall2. Dieses Datei ist eigentlich von sich aus schon sehr gut dokumentiert. Im folgenden möchte ich jedoch noch Zusatzinformationen zu den einzelnen Punkten geben.

1.) Should the Firewall be started?
Der erste Punkt weißt nur kurz darauf hin, dass man, um die Firewall automatisch zu starten, einfach nur einen link in /etc/init.d/rc?.d erstellen soll. Tja und wie genau mach ich das jetzt? Am einfachsten ist wohl wenn man Yast2 startet, und beim Runlevel-Editor unter Runlevel-Eigenschaften die Einträge SuSEfirewall2_final, SuSEfirewall2_init und SuSEfirewall_setup alle auf "Ja" setzen, und zusätzlich noch aktivieren, dass sie sowohl in runlevel 3 wie auf 5 gestartet werden sollen (ganz unten, bei "Der Dienst wird in folgenden Runlevel gestartet").

2.) Which is the interface that points to the internet/untrusted networks?
Bei diesem Punkt gibt es eigentlich nicht viel zu erklären. Hier müssen sie einfach das Interface angeben, welches in das Internet führt. D.h. z.B. bei einer ADSL oder Modem verbindung wäre dies ippp0, ippp1, ... bei einer LAN ähnlichen Verbindung wie z.B.: Kabel wäre dies eth0, eth1, ...

3.) Which is the interface that points to the internal network?
Jetzt einfach das Interface angeben das NICHT zum Internet führt. Also das Interface das z.B.: ins interne LAN geht.

4.) Which is the interface that points to the dmz or dialup network?
Das dmz (de-militarisierte Zone) kann ein Bereich in ihrem LAN sein, der auch vom Internet aus erreichbar ist. Als normaler Heimanwender werden sie dies wohl eher selten brauchen, eine dmz ist nur sinnvoll wenn sie intern z.B. einen WebServer haben den sie natürlich nach außen hin erreichbar machen wollen. Daher werden sie in der Regel diesen Punkt frei lassen.

5.) Should routing between the internet, dmz and internal network be activated?
Dieser Punkt gibt an ob sie eine Verbindung von Rechnern im LAN nach außen hin erlauben wollen. Nachdem wir hier ja einen router aufbauen wollen ist es wohl logisch das wir diesen Punkt auf yes setzen .

6.) Do you want to masquerade internal networks to the outside?
Masquerading bedeuted, dass die Rechner in ihrem internen LAN nach außen hin unsichtbar sind. D.h. nach außen hin sieht es so aus als würden alle request vom router selber kommen. Bei diesem Punkt gibt es jetzt mehrere Optionen. FW_MASQUERADE gibt an ob prinzipiell masquerading erfolgen soll. Natürlich ist es sinnvoll diese Option bei einem Router auf yes zu setzen, schließlich wollen wir ja alle surfen lassen ! FW_MASQ_DEV ist schon automatisch auf das externe Interface (siehe Punkt 2) gesetzt.

Die letzte Option bei diesem Punkt, FW_MASQ_NETS, ist etwas komplizierter. Sie gibt an welche IPs vom internen LAN nach außen hin durchgreifen dürfen. Zur Angabe dieser IPs werden sogenannte Netmasks verwendet. Netmasks geben einen gewissen IP-Bereich an. Z.B. würde 192.168.0.0/8 heißen, alle IPs von 192.168.0.0 bi 192.168.0.0 + 8 bit dürfen durch. + 8 bit bedeuted das 192.168.0.0 + 256 IPs durchgreifen dürfen (da 2^8 = 256). Im Endeffekt dürfen also alle IPs von 192.168.0.0 - 192.168.0.255 durchgreifen. Netmasks lassen sich natürlich beliebig verändern, so könnten sie statt 8 auch 16 nehmen und dann wäre der Bereich von 192.168.0.0 - 192.168.1.255. Diese Option sollten sie klarerweiße an ihre internen IPs anpassen.

7.) Do you want to protect the firewall from the internal network?
Dieser Punkt sollte unbedingt auf yes gesetzt werden. Wenn dieser Punkt auf yes gesetzt ist, können Rechner vom internen LAN nur auf ganz speziell erlaubte Dienste AUF der Firewall zugreifen. Das schützt sie sozusagen vor ihnen selber .

8.) Do you want to autoprotect all running network services on the firewall?
Hier werden alle Dienste automatisch geschützt, d.h. nicht verfügbar gemacht. Sie können nacher natürlich wieder einzelne Dienste freigeben. Auch hier ist es eine gute Wahl die Option auf yes zu setzen!

9.) Which services ON THE FIREWALL should be accessible from either the internet (or other untrusted networks), the dmz or internal (trusted networks)?
Hier können sie spezielle Service auf der Firewall freigeben. D.h. sollten sie zum Beispiel einen WebServer betreiben so sollten sie den www Port freigeben, oder wenn sie einen mail-server haben dann pop/smtp. Dienste die hier freigegeben sind können von ALLEN erreicht werden, d.h. von innen und von außen.

10.) Which services should be accessible from trusted hosts/nets?
Hier können sie spezielle Rechner/Netze angeben die entweder generell Zugriff haben oder bestimmte Services nutzen dürfen. Z.B. könnten sie generll den Zugriff auf ssh verbieten, und dann hier bei dieser Option einen Rechner, welcher als Wartungs-PC dient, angeben der dann auf ssh zugreifen darf.

11.) How is access allowed to high (unpriviliged [above 1023]) ports?
Hier können sie angeben ob Zugriffe auf highports erlaubt sind. Sollten sie nicht planen irgendwelche Programme auf highports laufen zu lassen so sollten sie diese Option unbedingt auf no setzen bzw. auf die Default Einstellung.

12.) Are you running some of the services below?
Hier müssen sie einige spezielle Dienste extra freischalten (da diese spezielle "zuwendung" brauchen ). Sollten sie einen der angegeben Services laufen haben so schalten sie einfach die entsprechende Option auf yes.

13.) Which services accessed from the internet should be allowed to the dmz (or internal network - if it is not masqueraded)?
Von diesem Punkt würde ich unbedingt die Finger lassen, da er großen Schaden anrichten kann. Hier können sie gewisse Netze/Ports angeben die direkt zum einem Rechner nach innen durch-geroutet werden sollen. Dies ist naürlich ein sehr hohes Sicherheitsrisiko und sollte nur sehr überlegt eingesetzt werden.

14.) Which services accessed from the internet should be allowed to masqueraded servers (on the internal network or dmz)?
Das ist im Prinzip genau das selbe wie die vorherige Option, allerdings diesesmal geht es um masqueraded Rechner (die in unserem Fall auch die einzigen sind). Aber auch hier gilt, nicht anwenden, wenn man nicht weiß was man tut .

15.) Which accesses to services should be redirected to a localport on the firewall machine?
Dieser Punkt ist sehr praktisch wenn sie die Rechner aus ihrem internen LAN unbedingt zwingen wollen über einen Proxy zu surfen. D.h. das alle request dann gleich automatisch zu dem Proxy auf der Firewall redirected wird, ohne das der interne Rechner etwas dagegen tun kann. Ansonsten kann man ihn aber generell frei lassen.

16.) Which logging level should be enforced?
Zu dieser Option gibt es nicht wirklich viel zu sagen. Kommt einfach drauf an wie gerne sie Log-files lesen .

17.) Do you want to enable additional kernel TCP/IP security features?
Nun ja wie auch in der Konfig-file erwähnt sollte diese Option zunächst einmal auf no gesetzt werden. Dann ales konfigurieren und wenn alles funktioniert auf yes setzen! Wenn dann noch immer alles funktioniert beibehalten, ansonsten wieder abdrehen !

18.) Keep the routing set on, if the firewall rules are unloaded?
Unbedingt auf no lassen. Es gibt in meinen Augen keinen wirklichen Grund warum man trotzdem noch routen sollte wenn die firewall abgedreht wird. Dies wäre ein riesiges Sicherheitsloch und ist auf keinen Fall zu empfehlen.

19.) Allow (or don't) ICMP echo pings on either the firewall or the dmz from the internet?
Diese Option ist per Default schon richtig eingestellt. So konfiguriert wie per Default dürfen sie zwar nach außen pingen, aber niemand nach innen oder die Firewall. Somit erscheinen sie nach außen hin tod !

So das waren die wichtigsten Optionen. Es gibt noch weiterer in /etc/sysconfig/SuSEfirewall2 allerdings hab ich diese noch nie benötigt.

Mfg,
Vir@s


Nun, das waren die beiden Texte, ich wuensche gutes Gelingen.

Gruss

mel

Zum Vergrößern anklicken....