Am Mittwoch, 14. April 2004 14:34 schrieb Edgar (Ede) Kuchelmeister:

Hi Andreas,

Am 14 Apr 2004 um 13:32 hat Andreas Schott geschrieben:

...

Hallo zusammen

Nachdem ich mich so langsam durch die Lösung meiner gesamten Probleme - auch mit Eurer Hilfe - gekämpft habe, fiel mir gestern noch etwas auf.

Bisher ging ich mit meinem Hauptrechner direkt in Internet. Nun war ich dabei mir einen Router aufzubauen (alter P1 166 Mhz der auch als Print- und Scan- und Backupserver dient) und stehe vor folgendem Problem.

Vom Router aus komme ich problemlos ins Internet. Vom Client, der am Router hängt leider nicht.

Ich dachte es genügt, wenn ich IP-Forwarding einschalte. Brauche ich dann noch Masquerading? Wie aktiviere ich das, ohne den Router per Firewall wieder dicht zu machen?

Also ich komme auch mit der SuSEFirewall2 ins Internet. Hast du denn beim Client auch den Router als DNS und Standard- Gateway eingetragen? Unter welchem BS läuft denn dein Client?

Die Frage ist nicht, ob es mit der SuSEFirewall2 geht - natürlich geht das, aber ich möchte eben auf dem Router keine Firewall haben, weil 1. Der PC-Router per WLAN-Karte an einem WLAN-Router mit integrierter Firewall hängt (Ich weiß - doppelt gemoppelt, aber am eigentlichen PC habe ich wegen einer neuen Firewire-Karte keinen PCI-Steckplatz mehr für die WLAN-Karte frei) 2. Auf den PC-Router (der auch Print- Scan- und Fileserver ist) auch meine Frau per WLAN vom Laptop aus zugreifen möchte. Das verhindert die Firewall - speziell für NFS. (siehe anderer Thread "NFS und Firewall") Ich möchte nur auf alle Dienste des Servers von extern zugreifen können und gleichzeitig von intern ins Internet. Wobei "extern" nur für den Server extern bedeutet - für mein Heimnetz ist das immer noch innerhalb der WLAN-Router-Firewall Dankeschön Andy

Am Mittwoch, 14. April 2004 14:45 schrieb Axel Heinrici:

Hi

On Wednesday 14 April 2004 13:32, Andreas Schott wrote:

...

Vom Router aus komme ich problemlos ins Internet. Vom Client, der am Router hängt leider nicht.

Ich dachte es genügt, wenn ich IP-Forwarding einschalte. Brauche ich dann noch Masquerading?

Ja. Und auf den Clientrechnern muss der router als gateway eingetragen sein.

Das funktioniert auch soweit

...

Wie aktiviere ich das, ohne den Router per Firewall wieder dicht zu machen?

Hier scheint ein Missverständnis bezüglich "firewall unter linux vorzuliegen". Die Firewall ist kein extra Programm, sondern ein Bestandteil des Kernels namens netfilter. Wird oft auch iptables genannt, was aber eigentlich nicht richtig ist. iptables ist nur ein programm (userspace tool), um dem Kernel zu sagen was er wie filtern soll. Anders gesagt, ohne firewall/netfilter/iptables kein masquerading. Wenn dir die SuSEfirewall, die auch nur ein Skript ist welches diverse Male iptables aufruft nicht gefällt, dann kannst du es auch manuell versuchen. man iptables hält die Antwort auf deine Fragen bereit. Das ist aber eine Menge zu lesen. Ich glaube nicht, dass es ein guter Rat wäre hier jetzt einzelne iptables-Zeilen zu posten. Ich würde vorschlagen du versuchst es erstmal mit der SuSEfirewall(2). Die Konfigurationsdatei dazu ist sehr viel einfacher als sich "mal eben" klarzumachen welche iptables-Regeln man braucht, um wirklich das zu leisten, was man haben will.

So oder so ähnlich habe ich das befürchtet. Die Einrichtung der SuSEFirewall2 klappt auch problemlos, nur wird dann eben der Zugriff auf meine freigegebenen NFS-Verzeichnisse verhindert. Welche Lösung gäbe es denn kurzfristig um den Server so zu öffnen, dass man die Firewall aktiviert und trotzdem auf NFS zugreifen kann? NFS per SSH verstehe ich momentan nicht so ganz, bzw. wird die Einrichtung sicher einige Zeit in Anspruch nehmen und der Zugriff auf NFS soll schnell klappen. Und zusätzlich habe ich ja noch die Firewall des WLAN-Routers, der direkt am DSL-Modem hängt. Zum Verständnis evtl. auch anderer Zweig des Threads Weiß jemand Rat? Andy

Ob nfs udp überhaupt braucht weiß ich nicht, aber es ist in /etc/services so aufgelistet.

Ohne mich in die Nesseln setzen zu wollen: NFS braucht auf jeden Fall UDP, deshalb rennt es auch so schnell ;-)

Am Mittwoch, 14. April 2004 16:49 schrieb David Zurborg:

Am Mittwoch, 14. April 2004 16:16 schrieb Axel Heinrici:

...

Hi

On Wednesday 14 April 2004 15:42, Andreas Schott wrote:

[...]

Habe mal einen Blick ins config-file geworfen. In der SuSEfirewall2 gibt es (bei SuSE8.1 unter 9.) "# Which services ON THE FIREWALL should be accessible from either the internet...."

Angenommen du bist nicht im Quickmode, dann sollte ein

...

...

FW_SERVICES_EXT_TCP="nfs"<<

und möglicherweise noch ein

...

...

FW_SERVICES_EXT_UDP="nfs"<< (hab nfs noch nie benutzt)

und im quickmode

FW_SERVICES_QUICK_TCP="2049" FW_SERVICES_QUICK_UDP="2049" (es geht auch wenn man da als port 2049 einträgt)

Hat leider auch nichts gebracht. Zugriff auf NFS durch die Firewall klappt nicht

hast du /etc/exports angepasst? also den laptop dort eingetragen?

Ja Hab ich. Schalte ich die Firewall ab, so kann ich die Verzeichnisse auch mounten

drucken und scannen geht ja von überall aus, also an der firewall müsste es meiner meinung nach nicht liegen.

Genau drucken und scannen hab ich in der FW als Ports freigegeben. Andy

Hi On Wednesday 14 April 2004 17:17, Andreas Schott wrote:

Am Mittwoch, 14. April 2004 16:16 schrieb Axel Heinrici:

...

Hi

On Wednesday 14 April 2004 15:42, Andreas Schott wrote:

Nur damit wir nicht aneinander vorbei reden

dsl w-lan Kabel Internet<------->HW- <------->PC- <------->"eigentlicher PC" router | router

v Laptop

So soll das aussehen?

Genau so sieht das ganze aus sind wohl irgendwie die spaces durcheinander gekommen. Jetzt siehts krumm aus.

Soweit ich das Beurteilen kann sind am HW-Router nur die Ports für http, https, pop3, news, smtp erlaubt. Wobei ich keine Komplettliste der freigegeben Ports habe.

Vielleicht möchte mal jemand einen Portsscan laufen lassen, wenn ich ihm die IP per PM mitteile?

...

Habe mal einen Blick ins config-file geworfen. In der SuSEfirewall2 gibt es (bei SuSE8.1 unter 9.) "# Which services ON THE FIREWALL should be accessible from either the internet...."

Angenommen du bist nicht im Quickmode, dann sollte ein

...

...

FW_SERVICES_EXT_TCP="nfs"<<

und möglicherweise noch ein

...

...

FW_SERVICES_EXT_UDP="nfs"<< (hab nfs noch nie benutzt)

da schon helfen.

So einfach geht es dann scheinbar doch nicht. Ich kann hier zwar "nfs" eingeben, doch Zugriff habe ich deshalb noch nicht. Ich weiß auch nicht, ob der Name des Dienstes genügt, oder ob der Port explizit angegeben werden muss

Ein "rcSuSEfirewall2 restart" hast du ausgeführt? Wenn jetzt nicht noch irgendeinem nfs-Fachmann was einfällt dann weiß ich es auch nicht. Eventuell dann doch iptables von Hand. Ich weise ausdrücklich jede Verantwortung von mir. Die Lektüre der manpage dazu empfehle ich dringend. Wenn ohne Firewall alles läuft bis auf, dass der PC dahinter am ethernet nicht ins internet kommt, dann Probiere ohne laufende Firewall ein iptables -I POSTROUTING -i [interface zum PC] -j MASQUERADE. Meist braucht man noch ein iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu damit GMX und Postbank und ähnliches läuft (... This target is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed packets...). Bedingung ist, dass man vom router aus schonmal ins internet kommt (also route richtig gesetzt ist). Zudem sollten dann alle policies auf ACCEPT stehen (nachschauen mit iptables -L und iptables -t nat -L). cat /proc/sys/net/ipv4/ip_forward sollte ne "1" liefern. Oberachtung auch in folgendem Punkt. Vermutlich ist damit auch w-lan-seitig alles scheunentorweit offen. Ich weiß nicht wie WEP oder sonstige Authentifizierungsmechanismen hier noch eingreifen, da ich immernoch Kabel tragen muss :-). mfg Axel

Am Montag, 19. April 2004 10:10 schrieb Andreas Scherer:

Am Mittwoch, 14. April 2004 16:16 schrieb Axel Heinrici:

...

Hi

On Wednesday 14 April 2004 15:42, Andreas Schott wrote:

Nur damit wir nicht aneinander vorbei reden

dsl/ isdn w-lan Kabel Internet<------->HW- <------->PC- <------->"eigentlicher PC" router | router v Laptop

So soll das aussehen?

Es würde doch auch so funktionieren. ;-)

dsl/ isdn w-lan Kabel 4-port Internet<------->HW- <--->PC- <-->Ethernet<----->"eigentlicher PC" router router Switch/Hub

v Laptop Kostet allerdings ein paar Euro - zahlt sich aber ganz sicher aus.

Grundsätzlich würde das so gehen, nur steht der PC und HW-Router im 1. Stock und meine Frau hält sich wegen Baby meist im EG auf - deshlab WLAN fürs Laptop Danek für den Tipp Andy

Hallo Andreas, hallo Andreas, Am Montag, 19. April 2004 10:10 schrieb Andreas Scherer:

Es würde doch auch so funktionieren. ;-)

dsl/ isdn w-lan Kabel 4-port Internet<------->HW- <--->PC- <-->Ethernet<----->"eigentlicher PC" router router Switch/Hub | v Laptop Kostet allerdings ein paar Euro - zahlt sich aber ganz sicher aus.

Selbstverständlich würde das gehen. Allerdings würde die "zwei-Router-Topologie" hier endgültig ad absurdum geführt: Der Wireless-LAN-Router ist hier schlicht überflüssig. Allerdings hat Andreas dagegen einen ganz lebenspraktischen Einwand:

Grundsätzlich würde das so gehen, nur steht der PC und HW-Router im 1. Stock und meine Frau hält sich wegen Baby meist im EG auf - deshalb WLAN fürs Laptop.

Grundsätzlich hat es immer etwas für sich, einen Laptop mittels Wireless LAN mit dem eigenen lokalen Netzwerk zu verbinden. Schließlich ist es der Sinn eines solchen Gerätes, dass es herumtragbar ist. Daher nun ein weiterer Vorschlag zu Topologie: dsl/ isdn Kabel 4-port Internet -------- PC- ---- Ethernet ------- "eigentlicher PC" router Switch/Hub | | w-lan access-point | | Laptop Das ganze ursprüngliche Problem fiele weg, da es jetzt nur noch einen Router und daher auch nur ein lokales Netzwerk, eine Firewall und evtl. ein Masquerading (S-NAT) gibt... Beim PC-Router müsste das wlan0-Interface durch ein zweites Ethernet-Interface ersetzt werden, das dann als ppp0 konfiguriert wird. Außerdem wäre dann noch ein externes DSL-Modem mit Ethernet-Schnittstelle nötig. Alternativ wäre auch ein internes DSL-Modem möglich, das dann in den PC-Router eingebaut und als ppp0 konfiguriert wird, ebenfalls mit Ethernet-Schnittstelle zum Splitter. Die SuSE-Firewall müsste aktiviert bleiben. Ob in diesem Fall Masquerading/Adressenumsetzung zum Internet hin notwendig ist, weiß ich nicht. Der Laptop müsste eine Adresse aus dem Netzwerk 192.168.1.0 /24 bekommen, z.B. 192.168.1.3, mit dem PC-Router (192.168.1.1) als Gateway.

HTH,

Andreas.

...

Danke für den Tipp

Andy

Viele Grüße, Marcus

Am Mittwoch, 21. April 2004 15:39 schrieb Andreas Scherer:

Am Dienstag, 20. April 2004 23:47 schrieb Marcus Glöder:

...

Hallo Andreas, hallo Andreas,

Am Montag, 19. April 2004 10:10 schrieb Andreas Scherer:

Das hatte ich ursprünglich auch so gedacht - aber ich befürchte fast, dass der dsl-router ein integriertes WLAN-Interface und kein Ethernet besitzt.

NACK Der Sinus 111 beinhaltet beide Interfaces. Aber eben auch das DSL-Modem - und dann müsste ich ein Kabel für DSL durch die ganze Wohnung ziehen - bis zu meinem PC.

Es gibt dafür DSL-Router mit integrierten LAN-Ports. Wäre natürlich ideal in Kombination mit einem WLAN-Access-Point. Dann wäre vermutlich auch der PC-Router überflüssig, denn dann könnte ja sein "eigentlicher PC" als Printserver dienen.

Na ja - dann warte ich ja wieder Ewigkeiten, bis die Seiten gedruckt sind und kann kaum vernünftig weiterarbeiten - so schicke ich sie einfach an den Printserver und der verarbeitet sie erst

Soweit ich das bis jetzt verstanden habe sind diese Überlegungen aber rein hypothetischer Natur, weil Andreas ja mit vorhandener Hardware auskommen muß.

ACK Andy

Andreas Schott, Mittwoch, 21. April 2004 17:32:

Am Mittwoch, 21. April 2004 15:39 schrieb Andreas Scherer:

...

Am Dienstag, 20. April 2004 23:47 schrieb Marcus Glöder:

...

Hallo Andreas, hallo Andreas,

Am Montag, 19. April 2004 10:10 schrieb Andreas Scherer:

Das hatte ich ursprünglich auch so gedacht - aber ich befürchte fast, dass der dsl-router ein integriertes WLAN-Interface und kein Ethernet besitzt.

NACK Der Sinus 111 beinhaltet beide Interfaces. Aber eben auch das DSL-Modem - und dann müsste ich ein Kabel für DSL durch die ganze Wohnung ziehen - bis zu meinem PC. [...]

Was spricht denn jetzt eigentlich dagegen, auf dem PC-Router Masquerading für den PC1 laufen zu lassen. Folgendes Script sollte alles nötige bewirken (Suse-Firewall kannst du dann vergessen): #!/bin/bash # Programmaufruf als Variable (spart Tipparbeit ;-) IPT="/sbin/iptables" # setzen diverser Kernel-Parameter (0=aus, 1=ein) echo "1" > /proc/sys/net/ipv4/ip_forward # Defaulteinstellungen, alte Regeln loeschen $IPT -F # evtl. vorhandene Filter loeschen $IPT -t nat -F # evtl. vorhandene NAT loeschen $IPT -X # evtl. vorh. Regelketten loeschen $IPT -P INPUT ACCEPT # alle Inputs erlauben $IPT -P FORWARD ACCEPT # alle Weiterleitungen erlauben $IPT -P OUTPUT ACCEPT # alle Outputs erlauben # Masquerading aktiviren $IPT -t nat -A POSTROUTING -o wlan0 -j MASQUERADE ######## EOF ############################################### Dieses Script als Startscript für deinen deines Runlevels eingebunden -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Marcus Glöder, Donnerstag, 22. April 2004 03:22:

Hallo Matthias,

Am Mittwoch, 21. April 2004 18:08 schrieb Matthias Houdek:

...

Was spricht denn jetzt eigentlich dagegen, auf dem PC-Router Masquerading für den PC1 laufen zu lassen.

Nichts. Genau das ist ja, wie Du weißt, auch von mir vorgeschlagen worden (nur unter der Bezeichnung "NAT"). Ich denke, dass das auf jeden Fall funktionieren wird. Wahrscheinlich ist das auch die Lösung, die den wenigsten Aufwand erfordert, weil sie an der jetzigen Situation am wenigsten ändert.

Eben.

Es ist nur so, dass die "ganze Konfiguration" mit zwei Routern "irgendwie nicht schön" ist, um Axel Heinrici zu zitieren. Die von mir vorgeschlagene Topologie...

Ja, aber es ist halt mit viel zusätzlichem Aufwand verbunden. Und wenn eh investiert werden kann/soll/muss, dann würde ich vielleicht eher dem PC1 einen W-LAN-Adapter spendieren. Sollte kein PCI-Platz mehr frei sein (die Ethernet-Karte könnte ja raus, wenn nicht on Board), dann gibt es sowas doch auch für USB. So könnte der PC1 wie das Notebook mit ins W-LAN.

[...] Weiter schreibst Du:

...

Folgendes Script sollte alles nötige bewirken (SuSE-Firewall kannst du dann vergessen):

#!/bin/bash ...

Dieses Script als Startscript für deinen deines Runlevels eingebunden

Das ist ja schon ein fertiges Konfigurationsscript. Einfacher geht's wirklich nicht mehr... ;-)

Naja, das Basis-Script meines Paket-Filters zurechtzustutzen war nun wirklich kein sooo großes Problem. Ich hoffe, ich habe nicht zu viel gekürzt *g*. Aber so kann nun endlich sicher ein Ergebnis erzielt werden - hoffe ich ;-) -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Am Donnerstag, 22. April 2004 09:43 schrieb Marcus Glöder:

Hallo Matthias,

Am Donnerstag, 22. April 2004 07:26 schrieb Matthias Houdek:

...

Marcus Glöder, Donnerstag, 22. April 2004 03:22:

...

Wahrscheinlich ist das auch die Lösung, die den wenigsten Aufwand erfordert, weil sie an der jetzigen Situation am wenigsten ändert.

Eben.

OK.

...

...

Es ist nur so, dass die "ganze Konfiguration" mit zwei Routern "irgendwie nicht schön" ist, um Axel Heinrici zu zitieren. Die von mir vorgeschlagene Topologie...

Ja, aber es ist halt mit viel zusätzlichem Aufwand verbunden.

Stimmt, das hatte ich ja auch schon zugegeben...

...

Und wenn eh investiert werden kann/soll/muss, dann würde ich vielleicht eher dem PC1 einen W-LAN-Adapter spendieren. Sollte kein PCI-Platz mehr frei sein (die Ethernet-Karte könnte ja raus, wenn nicht on Board), dann gibt es sowas doch auch für USB. So könnte der PC1 wie das Notebook mit ins W-LAN.

Daran hatte ich auch bereits gedacht (nur in Bezug auf einen PCI-Platz) und Andreas das auch vorgeschlagen.[1] Der jetzige PC-Router könnte von allen Routing-Funktionen befreit werden und nur noch als Print-, Scan- und Fileserver dienen. Das Ergebnis wäre auch hier, dass es nur noch ein Netzwerk gibt und damit das ursprüngliche Problem einfach wegfällt. Für Andreas ging das aber deshalb nicht, weil er auf die Firewire-Karte nicht verzichten kann/will. Der Ethernet-Anschluss am PC1 ist wohl OnBoard (nehme ich an), sonst wäre ein Austausch der Ethernet-Karte mit einer Wireless-LAN-Karte ja kein Problem.

Die externe USB-Lösung ist allerdings eine Idee!

...

...

Das ist ja schon ein fertiges Konfigurationsscript. Einfacher geht's wirklich nicht mehr... ;-)

Naja, das Basis-Script meines Paket-Filters zurechtzustutzen war nun wirklich kein sooo großes Problem. Ich hoffe, ich habe nicht zu viel gekürzt *g*.

Aber so kann nun endlich sicher ein Ergebnis erzielt werden - hoffe ich ;-)

Ich auch. ;-)

Um Euch zu beruhigen - das Script von Matthias ging natürlich perfekt und so konnte ich mein Problem letztlich lösen, ohne viele Kosten, Arbeit zu haben. Und Firewire brauche ich um die Videos meiner Tochter auf DVD zu bannen - das ist doch ein Grund, oder? Vielen Dank allen, die mir so ausführlich geholfen haben, auch wenn der Thread ein weinig in Bereiche abgegelitten ist, die ich nicht mehr verstanden habe ;-) Andy

Am Donnerstag, 22. April 2004 14:45 schrieb Marcus Glöder:

Hallo Andreas,

Am Donnerstag, 22. April 2004 10:01 schrieb Andreas Schott:

...

Am Donnerstag, 22. April 2004 09:43 schrieb Marcus Glöder:

...

Am Donnerstag, 22. April 2004 07:26 schrieb Matthias Houdek:

...

Aber so kann nun endlich sicher ein Ergebnis erzielt werden - hoffe ich ;-)

Ich auch. ;-)

Um Euch zu beruhigen - das Script von Matthias ging natürlich perfekt und so konnte ich mein Problem letztlich lösen, ohne viele Kosten, Arbeit zu haben.

Hurra!!!

...

Und Firewire brauche ich um die Videos meiner Tochter auf DVD zu bannen - das ist doch ein Grund, oder?

Selbstverständlich... Vielleicht hilft Dir da ja dieser Thread weiter:

http://lists.suse.com/archive/suse-linux/2004-Apr/2160.html

...

Vielen Dank allen, die mir so ausführlich geholfen haben, auch wenn der Thread ein wenig in Bereiche abgeglitten ist, die ich nicht mehr verstanden habe ;-)

Nun ja, es ist ja auch kein so ganz einfaches Thema (wie Du vielleicht auch aus der Diskussion zwischen mir, Matthias Houdek und Andreas Koenecke, die ein eigener Teilthread geworden ist, erahnen kannst...) ;-). Aber vielleicht hat Dir die ganze Diskussion doch eine Menge gebracht, was das Verständnis angeht. Wenn Du noch weiter in die "unendlichen Weiten" der Netzwerkwelt eintauchen willst, ist selbstredend viel lesen angesagt... (Es ist für Dich durchaus von Vorteil, Dir ein bestimmtes Grundverständnis über Netzwerke anzueignen, wenn Du so etwas bei Dir zu Hause betreibst.)

Zunächst solltest Du das Netzwerk-HOWTO des deutschen HOWTO-Projektes [1] lesen. Dann ist auch der Netzwerk-Teil im SuSE-Linux-Admin-Handbuch [2] wichtig, insbesondere das Kapitel über TCP/IP. Wenn Du begriffen hast, wie IP-Adressen "funktionieren" und was Subnetzmasken eigentlich sind, dann bist Du schon ein großes Stück weiter.

Die hatte ich mir schon mal reingezogen, aber wenn man das nicht dauernd braucht vergisst man es einfach wieder. Das Netzwerk-Kapitel im Kofler [3] ist vielleicht auch

nicht schlecht. Unabhängig von Linux, aber speziell für Einsteiger geschrieben ist Buch [4]. Mein ICND-Buch [5] ist wirklich fundiert, geht schon sehr ins Detail und ist auch sehr Cisco-spezifisch. Das ist dann schon mehr was für Fortgeschrittene...

Hatte mir mal den Linux Hackers-Guide ausgeliehen - ich denke den werde ich mir zulegen... Vielen Dank Andy

Am Mittwoch, 14. April 2004 15:17 schrieb Marcus Glöder:

Am Mittwoch, 14. April 2004 13:32 schrieb Andreas Schott:

...

Hallo zusammen

Hallo Andreas,

nun habe ich auch ein paar Verständnisfragen: ;-)

Auf allen Rechnern läuft SuSE 9.0 Mein Netz sieht folgendermaßen aus (Subnetz immer 255.255.255.0) PC1 mit eth0 192.168.1.2 per CAT5-Patchkabel an PC-Router Gateway 192.168.1.1 PC Router hat zwei Netzwerkkarten: eth0 mit 192.168.1.1 mit PC1 verbunden wlan0 mit 192.168.2.2 an WLAN-DSL-Router 192.168.2.1 (mit integrierter Firewall) Gateway 192.168.2.1 IP-Weiterleitung aktiviert, SuSEFirewall2 aktiviert in vorgeschlagener Standardkonfiguration - Port 631 zum Drucken und Port 6566 zum Scannen per WLAN geöffnet Laptop mit wlan0 192.168.2.3 geht direkt per 192.168.2.1 ins Internet und greift auf PC Router 192.168.2.2 per wlan auf die Drucker und den Scanner zu Soweit funktioniert auch alles. Ich komme von allen Rechnern ins Internet, kann von allen Rechnern aus drucken und kann von allen Rechnern aus scannen Ich möchte aber auch Verezichnisse vom PC-Router per NFS an PC1 und Laptop freigeben und mounten. An PC1 geht das auch problemlos, da intern der Firewall des PC-Routers. Vom Laptop komme ich aber an die NFS-Verzeichnisse nicht ran, da diese Ports entsprechend blockiert werden. Da diese aber auch immer wechseln, kann ich sie nicht explizit in der PC-Router Firewall freigeben. Schalte ich die Firewall am PC-Router aus, so kann ich NFS mounten, aber komme von PC1 mangels masquerading nicht mehr ins Internet. Und für dieses Problem suche ich eine Lösung. Vielen Dank Andy P.S. Die WLAN-Karte kann ich mangels Steckplatz nicht in den PC1 stecken - dann wäre es kein größeres Problem

Andreas Schott, Mittwoch, 14. April 2004 16:08:

Am Mittwoch, 14. April 2004 15:17 schrieb Marcus Glöder:

...

Am Mittwoch, 14. April 2004 13:32 schrieb Andreas Schott:

...

Hallo zusammen

Hallo Andreas,

nun habe ich auch ein paar Verständnisfragen: ;-)

Auf allen Rechnern läuft SuSE 9.0

Mein Netz sieht folgendermaßen aus (Subnetz immer 255.255.255.0)

PC1 mit eth0 192.168.1.2 per CAT5-Patchkabel an PC-Router Gateway 192.168.1.1

PC Router hat zwei Netzwerkkarten: eth0 mit 192.168.1.1 mit PC1 verbunden wlan0 mit 192.168.2.2 an WLAN-DSL-Router 192.168.2.1 (mit integrierter Firewall) Gateway 192.168.2.1 IP-Weiterleitung aktiviert, SuSEFirewall2 aktiviert in vorgeschlagener Standardkonfiguration - Port 631 zum Drucken und Port 6566 zum Scannen per WLAN geöffnet

Laptop mit wlan0 192.168.2.3 geht direkt per 192.168.2.1 ins Internet und greift auf PC Router 192.168.2.2 per wlan auf die Drucker und den Scanner zu

Ich hab's immer gern bildlich: [INTERNET] -------, [WLAN-DSL-Rt] [192.168.2.1] ..... .............. funk funk : : [192.168.2.2] [192.168.2.3] [ PC-Router ]--, [ LAPTOP ] [192.168.1.1] \ / \ / `---[Drucker] [192.168.1.2] [ PC1 ] Das müsste so stimmen.

Soweit funktioniert auch alles. Ich komme von allen Rechnern ins Internet, kann von allen Rechnern aus drucken und kann von allen Rechnern aus scannen

Also stimmt Routing/Masquerading auf dem PC-Router. Für das Laptop hat dies ohnehin keine Bedeutung fürs Internet. Drucken geht auch (via Cups), da Port 631 auf PC-Router offen. (Risiko: Er ist damit auch vom WLAN-Router und somit potentiell aus dem Internet erreichbar, da der WLAN-Router hier rein kann. Achte auf vernünftige Packetfiltereinstellungen im WLAN-Router!)

Ich möchte aber auch Verezichnisse vom PC-Router per NFS an PC1 und Laptop freigeben und mounten. An PC1 geht das auch problemlos, da intern der Firewall des PC-Routers. Vom Laptop komme ich aber an die NFS-Verzeichnisse nicht ran, da diese Ports entsprechend blockiert werden. Da diese aber auch immer wechseln, kann ich sie nicht explizit in der PC-Router Firewall freigeben.

Was wechselt dort? Natürlich musst du die entsprechenden Ports für NFS genau so wie Port 631 fürs Drucken an der Schnittstelle WLAN freigeben.

Schalte ich die Firewall am PC-Router aus, so kann ich NFS mounten, aber komme von PC1 mangels masquerading nicht mehr ins Internet.

Richtig, mit dem Ausschalten der SuSE-Firewall werden _alle_ Regeln für den Netfilter des Kernels zurückgesetzt. Damit auch das Masquerading.

Und für dieses Problem suche ich eine Lösung.

Ich weiß nicht, wie wichtig dir die Absicherung des PC-Routers gegen das WLAN ist, aber ich würde die Firewall-Funktion des PC-Routers in einem kleinen Home-Netz wahrscheinlich abschalten. Wichtig ist hier eine vernünftige, sichere Einrichtung des WLAN-Routers, da das der kritische Punkt für jeden Angriff von Außen ist (schau ins Handbuch des Teiles). Auf dem PC-Router gibt alle Ports frei und stelle das Masquerading für den PC1 ein. Dann kümmert sich die SuSEFirewall nur noch darum und nicht um das Blockieren von irgendwelchen Datenströmen. Ist vielleicht ein wenig oversized, aber es hilft erst einmal. Als nächsten Schritt beschäftige dich mal mit iptables und strick dir ein eigenes kleines Script, was die nötigen Einstellungen vornimmt. Tipp: Sungazer-Packetfilter (google) von Marius Brehler (die alten 1er-Versionen!) sind für einen Einsteiger ganz hilfreich und ausreichend dokumentiert. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Andreas Schott, Mittwoch, 14. April 2004 17:56:

Am Mittwoch, 14. April 2004 17:05 schrieb Matthias Houdek:

...

Andreas Schott, Mittwoch, 14. April 2004 16:08: [..]

...

Ich möchte aber auch Verezichnisse vom PC-Router per NFS an PC1 und Laptop freigeben und mounten. An PC1 geht das auch problemlos, da intern der Firewall des PC-Routers. Vom Laptop komme ich aber an die NFS-Verzeichnisse nicht ran, da diese Ports entsprechend blockiert werden. Da diese aber auch immer wechseln, kann ich sie nicht explizit in der PC-Router Firewall freigeben.

Was wechselt dort?

Jedesmal wen der Server neu bootet weist der Portmapper doch dem nfsd neue Ports zu, oder nicht?

Hm, der Zielport ist 2049, Verbindungen laufen über UDP und TCP. Ich kam bisher noch nicht in die Verlegenheit, NFS/NIS durch eine Firewall leiten zu müssen.

...

Natürlich musst du die entsprechenden Ports für NFS genau so wie Port 631 fürs Drucken an der Schnittstelle WLAN freigeben.

Soweit bin ich auch, doch welche Ports sind das?

Gib einfach alle Ports frei für Verbindungen, die von lokalen IPs reinkommen.

...

...

Schalte ich die Firewall am PC-Router aus, so kann ich NFS mounten, aber komme von PC1 mangels masquerading nicht mehr ins Internet.

Richtig, mit dem Ausschalten der SuSE-Firewall werden _alle_ Regeln für den Netfilter des Kernels zurückgesetzt. Damit auch das Masquerading.

...

Und für dieses Problem suche ich eine Lösung.

Ich weiß nicht, wie wichtig dir die Absicherung des PC-Routers gegen das WLAN ist, aber ich würde die Firewall-Funktion des PC-Routers in einem kleinen Home-Netz wahrscheinlich abschalten. Wichtig ist hier eine vernünftige, sichere Einrichtung des WLAN-Routers, da das der kritische Punkt für jeden Angriff von Außen ist (schau ins Handbuch des Teiles).

Auf dem PC-Router gibt alle Ports frei und stelle das Masquerading für den PC1 ein. Dann kümmert sich die SuSEFirewall nur noch darum und nicht um das Blockieren von irgendwelchen Datenströmen.

Soll ich dann einfach an der Stelle, wo jetzt 631 für die Druckerfreigabe 1:65535 schreiben?

Ich kenne SuSE-Firewall nicht in der Konfiguration. Kann man da nicht die Filterung für bestimmte Netze ganz ausschalten? Ich mag keine Automatismen, auf die ich mich verlassen muss. Dann lieber selbstgestrickt (und selbst durchschaut). -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

David Zurborg, Mittwoch, 14. April 2004 19:23:

[...] eine firewall wird .i.d.r. nur für den einwählrechner gebraucht (hier: unser wlan-router). eine firewall auf dem pc-router ist also völlig sinnlos. das problem sind die routing-tabellen. auf allen rechnern sollte die angepasst werden:

[LAPTOP]

| Funk

[WLAN-ROUTER] ------ [INTERNET]

| Funk? / Kabel? (im grunde egal)

[PC-ROUTER] ------ [DRUCKER]

| Kabel

[PC1]

(denke, das müsste jetzt klar genug sein)

Du liest ggf. auch mal vorher im Thread, bevor du antwortest? ;-)

routing-tabellen und einstellungen:

wlan-router 192.168.2.1: - default sollte auf internet zeigen - firewall aktiv ; masq ein

laptop 192.168.2.3: - default 192.168.2.1 (gateway) - 192.168.2.0 wlan0

pc-router 192.168.2.2 / 192.168.1.1 - default 192.168.2.1 (gateway) - 192.168.2.0 wlan0 - 192.168.1.0 eth0 - firewall aus; masq aus

pc1 192.168.1.2 - default 192.168.1.1 (gateway) - 192.168.1.0 eth0

traceroute zum prüfen der routingtabellen nehmen!

Schrieb ich bereits im anderen Teilthread. Übrigens sollte noch im WLAN-Router der PC-Router als Gateway ins Subnetz 192.168.1.0 eingetragen werden. Sonst finden die (unmaskierten) Pakete nicht wieder zurück zum PC1. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Hallo Matthias, bei den von Dir vorgeschlagenen statischen Routen habe ich ein bestimmtes Verständnisproblem. das kann aber daran liegen, dass ich die Vorgehensweise und die Syntax bei der Festlegung statischer Routen auf Cisco-Routern gelernt habe, und deshalb mit der Vorgehensweise und der Syntax bei Unix- bzw. Linux-Systemen nicht vertraut bin. Im Falle des Cisco-IOS sieht eine statische Route so aus: ip route [Ziel] [Maske] [next-hop-Router | intf] [Dist] permanent Dabei ist: ---------- [Ziel] Zielnetzwerk oder Zielhost [Maske] Subnetzmaske des Zielnetzwerkes [next-hop-Router | intf] [next-hop-Router] ist die IP-Adresse des Routers, der der nächste auf dem Weg zum Zielnetzwerk ist, aus der Sicht des Gerätes, auf dem die statische Route definiert ist (also: die IP-Adresse der "mir" zugewandten Schnittstelle des nächsten Routers auf dem Weg zum Zielnetzwerk). [ietf] ist dasjenige Interface des Gerätes, auf dem die statische Route definiert ist, aus dem der Verkehr zum Zielnetzwerk herausgejagt werden muss (z.B. eth0, serial0 oder dialer1). Die beiden Angaben sind alternativ zueinander: sie dürfen nicht beide gleichzeitig angegeben werden, aber eine davon muss gemacht werden. --> Die bis hierhin aufgezählten Angaben müssen auf jeden Fall gemacht werden. Die folgenden beiden sind dagegen optional: [Dist] Administrative Distanz. Statische Routen haben normalerweise eine administrative Distanz von 1 (EIGRP: 90, IGRP: 100, OSPF: 110, RIP: 120, direkt angeschlossene Netzwerke: 0). Mit dieser Option kann dieser Wert verändert und die Route damit "teurer" gemacht werden. permanent Dieses Schlüsselwort bewirkt, dass eine Route auch dann aufrechterhalten wird, wenn das Interface, durch das der Verkehr geleitet werden soll, ausfällt oder abgeschaltet wird. Wichtig ist nun, dass das Gerät, auf dem die statische Route definiert wird immer nur das nächste routende Gerät (den next-hop-Router) "sehen" kann. Der Blick auf all jene Router, die eventuell noch hinter dem next-hop-Router auf dem Weg zum Zielnetzwerk existieren, ist gewissermaßen verstellt. Das Gerät, auf dem die statische Route definiert ist, braucht diese ganzen anderen Router auch gar nicht zu kennen, da der next-hop-Router ja die Aufgabe hat, die Pakete zum übernächsten Router ins richtige Netzwerk zu routen. Ich nehme jetzt mal Dein Bild, das ist schön:

Ich hab's immer gern bildlich:

[INTERNET] -------, [WLAN-DSL-Rt] [192.168.2.1] ..... .............. funk funk

[192.168.2.2] [192.168.2.3] [ PC-Router ]--, [ LAPTOP ] [192.168.1.1] \ / \ / `---[Drucker] [192.168.1.2] [ PC1 ]

(Bei Einstellung einer Schrift mit fester Zeichenbreite im E-Mail-Programm ist auch alles am richtigen Platz.) Für den PC1, der meinem Verständnis nach eigentlich gar kein routendes Gerät ist (oder sein sollte), schlägst Du die folgenden Routen vor:

~# route add -net 192.168.2.0 gw 192.168.1.1 dev eth0 ~# route add -net 0.0.0.0 gw 192.168.2.1 dev eth0

Wenn ich das richtig verstehe, besagt die erste Route, dass der PC1 Pakete die für das Netzwerk 192.168.2.0 /24 bestimmt sind, über sein eigenes Interface eth0 zum next-hop-Router 192.168.1.1 (aus Sicht von PC1) schicken muss. Soweit, so klar. Die zweite Route soll dann wohl sagen, dass der PC1 Pakete, die für irgendwelche anderen Netzwerke bestimmt sind (0.0.0.0), ebenfalls aus der Schnittstelle eth0 rausgejagt werden sollen, aber jetzt zum Wireless-LAN-Router (192.168.2.1) als Zielgerät. Aber der PC1 sieht den Wireless-LAN-Router überhaupt nicht. Er hat nämlich den PC-Router direkt vor seiner Nase. Um Verkehr zum Wireless-LAN-Router leiten zu können, müsste der PC1 wissen, dass die Pakete zunächst beim PC-Router (192.168.1.1, auch Sicht von PC1) abgeliefert werden müssen. Jeglicher Verkehr, der den PC1 verlässt, muss also so oder so immer zuerst durch das Interface eth0 zum next-hop-Router 192.168.1.1 (aus der Sicht von PC1) geschickt werden. Alles weitere entscheidet dann der PC-Router. Das alles ist ganz einfach deshalb so, weil der PC1 ein Endgerät ist und deshalb gar nicht mehr als eine Schnittstelle zur großen weiten Welt hat. Wenn ich also nicht ganz daneben liege, dürfte für den PC1 auch die schlichte Definition eines Standard-Gateways ausreichen: route add -net 0.0.0.0 gw 192.168.1.1 dev eth0 - oder einach über YaST -> Netzwerk/Basis -> Konfiguration der Netzwerkkarte das Standard-Gateway (hier: 192.168.1.1) einstellen. Für den PC-Router schlägst Du vor:

~# route add -net 192.168.2.0 netmask 255.255.255.0 dev wlan0 ~# route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0

Das ist eigentlich klar, was die beiden Routen als solche betrifft. Eine Frage zur Syntax wäre, ob die Angabe der Subnetzmaske des Zielnetzwerkes unbedingt gemacht werden muss, oder ob das optional ist (bei den Routen für PC1 hattest Du sie ja weggelassen). Allerdings sind das die beiden direkt mit dem Router verbundenen Netzwerke. Die sollte ein Router auch ohne statische Route und sogar ohne Routing-Protokoll erkennen können. Daher sind beide Routen meiner Meinung nach nicht falsch aber schlicht überflüssig. Was jedoch fehlt, ist eine Route, die sagt, wohin Pakete für nicht direkt angeschlossene Netzwerke (in unserem Fall also alles, was fürs Internet bestimmt ist) hingeroutet werden sollen. Auch hier wäre ein Standard-Gateway hilfreich (sonst wird alles gedroppt, was nicht die Netzwerke 192.168.1.0 /24 oder 192.168.2.0 /24 zum Ziel hat): route add -net 0.0.0.0 gw 192.168.2.1 dev wlan0 wäre also ebenso notwendig wie ausreichend. Für den Wireless-LAN-Router schreibst Du:

Allerdings muss der WLAN-Router auch PC1 erreichen können, dafür muss er für das Subnetz 192.168.1.0 das Gateway 192.168.2.2 (den PC-Router) eingetragen bekommen (ich hoffe, das geht).

Selbstverständlich. Nach der von Dir benutzten Syntax müsste das dann so aussehen: route add -net 192.168.1.0 gw 192.168.2.2 dev wlan0 (sofern die Wireless-LAN-Schnittstelle des Wireless-LAN-Routers so heißt). Solange ausschließlich statisches Routing betrieben wird ist das auch eine notwendige Angabe, da es sich um ein entferntes Netzwerk handelt ("entfernt" insofern, als es nicht direkt mit dem Wireless-LAN-Router verbunden ist). Allerdings hielte ich es hier für einfacher zur "Entdeckung" von Routen zu solchen entfernten Netzwerken ein Routing-Protokoll (z.B. RIP) einzusetzen. Da aber solche Routing-Protokolle wie RIP nicht im Internet arbeiten können (ich spreche jetzt nicht von BGP), muss auf dem Wireless-LAN-Router auf jeden Fall noch eine statische Route für alle Zielnetzwerke außer 192.168.1.0 /24 und 192.168.2.0 /24 gesetzt werden. Ohne Routing-Protokoll also: route add -net 192.168.1.0 gw 192.168.2.2 dev wlan0 route add -net 0.0.0.0 gw [IP des ISP-POP] dev ppp0 Mit Routing-Protokoll ist nur die zweite Route nötig. Was nun den Laptop angeht, denke ich dass hier, wie beim PC1 (und aus denselben Gründen), ein schlichtes setzen des Standard-Gateways ausreichen müsste: route add -net 0.0.0.0 gw 192.168.2.1 dev wlan0 oder eben über YaST (oder Systemsteuerung -> Netzwerk). Eine Frage zur Syntax (bevor ich mich wieder völlig der Manpage zu route widme): kann die Dummyangabe 0.0.0.0 für alle Netzwerke, für die sonst keine Route definiert ist, auch durch das Schlüsselwort "default" ersetzt werden? Soweit erst mal. (Puh!) Viele Grüße an alle, Marcus

Hallo Matthias, am Donnerstag, 15. April 2004 06:53 schriebst Du:

Marcus Glöder, Mittwoch, 14. April 2004 21:58:

...

Wenn ich also nicht ganz daneben liege, dürfte für den PC1 auch die schlichte Definition eines Standard-Gateways ausreichen:

route add -net 0.0.0.0 gw 192.168.1.1 dev eth0

Im Prinzip ja. Das sollte reichen.

Ich hab hier zuerst daran gedacht, dass ja der WLAN-Router ggf. erreichbar sein muss (für Konfiguration vom PC1 aus). Und dann kann man über diesen Gateway-Eintrag auch gleich die Defaultroute schicken.

Ist ein wenig umständlich, geb ich zu. Man könnte aber so einfach durch löschen der Default-Route den Zugang zum Internet blocken, ohne gleich den WLAN-Router (und auch das Laptop) unerreichbar zu haben ;-)

Außerdem spare ich mir so die Default-Route im PC-Router, denn der braucht keinen eigenen Zugang zum Internet (IMHO).

Ich finde nicht, dass der Wireless-LAN-Router vom PC1 aus konfigurierbar sein muss. Er kann jederzeit vom Laptop aus konfiguriert werden (ich nehme jetzt mal an, dass der Laptop allenfalls im Haus herumgetragen wird und nicht häufig "auf große Reise" geht). Was ich immer noch nicht verstehe, ist, wie die Route route add -net 0.0.0.0 gw 192.168.2.1 dev eth0 überhaupt funktionieren soll. Irgendein Gerät mit der IP-Adresse 192.168.2.1 kennt der PC1 überhaupt nicht. Aber vielleicht ist das auch der Grund, weshalb in der Linux/Unix-Syntax immer auch das Interface mit angegeben wird, aus dem die Pakete zum Zielnetzwerk herausgejagt werden müssen. Angenommen der PC1 tut das: die Pakete landen dann automatisch beim PC-Router, über _dessen_ Interface eth0 mit der IP-Adresse 192.168.1.1. Und jetzt? Du schreibst, Du brächtest dann im PC-Router keine Default-Route mehr. Aber die Route mit dem Wireless-LAN-Router als weiterroutendes Gerät ist auf PC1 konfiguriert, und wenn kein Routing-Protokoll wie RIP eingesetzt wird, mittels dessen die verschiedenen Geräte im Netzwerk ihre Routing-Tabellen austauschen, dann weiß der PC-Router von dieser Route gar nichts... Wenn unter diesen Umständen der PC-Router Pakete erhält, die nicht für die Netzwerke 192.168.1.0 /24 oder 192.168.2.0 /24 bestimmt sind, dann werden sie meiner Meinung nach gedroppt (fallengelassen). Oder habe ich etwas übersehen? Jedenfalls halte ich es für besser, auf jedem Gerät eine Default-Route einzurichten. Dann weiß ich wenigstens, was ich tue. Was den Wireless-LAN-Router betrifft, habe ich offensichtlich nicht berücksichtigt, dass es sich hier um ein kommerzielles SOHO-Produkt handelt. Insofern ist Deine Bemerkung:

So der WLAN-Router das unterstützt. Ich kenne das Teil nicht.

nur allzu berechtigt. Inzwischen wissen wir (aus einer Mail von Andreas), um was für ein Gerät es sich handelt: Am Donnerstag, 15. April 2004 19:13 schrieb Andreas Schott:

Das würde bedeuten ich muss meinem WLAN-Router mitteilen, dass Pakete der IP 192.168.1.1 an 192.168.2.2 zurückgeschickt werden, weil er 192.168.1.1 nicht sieht und sie ins Nirwana schickt, oder?. Der PC-Router leitet diese dann weiter an PC1 mit 192.168.1.1

Das kann ich aber glaube ich nicht einstellen am WLAN-Router. Hab zumindest nix gefunden was sich wie Routing anhört.

Es ist der T-Sinus 111 WLAN-Router der Telekom - vielleicht hilft das.

Danach gibt es hier keine Möglichkeit, statische Routen einzurichten. Bei einem Telekom-Router, den meine Eltern in ihrem Hausnetzwerk betreiben (Teledat 530) ist das jedenfalls so, weshalb ich annehme, dass Andreas da nichts übersehen hat. Wahrscheinlich wird auf dem Wireless-LAN-Router RIP laufen, ohne die Möglichkeit, das abzustellen oder ein anderes Routing-Protokoll einzusetzen. Solange aber auf dem PC-Router nicht auch RIP läuft, nützt das allerdings gar nichts: Der Wireless-LAN-Router hat in diesem Fall keine Möglichkeit eine Route zum Zielnetzwerk 192.168.1.0 /24 festzustellen. Alle Pakete dahin würden dann vom Wireless-LAN-Router gedroppt. Zur Not würde ich vorschlagen, auf dem PC-Router NAT (Network Address Translation) einzurichten. Dann würde der PC-Router dem PC1 (der sich ja im Netzwerk 192.168.1.0 /24 befindet) eine Adresse aus dem Netzwerk 192.168.2.0 /24 zuweisen, z.B. 192.168.2.4. Für alle Geräte im Netzwerk 192.168.2.0 /24 wäre das eben nur ein weiteres Gerät in ihrem eigenen Netzwerk. Dass diese Adresse virtuell ist, brauchen sie nicht zu wissen. Der PC-Router sorgt dann für die Adressenumsetzung und damit für die Weiterleitung an die "richtige" Adresse 192.168.1.2 von PC1. Allerdings weiß ich nicht, wie die Syntax dafür unter Linux/Unix aussieht. Nach dem, was ich in diesem Thread über Masquerading gelesen habe, könnte es auch sein, dass das einen ähnlichen Zweck erfüllt (und deshalb hier auch eingesetzt werden könnte). Über Masquerading weiß ich allerdings soviel, wie ein Fisch von einem Fahrrad, da müssten dann andere weitermachen. Viele Grüße an alle, Marcus

Am Freitag, 16. April 2004 07:11 schrieb Matthias Houdek:

Hallo, Marcus

Hallo Matthias,

Eins kurz vorab, um Missverständnisse zu vermeiden: Meine Konfiguration ist eine Möglichkeit. Ich habe nirgends behauptet, es sei die einzige oder deine ginge nicht.

Das habe ich auch nicht angenommen... ;-)

Marcus Glöder, Freitag, 16. April 2004 01:01:

...

Ich finde nicht, dass der Wireless-LAN-Router vom PC1 aus konfigurierbar sein muss. Er kann jederzeit vom Laptop aus konfiguriert werden (ich nehme jetzt mal an, dass der Laptop allenfalls im Haus herumgetragen wird und nicht häufig "auf große Reise" geht).

Könnte aber sein. Ein Laptop ist halt mobil uns lt. Murphy garantiert in dem Fall, wo er vor Ort dringend gebraucht wird, woanders ;-)

OK, gebont. Weiter schreibst Du:

RIP gibt es bei mir auch nicht. _Ich_ bestimme, was von wo nach wo darf.

Du machst also ausschließlich statisches Routing. Bei kleinen Netzwerken (wie dem von Andreas) ist das auch ohne weiteres möglich. Bei großen Unternehmensnetzwerken mit tausenden von Client-Rechnern, Servern, Routern, Switches usw. würde wohl jeder Administrator / jede Aministratorin sehr schnell die Übersicht verlieren. D.h., ab einer gewissen Komplexität des Netzwerkes ist der Einsatz eines Routing-Protokolls einfach notwendig. Ich gebe Dir aber sofort zu, dass in einem solchen Falle mit Sicherheit _nicht_ RIP, sondern eher so etwas wie OSPF eingesetzt würde. Ein Netz das klein genug ist, damit RIP ordentlich arbeitet, ist wohl auch klein genug, um mit reinem statischen Routing arbeiten zu können. Ich bin jetzt vielleicht wirklich etwas penetrant, aber nur deshalb, weil ich das mulmige Gefühl habe, irgend etwas ganz Grundlegendes im Bezug auf das Routing in Linux/Unix-Systemen nicht begriffen zu haben. Also, erst mal tief Luft holen, und dann von vorne, ganz langsam:

Gut, ich bin hier in meinem Gedankengang vielleicht zu sehr mit meinen eigenen Netzen beschäftigt gewesen. Bei mir hat aus Sicherheitsgründen kein Server eine Defaultroute. Ist Bestandteil meiner Sicherheitskonzeption. Damit sind alle Verbindungswege im Netzwerk fest und kontrolliert in der Hand des Netzwerk-Admins.

Ich gehe jetzt mal davon aus, dass Du mit "Server" auch Router meinst. Das heißt dann, Router haben keine Default-Route (kein Standard-Gateway, oder wie immer Du das nennen willst).

Jeder Client hat als Defaultroute (und die brauche ich nur für die Verbindung ins Internet - alle anderen Zielnetze kenne ich beim Namen) den zentralen Internetzugang-Rechner/Proxy/Router.

Richtig, genau dafür brauche ich eine Default-Route: für den Zugang ins Internet. Dass ich nicht mit einem Router im Internet surfen oder meine E-Mails herunterladen möchte, ist schon klar. Aber der Router muss doch Pakete, die für das Internet bestimmt sind, in das richtige nächste Netz auf dem Weg dorthin weiterleiten. Oder bin ich jetzt schon auf dem falschen Dampfer?

Sollte der sich nicht im eigenen Netz befinden, müssen die Router dazwischen für die entsprechende Weiterleitung sorgen (in beide Richtungen).

Genau. Das ist eben der Punkt, den ich nicht begreife: wie macht der "dazwischenliegende" Router denn das, wenn er keine Information (in Form einer Default-Route) darüber besitzt, wohin er Pakete senden soll, deren Zielnetzwerk er nicht explizit kennt? -- Die Defaultrouten für den "übernächsten" oder "über-übernächsten" Router hast Du ja auf den Client-Rechnern definiert. Du machst auch nur statisches Routing. Die Router haben also keine Möglichkeit etwas über Routen zu erfahren, die auf den Client-Rechnern (oder anderen Routern) definiert sind. Am Beispiel von Andreas Netzwerk: Der PC-Router ist nach Dir so konfiguriert, dass er nur die beiden Netzwerke 192.168.1.0 /24 und 192.168.2.0 /24 kennt. Irgendeine andere Route ist auf dem PC-Router nicht gesetzt. Nun bekommt der PC-Router vom PC1 ein Paket, das für das Ziel 134.95.100.203 (Das ist die IP-Adresse des Web-Servers der Uni Köln, ermittelt durch ping www.uni-koeln.de) bestimmt ist. Der Router kennt nur die beiden Zielnetzwerke 192.168.1.0 /24 und 192.168.2.0 /24. Auf dem PC1 ist zwar eine Default-Route ins Internet definiert, aber von dieser Route weiß der PC-Router absolut nichts. Was also den PC-Router und die Frage, wie der sich verhält, angeht, kann die Default-Route auf PC1 nun definiert sein oder nicht. Dem PC-Router ist das Schnuppe. Er verhält sich -- meiner Meinung nach -- in beiden Fällen gleich: er droppt das Paket, weil er zu dessen Zielnetzwerk keine Route besitzt. Oder liege ich da falsch? Habe ich irgend etwas übersehen? Wie soll das gehen? Ich hoffe, ich habe Dir das Verständnisproblem, das ich mit Deiner Art der Routen-Konfiguration habe, jetzt hinreichend deutlich machen können. Die Frage ist immer: Was passiert auf dem Router? Wie macht er das, was der machen soll? mit welchen Informationen geht er um? Soweit zu meinen theoretischen Verständnisproblemen. (Nichts für ungut, das letzte was ich will, ist, Dich in irgend einer Weise persönlich anzugreifen. Aber ich denke, das ist klar.)

[...]

...

Am Donnerstag, 15. April 2004 19:13 schrieb Andreas Schott:

...

Es ist der T-Sinus 111 WLAN-Router der Telekom - vielleicht hilft das.

Danach gibt es hier keine Möglichkeit, statische Routen einzurichten. [...]

Tja, dann geht es so nicht. Scheiß Billigrouter ;-)

ACK.

...

Zur Not würde ich vorschlagen, auf dem PC-Router NAT (Network Address Translation) einzurichten. [...] Nach dem, was ich in diesem Thread über Masquerading gelesen habe, könnte es auch sein, dass das einen ähnlichen Zweck erfüllt (und deshalb hier auch eingesetzt werden könnte). Über Masquerading weiß ich allerdings soviel, wie ein Fisch von einem Fahrrad, da müssten dann andere weitermachen.

Genau so läuft es ja im Moment. Masquerading (eigentlich S-NAT) ist ja auch eine Funktion des netfilter. Leider wurde es hier nur gleichzeitig mit Port-Sperren genutzt, wodurch damit andere Netzwerkfunktionen verhindert wurden. Wird dann netfilter (hier über SuSE-Firewall) abgeschaltet, funktioniert der PC-Router wieder als Server im Netz ohne Einschränkung, aber das Masquerading ist auch abgeschaltet.

Ja, gut. In dem Fall wäre es wohl die beste Lösung, netfilter eingeschaltet zu lassen, mittels netfilter S-NAT zu konfigurieren und _alle_ TCP/UDP-Ports zu öffnen (wir wollen ja nur die Adressenumsetzung, nicht die Firewall!). Das ist zwar nicht besonders schön, aber in Anbetracht der fehlenden Möglichkeit, auf dem Wireless-LAN-Router statische Routen einzurichten, wohl die einzige Möglichkeit (soweit ich das sehen kann...). Grüße an alle, Marcus

Hallo Matthias. * Samstag, 17. April 2004 um 11:49 (+0200) schrieb Matthias Houdek:

Marcus Glöder, Samstag, 17. April 2004 01:29:

Nein, ist schon richtig. Aber die Pakete werden doch zum Routen über ein Gateway verpackt: .______________________. | Header mit Ziel-IP | | des Routers | Das intern verschickte Paket ist |----------------------| um den zusätzlichen Header größer |,--------------------,| als das Origrinal-Paket. || Header mit Ziel-IP || || des Internet-Hosts || Deshalb muss man z.B. den MTU-Wert ||--------------------|| bei DSL über interne Router ent- || Daten des Paketes || sprechend heruntersetzen. || .... || :: ::

Jetzt willst du aber Marcus komplett verwirren, oder? Beim "normalen Routing" (also kein Tunnel, VPN o.ä.) werden keine Pakete verpackt; Quell- und Zieladresse des Paketes werden während des gesamten "Weges" nie verändert (Ausnahme: NAT, und da werden die Pakete auch nicht mit zusätzlichen Headern versehen, sondern Ziel-, bzw. Quell-Adressen werden im ursprünglichen Header umgeschrieben.).

Damit ist das (verpackte) Paket primär an das Gateway zum Internet (hier der WLAN-Router) adressiert und die Router im lokalen Netz müssen dafür nur die Route zu diesem Ziel-Host kennen.

Nö.

Doch, siehe oben. Weil eben beim Senden an ein Gateway dieses Gateway die Zieladresse des Pakete ist. Die eigentliche Zieladresse muss das Gateway vor dem Weitersenden erst auspacken. ] ... ] Eben nicht. Der PC-Router erhält ein Paket, das an 192.168.2.1 (WLAN-Router) adressiert ist, welches das eigentliche Paket an 134.95.100.203 enthält.

Auch "Nö".

Ein Router macht genau das, was du oben beschreibst: Er nimmt ein Paket an und schickt es an die entsprechende Zieladresse weiter, wenn es nicht für ihn selbst bestimmt ist. Das Weitersenden erfolgt entsprechend der Routing-Tabellen, die genaue Auskunft darüber geben, welches Zielhosts über welchen weiteren Weg erreichbar sind. Alle hier nicht explizit definierten Ziele sind über die Default-Route erreichbar (so diese angegeben ist) oder werden gedroped.

OK.

Dein Verständnis-Problem liegt vermutlich aus dem Source-Host. Dieser verpackt Pakete, die über ein Gateway laufen sollen, in einen neuen IP-Header, der direkt an das Gateway gerichtet ist. Damit kann dann auch jeder Router, der nur den Weg zu diesem Gateway kennt, das Paket exakt zustellen.

Und wieder "Nö". Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

Marcus Glöder, Sonntag, 18. April 2004 02:49:

Hallo Matthias,

Am Samstag, 17. April 2004 11:49 schrieb Matthias Houdek:

...

Marcus Glöder, Samstag, 17. April 2004 01:29:

...

Oder bin ich jetzt schon auf dem falschen Dampfer?

Nein, ist schon richtig. Aber die Pakete werden doch zum Routen über ein Gateway verpackt: .______________________.

| Header mit Ziel-IP | | des Routers | Das intern verschickte Paket ist |----------------------| um den zusätzlichen Header größer |,--------------------,| als das Original-Paket. | || Header mit Ziel-IP || || des Internet-Hosts || Deshalb muss man z.B. den || MTU-Wert --------------------|| bei DSL über interne || Router ent- Daten des Paketes || sprechend || heruntersetzen. .... ||

Damit ist das (verpackte) Paket primär an das Gateway zum Internet (hier der WLAN-Router) adressiert und die Router im lokalen Netz müssen dafür nur die Route zu diesem Ziel-Host kennen.

[...]

Dein Verständnis-Problem liegt vermutlich aus dem Source-Host. Dieser verpackt Pakete, die über ein Gateway laufen sollen, in einen neuen IP-Header, der direkt an das Gateway gerichtet ist. Damit kann dann auch jeder Router, der nur den Weg zu diesem Gateway kennt, das Paket exakt zustellen.

Du meinst also, wenn PC1 ein Paket zum Internet-Host 134.95.100.203 versenden will, dann packt er das IP-Paket mit der Zieladresse 134.95.100.203 in ein weiteres IP-Paket ein, das als Zieladresse die Adresse des Standard Gateways trägt, den Du auf PC1 angegeben hast, bei Dir wäre das dann 192.168.2.1 (der Wireless-LAN-Router). Der PC-Router "sieht" nur dieses zweite IP-Paket mit der Adresse 192.168.2.1 und leitet es dann eben an den Wireless-LAN Router weiter. Der Wireless-LAN-Router packt (Deiner Darstellung nach) das ursprüngliche IP-Paket mit der Zieladresse 134.95.100.203 wieder aus und jagt es durch sein WAN-Interface.

Naja, nicht ganz. Ich hab in meiner Darstellung wohl ein wenig "übertrieben". Es ist kein komplett neuer Header (das wäre nur bei Tunnelung, z.B. VPN, der Fall - ich hatte mal wieder nur meine derzeitigen Kämpfe mit mehreren z.T. verschachtelten VPN-Strecken im Hinterkopf und Alexander hat ja auch schon drauf hingewiesen). Nur der IP-Header erhält Routing-Informationen, über die dann aber der PC-Router das Teil weiterleiten sollte. Klappt bei mir jedenfalls an zwei Standorten prima: LAN #1 --, LAN #2 --->- Router - Server LAN #3 --´ | Gateway ---------> Internet | DMZ (Mailserver, Web-Server) Alle Clients haben das Gateway als Default-Route, der Router selbst hat keine Default-Route.

OK, das wäre, so es denn stimmen würde, eine Erklärung für Deine Art der Konfiguration. Ich habe jetzt extra noch mal in meinem ICND-Buch [1] nachgesehen. Dort steht nichts von einem derartigen Header-Zauber. Meiner Meinung nach gibt es derartige "doppelte Verpackungen" bei ganz gewöhnlichem IP-Routing (davon sprechen wir ja) auch gar nicht.

Jaja, ich nehm ja alles zurück ;-) Übrigens gibt es das mit dem 2. Header auch beim Routing: Wenn IPv6-Pakete durch ein IPv4-Netz geroutet werden muss. Da werden dann wirklich die IPv6-Pakete in ein IPv4-Paket verpackt. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Hallo Matthias. * Sonntag, 18. April 2004 um 11:37 (+0200) schrieb Matthias Houdek:

Nur der IP-Header erhält Routing-Informationen, über die dann aber der PC-Router das Teil weiterleiten sollte.

Das ist zumindest missverständlich: Der IP-Header eines "gewöhnlichen" IP-Paketes enthält keinerlei Routing-Informationen ausser der Zieladresse des Paketes. (Es gibt zwar die Möglichkeit mit den IP-Optionen "* Source Routing" Routing-Informationen dem Paket mitzugeben, aber 1.) gibt es AFAIK nur wenige (Netzwerk-) Programme, die solche Pakete erzeugen können und 2.) verwirft jeder vernünftig konfigurierte Router solche Pakete.)

Klappt bei mir jedenfalls an zwei Standorten prima:

LAN #1 --, LAN #2 --->- Router - Server LAN #3 --´ | Gateway ---------> Internet | DMZ (Mailserver, Web-Server)

Alle Clients haben das Gateway als Default-Route, der Router selbst hat keine Default-Route.

Es wundert mich, dass das so funktioniert. Mit "normalem" IP-Routing hat das aber IMHO nichts zu tun. Und du hast sicher keinen Tunnel zwischen LAN-Clients und Gateway, oder den Router als Bridge o.ä. konfiguriert? Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

Hallo Matthias. * Sonntag, 18. April 2004 um 20:55 (+0200) schrieb Matthias Houdek:

Andreas Koenecke, Sonntag, 18. April 2004 19:29:

Mir war aber so, als wenn ich vor einiger Zeit etwas darüber gelesen hab, dass im Header auch der "Next-Hop" mitgegeben wird.

Ausser der erwähnten "Source Routing"-Optionen wüsste ich nicht, wo das im IP-Header stehen sollte.

Clientseitig wird über DHCP nur die eigene IP aus dem entsprechenden Subnetz, die IP des Linux-Gateways als DNS und default-Route sowie die Route zum Server-Subnetz und Gateway über den Router (IIRC, kann ich morgen noch einmal genau nachsehen).

Und wo steht der DHCP-Server?

Was auf dem Novell genau läuft - ??? Aber da bin ich jetzt auch neugierig, denn eigentlich dürfte es nicht gehen, wenn wirklich keine Routing-Infos mitgehen, sondern nur die Ziel-IP im Internet.

Man ist das spannend - und das zum Sonntagabend ;-) Ich glaub ich war noch nie so scharf drauf, am Montag wieder arbeiten zu dürfen *g*

Jepp, das ist ziemlich interessant -- halte uns bitte auf dem Laufenden... Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

Hallo Matthias, hallo Andreas, Am Sonntag, 18. April 2004 20:55 schrieb Matthias Houdek:

Stimmt, ich hab mal nachgeschlagen und irgendwann auch was gefunden. Mir war aber so, als wenn ich vor einiger Zeit etwas darüber gelesen hab, dass im Header auch der "Next-Hop" mitgegeben wird. Das hat mir dann auch plausibel gemacht, warum es in meinen beiden Netzen, in denen derart geroutet wird, funxt. Ich hab das dann irgendwie so verinnerlicht, denn es klang irgendwie logisch.

IP-Header-Felder (in dieser Reihenfolge): IP-Header-Feld Beschreibung Länge ----------------------------------------------------------------------- Version Versionsnummer 4 Bits Header-Länge Header-Länge in 32-Bit-Wörtern 4 Bits Priorität und Art Wie der Datenblock gehandhabt 8 Bits des Dienstes werden sollte Totale Länge Totale Länge (Header plus Daten) 16 Bits Identifikation Eindeutiger IP-Datenblock-Wert 16 Bits Flags Legt fest, ob Fragmentierung 3 Bits auftreten kann. Fragment Offset Fragmentierung von Datenblöcken 13 Bits um unterschiedliche MTUs im Internet zu erlauben. TTL Lebenszeit 8 Bits Protokoll Protokoll der höheren Schicht (4), 8 Bits das den Datenblock sendet Header-Prüfsumme Prüfung der Unversehrtheit des 16 Bits Headers Quell-IP-Adresse 32-Bit-Quell-IP-Adressen 32 Bits Ziel-IP-Adresse 32-Bit-Ziel-IP-Adressen 32 Bits IP-Optionen Netzwerk testen, Fehler suchen Sicherheit und anderes wenn nicht vorhanden 0 Bits wenn vorhanden 32 Bits Daten Daten des Protokolls der höheren Variiert Schicht ----------------------------------------------------------------------- Tabelle nach meinem ICND-Buch, Seiten 260 und 261. Ohne das Options-Feld ist ein IP-Header also 20 Bytes lang (IPv4). Von dem "Mitgeben" eines Next-Hop kann ich in dem Header nichts entdecken.

...

...

Klappt bei mir jedenfalls an zwei Standorten prima:

LAN #1 --, LAN #2 --->- Router - Server LAN #3 --´ | Gateway ---------> Internet

DMZ (Mailserver, Web-Server)

Alle Clients haben das Gateway als Default-Route, der Router selbst hat keine Default-Route.

Es wundert mich, dass das so funktioniert. Mit "normalem" IP-Routing hat das aber IMHO nichts zu tun. Und du hast sicher keinen Tunnel zwischen LAN-Clients und Gateway, oder den Router als Bridge o.ä. konfiguriert?

Hm, die Router sind nicht von mir. Der Router wie auch die Server (rechts) sind Novell-Kisten, das Routing war alles so eingestellt. An Stelle des Gateway-Linux hing allerdings ein ISDN-Router von Cisco.

Novell? Laufen Dein LAN-Router (so nenn' ich den jetzt mal) und Deine Server unter IPX/SPX (alte Novell-Versionen) oder unter TCP/IP (v4) (neuere Novell-Versionen)? Wir haben immer über IP gesprochen. Bei IPX müsste ich mich erst mal über den Header schlau machen. Aber soviel ich weiß, kann hier außer der (IPX-)Quell- und Ziel-Adresse auch keine weitere Routing-Information mitgegeben werden.

Mann, ist das spannend - und das zum Sonntagabend ;-) Ich glaub ich war noch nie so scharf drauf, am Montag wieder arbeiten zu dürfen *g*

Ja, wir sind alle gespannt (ich jedenfalls)... Viele Grüße, Marcus

Hallo Matthias, Am Montag, 19. April 2004 07:21 schrieb Matthias Houdek:

Marcus Glöder, Sonntag, 18. April 2004 22:31:

...

IP-Header-Felder (in dieser Reihenfolge):

[Aufbau des Headers - gelöscht, da Chaos im Umbruch *g*]

Das ist schade, ich habe mir so viel Mühe mit der Tabelle gegeben, und bei mir sah sie schön aus... Aber sag mal, was für eine maximale Zeilenlänge hast Du denn? In meinem KMail habe ich den Zeilenumbruch bei Spalte 72 eingestellt. Das habe ich bei der Tabelle auch fast vollständig ausgenutzt: sie ist genau 71 Zeichen breit. Wenn Dein Mail-Client bei z.B. 70 oder gar schon bei 65 Zeichen umbricht, ist das mit dem "Chaos im Umbruch" klar. Wenn Du also dein Mail-Programm zum lesen der Mail auf 72 Zeichnen (um)stellst, müsste die Tabelle wieder gut zu erkennen sein. (Beim Antworten kommt allerdings noch ein ">" und ein Leerzeichen dazu, d.h. hier müsste die zulässige Zeilenlänge auf 74 Zeichen erhöht oder in jeder Zeile der Tabelle zwei Zeichen gelöscht werden...) (Ich mach' nie wieder so breite Tabellen *grummel*.)

Vielleicht geht sowas im Bereich IP-Optionen mit (als "Fehler"-Meldung, da der Next-Hop nicht direkt erreichbar ist?)

Wäre möglich. Dafür müsste ich jetzt aber genauer wissen, was in das Options-Feld alles hineingeschrieben werden kann. Siehe aber die Aussage von Andreas zu diesem Punkt:

(Es gibt zwar die Möglichkeit mit den IP-Optionen "* Source Routing" Routing-Informationen dem Paket mitzugeben, aber 1.) gibt es AFAIK nur wenige (Netzwerk-) Programme, die solche Pakete erzeugen können und 2.) verwirft jeder vernünftig konfigurierte Router solche Pakete.)

...und direkt als Antwort auf Deine Vermutung:

Außer der erwähnten "Source Routing"-Optionen wüsste ich nicht, wo das im IP-Header stehen sollte.

Weiter schreibst Du:

Es ist ein Netware 5.0 und läuft mit IP.

Das ist schön. Mit IP (genauer: IPv4) kenne ich mich wenigstens einigermaßen aus... So verharre ich denn weiter in gespannter Erwartung. Viele Grüße, Marcus

Hallo Matthias. * Dienstag, 20. April 2004 um 22:49 (+0200) schrieb Matthias Houdek:

Also: Es sind alle Netzwerkkarten sowohl an IP als auch an IPX gebunden. Die Clients (zumindest bei denen, die ich mir angesehen habe) sind auf IPX mit IP-Unterstützung eingerichtet.

Die Linux-Server und auch das Linux-Gateway laufen alle völlig ohne IPX, eventuelle Anbindung an die Novell-Server erfolgt nur über das IP-Protokoll (Adresse wird im nwmount-Befehl mitgegeben).

Was macht nun dieses IPX mit IP-Unterstützung beim Novell? Werden hier eventuelle IP-Pakete durch das IPX-Protokoll getunnelt? Das wäre dann eine Erklärung.

So etwas vermute ich auch, allerdings kenne ich mich mit IPX (auch) überhaupt nicht aus...

Beim Routing habe ich auf dem Novell nur die statischen Routen in die einzelnen Segmente gefunden, keine default-Route, kein RIP (das muss aber nix bedeuten, falls diese Angaben evtl. wieder ganz woanders versteckt sind. Ich hab nur alles unter INETCFG durchstöbert.

Nach oberflächlicher Google-Suche ist RIP AFAIR fester Bestandteil von IPX. Gruß Andreas -- Andreas Könecke "Andreas Koenecke " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

Andreas Koenecke, Mittwoch, 21. April 2004 21:48:

Hallo Matthias.

* Dienstag, 20. April 2004 um 22:49 (+0200) schrieb Matthias Houdek:

...

Also: Es sind alle Netzwerkkarten sowohl an IP als auch an IPX gebunden. Die Clients (zumindest bei denen, die ich mir angesehen habe) sind auf IPX mit IP-Unterstützung eingerichtet.

Die Linux-Server und auch das Linux-Gateway laufen alle völlig ohne IPX, eventuelle Anbindung an die Novell-Server erfolgt nur über das IP-Protokoll (Adresse wird im nwmount-Befehl mitgegeben).

Was macht nun dieses IPX mit IP-Unterstützung beim Novell? Werden hier eventuelle IP-Pakete durch das IPX-Protokoll getunnelt? Das wäre dann eine Erklärung.

So etwas vermute ich auch, allerdings kenne ich mich mit IPX (auch) überhaupt nicht aus...

...

Beim Routing habe ich auf dem Novell nur die statischen Routen in die einzelnen Segmente gefunden, keine default-Route, kein RIP (das muss aber nix bedeuten, falls diese Angaben evtl. wieder ganz woanders versteckt sind. Ich hab nur alles unter INETCFG durchstöbert.

Nach oberflächlicher Google-Suche ist RIP AFAIR fester Bestandteil von IPX.

Ja, bei IPX braucht man sich um Routing keine großen Gedanken zu machen. Dafür ist es schwer, Netzsegmente sauber voneinander zu trennen, dass sie nicht erreichbar sind - ich musste das mal und hab letztendlich alles auf IP umgestellt *g*. Bleibt die Frage, ob die IP-Pakete einfach über IPX getunnelt werden. Ich dachte immer, es laufen dann beide Protokolle parallel. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Andreas Koenecke, Donnerstag, 22. April 2004 12:21:

* Donnerstag, 22. April 2004 um 07:29 (+0200) schrieb Matthias Houdek:

...

Bleibt die Frage, ob die IP-Pakete einfach über IPX getunnelt werden. Ich dachte immer, es laufen dann beide Protokolle parallel.

Das hätte ich auch angenommen. Vielleicht wäre es einmal den Versuch wert, einen der Clients mit Knoppix o.ä. zu booten, IP und Routing manuell (also ohne DHCP) aufzusetzen und zu sehen, ob der Client dann noch das Gateway erreichen kann.

Das wird wahrscheinlich nicht klappen, denn irgendwie hat mich eure Argumentation bzgl. des IP-Routings dann doch überzeugt. Ich hab es hier zu Hause auch mal kurz mit drei Rechnern gebastelt (Knoppix-boot auf den PCs meiner Söhne), weil es mich ja auch interessiert hat. Zum Routing im Novell-Netz: Bei der Installation der Netware-Clients für Windows gibt es drei grundlegende Einstellungen: reines IPX ohne IP, IPX mit IP-Unterstützung (das ist hier so installiert) und IPX plus IP. Ich vermute mal, dass TCP mit IP-Unterstützung doch so eine Art Tunnelung ist, um über ein reines IPX-Netzwerk trotzdem z.B. ins Internet zu kommen. Testen könnte ich das eher, indem ich auf dem Novell für die Netzwerkkarten, an denen die Clients hängen, die Bindung an das IP-Protokoll abschalte. Muss ich mir aber mal ein ruhiges Wochende aussuchen, sonst gibt es mächtig Touble, wenn plotzlich alles steht *g*. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu

Hallo Matthias, Am Dienstag, 20. April 2004 22:49 schrieb Matthias Houdek:

Marcus Glöder, Dienstag, 20. April 2004 21:21:

...

Aber sag mal, was für eine maximale Zeilenlänge hast Du denn?

*nachschau* - 70 Zeichen.

...

In meinem KMail habe ich den Zeilenumbruch bei Spalte 72 eingestellt. Das habe ich bei der Tabelle auch fast vollständig ausgenutzt: sie ist genau 71 Zeichen breit.

So ein Ärger...

...

(Ich mach' nie wieder so breite Tabellen *grummel*.)

Och, ich hätte es ja auch überarbeiten können. Hatte aber keine Lust ;-)

Kann ich nachvollziehen ;-).

Was macht nun dieses IPX mit IP-Unterstützung beim Novell? Werden hier eventuelle IP-Pakete durch das IPX-Protokoll getunnelt? Das wäre dann eine Erklärung.

Könnte sein. Mit IPX kenne ich mich aber, wie gesagt, nicht wirklich aus. Siehe aber auch die Antwortmail von Andreas.

P.S. @Marcus: PM an mich -> Siehe unten.

Das war offensichtlich eine Unachtsamkeit von mir, sorry. Bisher war es so, dass im meinem KMail sowohl bei "Allen antworten" als auch bei "An Mailingliste antworten" im Briefkopf unter "An:" sowohl die persönliche Absender-Adresse (in diesem Fall eben "linux@houdek.de") als auch die Adresse der SuSE-Mailingliste (d.h. "suse-linux@suse.com") erschienen ist. Ich habe dann immer die persönliche Adresse gelöscht, die Mail geschrieben und nach einer Rechtschreibkontrolle abgeschickt. Bei Dir habe ich Schnarchnase das Löschen Deiner persönlichen Adresse vergessen. Da mir das jetzt zum zweiten oder dritten Mal passiert ist (bei verschiedenen Leuten), habe ich in der KMail-Hilfe nach einer Möglichkeit gesucht, dieses Verhalten bei "An Mailingliste antworten" abzustellen - und bin fündig geworden. Nun habe ich den Ordner, in den ich die Mails für die Liste (per Filter) verschiebe über -> rechte Maustaste -> Eigenschaften... mit der Mailingliste suse-linux@suse.com verknüpft. Jetzt kommt bei "An Mailingliste antworten" nur noch die Listenadresse im "An:"-Feld. So schnell wird mir das also nicht wieder passieren. ;-) Ich hatte keine "Entschuldigungs-PM" an Dich geschickt, weil ich aufgrund Deines "Hinweis 1" annahm, dass a) die "Entschuldigungs-PM" dann auch automatisch vernichtet würde, Du sie also gar nicht zu sehen bekommst, und b) die "unbeabsichtigte" PM wahrscheinlich von einem von Dir eingerichteten Filter sowieso schon ins Nirwana geschickt worden ist, bevor sie Dich überhaupt nerven kann... Viele Grüße, Marcus

Hallo zusammen, am Freitag, 16. April 2004 01:01 schrieb ich:

Zur Not würde ich vorschlagen, auf dem PC-Router NAT (Network Address Translation) einzurichten. [...] Allerdings weiß ich nicht, wie die Syntax dafür unter Linux/Unix aussieht. Nach dem, was ich in diesem Thread über Masquerading gelesen habe, könnte es auch sein, dass das einen ähnlichen Zweck erfüllt (und deshalb hier auch eingesetzt werden könnte). Über Masquerading weiß ich allerdings soviel, wie ein Fisch von einem Fahrrad, da müssten dann andere weitermachen.

Über eine Google-Suche mit den Suchwörtern "Network Address Translation" Linux Syntax habe ich folgende Links gefunden: Links zu NAT ------------ [1] http://www.netfilter.org/documentation/HOWTO//netfilter-double-nat-HOWTO.htm... (englisch!) [2] http://www.linuxhaven.de/dlhp/HOWTO/DE-Netzwerk-HOWTO-8.html -> Abschnitt 8.3 [3] http://www.e-infomax.com/ipmasq/howto-trans/de/DE-ipmasq-HOWTO-1_84-7.html -> Abschnitt 7.5 [4] http://linux.nbs.at/ipmasq/DE-ipmasq-HOWTO-1_65-7.html -> Abschnitt 7.5 (fast textidentisch) [5] http://www.se.openbsd.org/faq/de/faq6.html#NAT (bezieht sich auf BSD) [6] http://openbsd.appli.se/faq/de/faq6.html#6.3 (bezieht sich auf BSD) [7] http://joerg.fruehbrodt.bei.t-online.de/netfilter.html (unter anderem Konfiguration von NAT mittels iptables) Links zu Masquerading --------------------- [8] http://www.linuxnetmag.com/de/issue7/m7dnsmasq1.html [10] http://home.t-online.de/home/hubertus.sandmann/l_masq.htm [11] http://www.leo.org/~loescher/tips.html#ipmasq [12] http://www.linuxhq.com/ldp/howto/IP-Masquerade-HOWTO/ (englisch!) [13] http://www.e-infomax.com/ipmasq/howto-trans/de/DE-ipmasq-HOWTO-1_84.html (deutsch!) [14] http://www.linuxfocus.org/Deutsch/January2000/article134.shtml#134lfindex14 [15] http://home.arcor.de/klaus-uwe/masquera.htm [16] www.m-janus.de/security/library/ dateien/firewall_handbuch.pdf -> Abschnitt 9.10 Masquerading und NAT Ergebnis: Masquerading und NAT scheinen sehr ähnliche Konzepte zu sein. Jedenfalls wird in vielen Web-Seiten davon gesprochen, Masquerading sei die Linux-Bezeichnung für NAT, Masquerading und NAT seien ähnlich, Masquerading sei eine bestimmte Form von NAT oder ähnliches. Das deutsche Masquerading-HOWTO hebt (in den FAQs) dagegen explizit auf die Unterschiede zwischen Masquerading, Proxy-Server und NAT als unterschiedliche Methoden zur Erreichung desselben Ziels ab. Es gibt wohl auch (seit Kernel 2.2) eine NAT-Implementierung für Linux. Zitat aus Link [2]: --- schnipp --- Ist der Kernel richtig konfiguriert und sind alle Tools installiert, kann man mit folgendem Kommando die Adressübersetzung für Pakete einrichten. ip route add nat <ext-addr>[/<masklen>] via <int-addr> Diese Regel wird in allen eingehenden Paketen mit der Zieladresse »ext-addr« (also die Adresse, die von außen z.B. vom Internet sichtbar ist) die Zieladresse nach »int-addr« umändern (das ist eine Adresse im internen Netzwerk, hinter dem Gateway bzw. der Firewall). Das Paket wird dann gemäß der lokalen Routing Regeln weitergeleitet. Es ist möglich, entweder einzelne oder ganze Bereiche von Hostadressen zu verändern. Beispiele: ip route add nat 195.113.148.34 via 192.168.0.2 ip route add nat 195.113.148.32/27 via 192.168.0.0 Das erste Kommando macht die interne Adresse 192.168.0.2 nach außen hin als 195.113.148.34 zugänglich. Das zweite Beispiel zeigt das Abbilden des Adreßbereiches 192.168.0.0-31 auf den Bereich 195.113.148.32-63. --- schnapp --- Link [7] beschreibt unter anderem auch die Konfiguration von NAT über iptables. Link [1] bietet ein Beispiel dafür. Viele Grüße an alle, Marcus

------------------------------------------------------------------------- Der folgende Text ist ziemlich lang. Ich denke aber es lohnt sich, ihn zu lesen. Er enthält einige ganz grundsätzliche Erklärungen darüber, was Routing eigentlich ist, wie es funktioniert, was der Unterschied zwischen statischem und dynamischem Routing ist und was Routing-Protokolle damit zu tun haben (die "Basics"). Nach der Lektüre ist, hoffe ich, einiges klarer... ------------------------------------------------------------------------- Hallo Andreas, Am Freitag, 16. April 2004 19:27 schriebst Du:

Könnt ihr mir noch kurz sagen, was RIP denn ist und ob nicht eine Lösung wäre RIP auf meinem PC--Router zu installieren?

RIP ist ein sogenanntes Routing-Protokoll. Ein Router ist ein Gerät, das Pakete [1] von einem lokalen Netzwerk (LAN) in ein anderes lokales Netzwerk (LAN) weiterleitet. Mit anderen Worten: die Grenzen eines LANs werden immer durch einen oder mehrere Router definiert. Damit ein Router diese Weiterleitung vollbringen kann, muss er wissen, aus welchen seiner Schnittstellen er die Pakete hinausjagen muss, die für ein bestimmtes Zielnetzwerk bestimmt sind. Er muss also für jedes Zielnetzwerk einen Eintrag in einer Tabelle haben, der ihm genau diese Information bereitstellt. Die Syntax dieser Tabellen kann von Betriebssystem zu Betriebssystem variieren, die darin enthaltenen Informationen sind aber immer gleich oder doch recht ähnlich. (Für den Aufbau von Routing-Tabellen unter Linux/Unix schau im Admin-Handbuch nach und hier: http://www.linuxhaven.de/dlhp/HOWTO/DE-Netzwerk-HOWTO.html (insbesondere Abschnitt 4.7 Routing) Am Beispiel Deines PC-Routers könnte diese Routing-Tabelle - so wird sie nämlich genannt - abstrakt (unabhängig von jeder besonderen Syntax) so aussehen: Zielnetzwerk Next-Hop-Router Schnittstelle Entfernung ----------------------------------------------------------------- 192.168.1.0 /24 -- eth0 0 Hops [2] 192.168.2.0 /24 192.168.2.1 wlan0 0 Hops 0.0.0.0 /0 192.168.2.1 wlan0 -- Dabei ist das "Netzwerk" 0.0.0.0 mit der Subnetzmaske 0.0.0.0 (oder eben /0) ein Dummy für "alle restlichen Netzwerke". Die einzelnen Einträge (Zeilen) in der Routing-Tabelle sind nun die Routen. Der letzte Eintrag ist also die Default-Route (auch Standard-Gateway oder einfach nur Gateway genannt), die dem Router sagt, wo Pakete hingeschickt werden sollen, für deren Zielnetzwerk er keinen expliziten Eintrag in der Routing-Tabelle (keine spezifische Route) besitzt, in der Hoffnung, dass der als Standard-Gateway definierte Router (hier: der Wireless-LAN-Router mit der IP-Adresse 192.168.2.1) schon wissen wird, wohin er die Pakete dann weiterleiten soll. Die Frage ist nun: Wie kommt der Router an die Informationen, die in seiner Routing-Tabelle stehen? Nun, dafür gibt es drei mögliche Wege: 1. Mit jedem seiner Schnittstellen steht der Router "mit einem Füßchen" in einem anderen Netzwerk. Aus der IP-Adresse und der Subnetzmaske der jeweiligen Schnittstelle kann der Router ohne sonstige Hilfsmittel herausfinden, zu welchen Netzwerken diese Schnittstellen gehören, mit anderen Worten: welche Netzwerke direkt mit ihm verbunden sind. --> Bei Netzwerken, die nicht direkt mit dem Router verbunden sind und insofern als "entfernte" Netzwerke gelten können (wie das Netzwerk 192.168.1.0 /24 für den Wireless-LAN-Router), wird die Sache komplizierter. Hier gibt es zwei weitere Möglichkeiten, wie der Router an seine Informationen kommt: 2. Entweder die Routen (Einträge in seiner Routing-Tabelle) werden ihm vom Netzwerk-Admin (also einem Menschen, in Deinem Falle bist das Du) explizit mitgeteilt (zugewiesen). Das ist statisches Routing, von dem in diesem Thread schon so viel die Rede war. Die Routen sind statisch, weil sie sich nur verändern, wenn der Admin etwas mit ihnen macht. 3. Oder die Router "entdecken" selbstständig Routen zu entfernten Netzwerken und löschen Routen zu Netzwerken, die nicht mehr erreichbar sind. Das ist dynamisches Routing ("dynamisch", weil sich die Routing-Tabellen ohne Zutun des Admin ändern können). Genaugenommen "entdecken" die Router die Routen aber nicht selbst, sondern das machen besondere Protokolle, die Routing-Protokolle. Im einfachsten Fall funktioniert das dann so, dass das Routing-Protokoll periodisch die Routing-Tabelle des eigenen Routers an alle direkt benachbarten Router schickt, wo dasselbe Routing-Protokoll diese Informationen mit der eigenen Routing-Tabelle abgleicht. So breiten sich die Informationen über "entfernte Routen" wellenförmig über das ganze Netzwerk aus, wie in menschlichen Ortschaften sich Gerüchte ausbreiten ("Routing by rumor"). RIP (Routing Information Protocol) ist nun ein solches Routing-Protokoll, und es arbeitet genau auf die beschriebene Art und Weise. Übrigens ist es das älteste Routing-Protokoll überhaupt, und in kleineren Netzwerken verrichtet es immer noch seinen Dienst ("old but stable"). Als RIP erfunden wurde waren die üblichen Netzwerke noch sehr viel kleiner als heute und es wurden auch geringere Datenmengen über das Netzwerk geschickt. Mit den heute z.B. in großen Unternehmen üblichen komplexen Netzwerken kann RIP nicht vernünftig umgehen, und zudem erzeugt es gerade in großen Netzwerken durch das ständige Hin- und Herschicken der Routing-Tabellen einen ganz erheblichen administrativen Verkehr [3]. Deshalb sind andere Routing-Protokolle - wie OSPF - entwickelt worden, die beide Nachteile beheben (OSPF arbeitet auf eine völlig andere Weise als RIP. Das jetzt zu erklären würde aber endgültig den Rahmen sprengen). Soweit zu der Frage, was RIP ist. Nun zu der Frage, ob es Dein Problem beheben könnte. Dein Netz ist so klein und übersichtlich, dass RIP keinerlei Probleme haben dürfte, darin zu arbeiten. Aber aus dem gleichen Grund kannst Du auch ebenso problemlos vollständig statisches Routing betreiben, ohne dabei den Überblick zu verlieren. Das hat zwei Vorteile. Der vielleicht unwichtigere ist, dass Du administrativen Verkehr einsparst. Entscheidender ist aber, dass Du dann immer weißt, wie die Pakete genau ihren Weg über die einzelnen Geräte durch dein Netzwerk nehmen. Das ist der entscheidende Grund, weshalb Matthias Houdek in seiner Mail vom 16. April, 7:11 Uhr, meint, dass er niemals Routing-Protokolle wie RIP einsetzt, sondern immer statisch routet (das geht selbstverständlich nur bis zu einer gewissen Größe/Komplexität eines Netzwerkes). Die größere Kontrolle über das, was in Deinem Netzwerk eigentlich geschieht ist der erste Grund, weshalb ich meine, dass Du auf den Einsatz von RIP verzichten solltest. Der zweite Grund ist:

Klingt vielleicht doof, etwas installieren oder einrichten zu wollen, von dem ich keine Ahnung habe, was es ist...

Du solltest _nie_ etwas einsetzen oder tun, was Du nicht vorher verstanden hast. Das gilt für Netzwerkadministration genauso wie sonst im Leben. Dass heißt also, zuerst Admin-Handbuch, HOWTOs, Man-Pages und was Du sonst noch so in die Finger bekommst lesen, versuchen, das Gelesene zu verstehen, nachdenken, seine Gedanken strukturieren (vielleicht mit Papier und Bleistift als Denkhilfe), und erst ganz zum Schluss, wenn Dir alles klar ist, zur Tat schreiten und deine Geräte administrieren. Ich weiß, wer aus der Windows-Welt kommt, für den ist es schwer, sich an eine solche Vorgehensweise zu gewöhnen. Ich habe da auch schon Lehrgeld zahlen müssen...

...

Zur Not würde ich vorschlagen, auf dem PC-Router NAT (Network Address Translation) einzurichten. [...] Wenn diese Möglichkeit funktioniert würde ich das auch tun - nur sind wir da eben wieder in Bereichen, die ich nicht kenne....

Vielleicht gibt es ja noch jemanden, der Rat weiß?

Nun, ja, vielleicht kennst Du gerade das besser als Du glaubst (nur unter einem anderen Namen: Masquerading). Ich zitiere jetzt mal die Reaktion von Matthias auf genau diese Textstelle von mir und meine Antwort darauf:

...

Genau so läuft es ja im Moment. Masquerading (eigentlich S-NAT) ist ja auch eine Funktion des netfilter. Leider wurde es hier nur gleichzeitig mit Port-Sperren genutzt, wodurch damit andere Netzwerkfunktionen verhindert wurden. Wird dann netfilter (hier über SuSE-Firewall) abgeschaltet, funktioniert der PC-Router wieder als Server im Netz ohne Einschränkung, aber das Masquerading ist auch abgeschaltet.

Ja, gut. In dem Fall wäre es wohl die beste Lösung, netfilter eingeschaltet zu lassen, mittels netfilter S-NAT zu konfigurieren und _alle_ TCP/UDP-Ports zu öffnen (wir wollen ja nur die Adressenumsetzung, nicht die Firewall!). Das ist zwar nicht besonders schön, aber in Anbetracht der fehlenden Möglichkeit, auf dem Wireless-LAN-Router statische Routen einzurichten, wohl die einzige Möglichkeit (soweit ich das sehen kann...).

Also, zusammengefasst, Du lässt die SuSE-Firewall eingeschaltet, lässt auch das Masquerading aktiv (bzw. aktivierst es), schaltest aber _alle_ Ports frei. das müsste dann eigentlich gehen.

Trotzdem Danke für die viele Mühe

Andy

Bitte, und viele Grüße, Marcus Anmerkungen: ------------ [1] Die Informationen, die über das Netz von einem Ort zu einem anderen gelangen sollen, werden immer in kleine Puzzlestücke zerlegt, dann "häppchenweise" über das Netzwerk übertragen und am anderen Ende wieder zusammengesetzt. [2] Ein Hop ist ein Schritt oder Sprung von einem Router zum nächsten, bis das Zielgerät erreicht ist. Hops können als Entfernungsmaß eingesetzt werden. Andere mögliche Maße wären z.B. die Bandbreite oder die Auslastung einer Leitung. Auch kombinierte Maße sind möglich. Das hier ist nur ein Beispiel... [3] Administrativer Verkehr ist der über das Netzwerk gehende Verkehr, der durch die Protokolle verursacht wird, die nötig sind, um so eine komplexe Struktur wie ein Netzwerk aufrecht zu erhalten. Es gibt eine ganze Menge solcher Protokolle. Der Gegensatz zu administrativem Verkehr ist interessanter Verkehr. Dabei handelt es sich um den Verkehr, den die Menschen erzeugen, die vor den Client-Computern sitzen und das Netzwerk benutzen (z.B. um Dateien auszutauschen, auf einem Netzwerk-Drucker zu drucken oder im Web zu surfen). Die Netzlast, die durch administrativen Verkehr entsteht, wird Overhead genannt. Obwohl eine ganze Menge administrativer Verkehr notwendig ist, um ein Netzwerk funktionsfähig zu erhalten, bemühen sich alle Administrator/inn/en darum, den Overhead möglichst gering zu halten. Schließlich ist ein Netzwerk nicht für sich selbst da...

Am Mittwoch, 14. April 2004 21:58 schrieb Marcus Glöder: Hallo Marcus Grundsätzlich muss ich gestehen, dass ich höchsten die Hälfte deiner Ausführungen verstanden habe. Ist das denn wirklich so schwer, oder bin ich einfach zu doof? (rhetorische Frage!!) Was mir nicht in den Kopf will und ich auch nach Lesen von man route absolut nicht verstehe, wie ich den PC-Router dazu bringe Datenpakete von einem Subnetz 192.168.2.0 in das Subnetz 192.168.1.0 zu bringen. Hier mal meine Routing-Tabellen PC1 Ziel Router Genmask Flags Metric Ref Use Iface localhost * 255.255.255.0 U 0 0 0 eth0 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 Laptop Ziel Router Genmask Flags Metric Ref Use Iface localhost * 255.255.255.0 U 0 0 0 wlan0 default 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0 PC-Router Erstellt mit route add -net 192.168.2.0 netmask 255.255.255.0 dev wlan0 route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0 Die defaultroute auf 192.168.2.1 bestand ja schon. Destination Gateway Genmask Flags Metric Ref Use Iface localhost * 255.255.255.0 U 0 0 0 wlan0 localhost * 255.255.255.0 U 0 0 0 eth0 default localhost 0.0.0.0 UG 0 0 0 wlan0 Warum steht bei default "localhost" und nicht "192.168.2.1"? Woher weiß der PC-Router nun, dass er Pakete vom WLAN-Router 192.168.2.1 an den PC1 192.168.1.2 weiterleiten soll. Genau hier hängt meines Erachtens das Problem. Und es will mir einfach kein Kronleuchter aufegen... (heul) Danke für Eure Hilfe bisher Andy

Am Donnerstag, 15. April 2004 18:27 schrieb Matthias Houdek:

Andreas Schott, Donnerstag, 15. April 2004 17:39:

...

Am Mittwoch, 14. April 2004 21:58 schrieb Marcus Glöder:

Hallo Marcus

Grundsätzlich muss ich gestehen, dass ich höchsten die Hälfte deiner Ausführungen verstanden habe. Ist das denn wirklich so schwer, oder bin ich einfach zu doof? (rhetorische Frage!!)

Was mir nicht in den Kopf will und ich auch nach Lesen von man route absolut nicht verstehe, wie ich den PC-Router dazu bringe Datenpakete von einem Subnetz 192.168.2.0 in das Subnetz 192.168.1.0 zu bringen.

Hier mal meine Routing-Tabellen

Dann schau'n wir uns die mal an:

...

PC1 Ziel Router Genmask Flags Metric Ref Use Iface localhost * 255.255.255.0 U 0 0 0 eth0 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Alle Pakete werden an den Router/das Gateway 192.168.1.1 (PC-Router) geschickt. Das ist OK so bis auf das IF in der ersten: Warum nicht lo?

...

Laptop

Ziel Router Genmask Flags Metric Ref Use Iface localhost * 255.255.255.0 U 0 0 0 wlan0 default 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0

dito. - nur dass hier direkt der WLAN-Router das Gateway ist.

...

PC-Router

Erstellt mit route add -net 192.168.2.0 netmask 255.255.255.0 dev wlan0 route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0 Die defaultroute auf 192.168.2.1 bestand ja schon.

Destination Gateway Genmask Flags Metric Ref Use Iface localhost * 255.255.255.0 U 0 0 0 wlan0 localhost * 255.255.255.0 U 0 0 0 eth0 default localhost 0.0.0.0 UG 0 0 0 wlan0

Warum steht bei default "localhost" und nicht "192.168.2.1"?

Mir geht ein Licht auf *g*. Du hast eine flachse Namensauflösung: localhost ist 127.0.0.1, bei dir verweist localhost offensichtlich auch auf die lokale Netzwerkadresse des Rechners. Damit erübrigt sich auch meine erste Frage (oben).

Gib mal am PC-Router ein: 'host 192.168.1.1' Das Ergebnis ist bestimmt: localhost

Richtig. Hat das irgendetwas mit meinem Problem zu tun? s.u.

Überprüf bitte deine /etc/hosts auf all deinen Rechnern und konfiguriere um. Oder deine DNS-Einstellungen.

Das Problem liegt eher auf Seiten des WLAN-Routers. Der muss auch wissen, wie er den PC1 erreicht (da er ja in einem anderen Netzsegment hängt). Wenn auf dem PC-Router das Masquerading läuft, dann maskiert der PC-Router die Pakete von PC1 mit seiner eigenen IP und der WLAN-Router schickt die Antwortpakete auch nur an den PC-Router zurück. Über die Maquerading-Tabelle kann dieser dann das eigentliche Ziel ausmachen und das Paket an PC1 weiterschicken.

Wenn du das Masquerading ausschaltest (mit dem Abschalten der SuSE-Firewall), dann klappt das nicht mehr. PC1 und WLAN-Router haben zwischen sich ein Gateway, das _beide_ auch als solches kennen müssen.

Das würde bedeuten ich muss meinem WLAN-Router mitteilen, dass Pakete der IP 192.168.1.1 an 192.168.2.2 zurückgeschcikt werden, weil er 192.168.1.1 nicht sieht und sie ins Nirwana schickt, oder?. Der PC-Router leitet diese dann weiter an PC1 mit 192.168.1.1 Das kann ich aber galube ich nicht einstellen am WLAN-Router. Hab zuminest nix gefunden was sich wie Routing anhört. Es ist der T-Sinus 111 WLAN-Router der Telekom - vielleicht hilft das. Wenn ich es richtig sehe, dann kann ich in dieser Konfiguration entweder ins Internet oder mit dem Laptop auf NFS zugreifen. Letzte Frage: Wenn ich die WLAN-Karte in PC1 stecke (und Firewire wieder ausbaue), dann brauche ich ja keine FW, weil ich direkt mit PC1 an den WLAN-Router gehe. Wie mache ich dann aber PC1, der dann ja wlan0 und eth0 in verschiedenen Subnetzen enthält klar, dass Anfragen vom Laptop an den Server weitergeleitet werden? Odre geht das auch nicht? Kann ich beide Netzwerkkarten ins gleiche Subnetz hängen? Dann sollte das doch gehen, oder? Viele Fragezeichen.... Andy

Hallo Andreas, Am Freitag, 16. April 2004 19:34 schriebst Du:

Ich hab nun noch den Versuch gestartet, beide Netzwerkkarten des PC-Routers ins gleiche Subnetz zu stecken

PC-Router eth0 192.168.2.11 wlan0 192.168.2.2 Gateway 192.168.2.1 über wlan0

PC1 eth0 192.168.2.10 Gateway 192.168.2.11

Dann komme ich zwar vom PC-Router zum PC1 und umgekehrt, aber nicht mehr vom PC-Router ins Internet, obwohl Gateway auf 192.168.2.1 (WLAN-Router) steht -und natürlich erst recht nicht von PC1 ins Internet

Gibt es hierfür eine Erklärung?

Bei einem Router zwei Schnittstellen ins selbe Netz zu stecken, solltest Du tunlichst lassen. Warum, wird Dir schnell klar, wenn Du meine etwas längliche "Routing-Basics-Mail" gelesen hast: grundsätzlich ist ein Router ein Gerät, dass Pakete von einem Netzwerk in ein anderes weiterleitet. Ein Router, der nur an ein einziges Netzwerk angeschlossen ist, ist wirklich überflüssig. Außerdem können dadurch inkonsistente Routing-Tabellen entstehen, so dass der Router nicht mehr weiß, welches Interface er benutzen soll, um Pakete in ein bestimmtes Netzwerk zu routen. Meistens entscheidet sich der Router dann für die "beste" Route, d.h. diejenige, von der der Router nach den Informationen, über die er verfügt, annehmen kann, dass die Datenübertragung am zuverlässigsten und/oder am schnellsten geht. Ich denke, dass in Deinem Fall genau so etwas passiert ist: der Router hat jetzt zwei Möglichkeiten, um ins Netzwerk 192.168.2.0 /24 zu gelangen. Er nimmt dann die "bessere" Route, in diesem Fall diejenige mit mehr Bandbreite. Das ist eth0. damit ist der Weg zum Wireless-LAN-Router (und zum Laptop) versperrt, sowohl für den PC-Router, als auch (erst recht) für PC1. Was du aber selbstredend tun könntest, wäre, aus dem PC1 die Firewire-Karte, so Du sie nicht brauchst, was nur Du entscheiden kannst, oder die LAN-Karte, insoweit die LAN-Schnittstelle am PC1 nicht "on Board" sein sollte, auszubauen und eine Wireless-LAN-Karte einzubauen. Dann bringst Du PC1 per Wireless-LAN direkt ins Netzwerk 192.168.2.0 /24 mit dem Wireless-LAN-Router als Standard-Gateway. Beim PC-Router entfernst Du vollständig die Routing-Funktion, so das er nur noch als File-, Druck- und Scanserver arbeitet, und zwar ebenfalls mittels Wireless-LAN-Karte direkt im Netzwerk 192.168.2.0 /24, mit dem Wireless-LAN-Router als Standard-Gateway. Irgendein Netzwerk 192.168.1.0 /24 gibt es dann nicht mehr. Es gibt dann nur noch ein Netzwerk. Dass _muss_ dann gehen. Aber das Ganze hängt selbstverständlich davon ab, ob Du auf die Firewire-Karte im PC1 verzichten kannst/willst. Das kannst Du nur selbst wissen. Ansonsten bleibt (meiner Meinung nach) nur die Lösung, bei Deiner alten Konfiguration (mit PC1 im Netzwerk 192.168.1.0 /24) beim PC-Router die SuSE-Firewall eingeschaltet zu lassen, Masquerading aktiv zu lassen oder zu aktivieren und alle Ports zu öffnen (Du willst ja nur das Masquerading und eben _keine_ Paketfilterung/Firewall).

Danke Euch

Andy

Bitte, Marcus

Am Freitag, 16. April 2004 19:34 schrieb Andreas Schott:

Am Donnerstag, 15. April 2004 19:13 schrieb Andreas Schott:

...

Kann ich beide Netzwerkkarten ins gleiche Subnetz hängen? Dann sollte das doch gehen, oder?

Ich hab nun noch den Versuch gestartet, beide Netzwerkkarten des PC-Routers ins gleiche Subnetz zu stecken

PC-Router eth0 192.168.2.11 wlan0 192.168.2.2 Gateway 192.168.2.1 über wlan0

PC1 eth0 192.168.2.10 Gateway 192.168.2.11

Dann komme ich zwar vom PC-Router zum PC1 und umgekehrt, aber nicht mehr vom PC-Router ins Internet, obwohl Gateway auf 192.168.2.1 (WLAN-Router) steht -und natürlich erst recht nicht von PC1 ins Internet

Gibt es hierfür eine Erklärung?

Ja, der PC-Router wiß nicht über welches device er die Pakete schicken soll. Nach zwei Nächten rumexperementieren und alte Doku lesen habe ich vielleicht einen Lösung gefunden: Erstens: gib dem WLanRouter mal folgende IP 192.168.2.129/24 Zweitens: Auf dem PC-Router bekommt: wlan0 die IP 192.168.2.130 und als netmask 255.255.255.128 (/25) eth0 IP 192.168.2.1 netmask 255.255.255.128 (/25) Defaultroute: default gw 192.168.2.129 wlan0 Drittens: PC1 bekommt als IP 192.168.2.10 netmask 255.255.2555.128 (/25) Defaultroute: default default gw 192.168.2.1 eth0 Viertens: Notebook bekommt IP 192.168.2.140 netmask 255.255.2555.128 (/25) Als Defaultroute: default default gw 192.168.2.1 wlan0 wenn es auch mit dem PC1 komunuzieren soll, sonst kann auch default gw 192.168.2.129 wlan0 eingetragen werden, dürfte aber keinen Geschwindigkeitsvorteile bringen, sondern man beraubt sich nur der Möglichkeit mit PC1 zu kommunizieren. Jetzt die Erklärungen dazu: Dem WLANRouter sagen wir du bist in einem C-Klasse-Netz (/24) damit wird er alls Pakete an dieses Netz über sein Internes Device abschicken. Eine Gateway angabe brauchen wir dafür nicht. Auf dem PCRouter unterteilen wir das C-Klasse-Netz in zwei kleinere Netze (/25), wobei der PCRouter über statische Routen das routing übernimmt. Das heißt, er verteilt die Pakete in die entsprechenden Unternetze. Stop so ganz stimmt das nicht, er schickt die arp-Anfragen an die entsprenchenden Unternetze raus, im Fall vom Notebook wird ganz schnell festgestellt, das das DefaultGw vom PC-Router sich im Subnetz des Notebooks befindet, und das beiden Mitteilen, so das sie direkt kommunuizieren. Ein Problem könnte noch der WLANRouter machen, nämlich dann wenn er erkennt, das sich am anderen Ende seiner Leitung nur Subnetze (/25) befinden und er so intelegent ist die automatisch einzustellen, dann hätten wir wieder die Situation wie vorher. Aber auch da bietet Linux eine Möglichkeit: IP-Aliasing. Hierfür muß am PCRouter nur folgendes gemacht werden: 1. wlan0 ganz normal mit netmask /24 einrichten. 2. jetzt muß die route von wlan0 gelöscht werden: route -del 192'.168.2.0 netmask 255.255.255.0 wlan0 3. ein weiteres logisches Device wird auf wlan0 eingerichtet: ifconfig wlan0 up 192.168.2.129 netmask 255.255.255.128 4. anlegen der Route: route add -net 192.168.2.128 netmask 255.255.255.128 wlan0 Der Rest bleibt so wie oben beschrieben, jetzt hängt für den WLANRouter auch noch ein Klasse-C-Netz in seiner Leitung. Zur Überprüfung und zur Fehleranalyse, sollte auf dem PCRouter iptraf installiert sein, damit kann man sehrschön sehen ob Pakete über die verschiedenen Dvices geschickt werden. Wenn die xlibs auf dem PCRouter installiert sind, sollte auch ethereal installiert werden, es ist wesentlich mächtiger als iptraf und ermöglicht eine Analyse der einzelnen Pakete. Und bevor jetz wieder einige zu schreien anfangen: "Auf einem Server gehört kein X!", muß ich leider sagen, daß sie irren. 1. Klar gibt es Server, wo ein ein X-Server absolut überflüssig ist: reine File und Printserver, auch eine Firewall und Router gehören in die Kategorie, aber was ist mit Applicationserver auf denen man sich mit X-Terminals anmeldet? Ein besonderer Fall sind auch Webserver, es gibt libs, die brauchen zur Bildergenerierung den Zugriff auf einen X-Server (AFAIR die qtlibs). 2. Sind die xlibs kein X-Server, und man kann den Zugriff darauf auch beschänken. 3. Zur Fehleranalyse etc. sind sie sank rpm schnell installiert und deinstalliert. Eine Anmerkungen noch zum WLAN, CUPS etc WLAN: wer keinen öfentlichen HOTSpot betreibt, sollt immer die Hardwareverschlüsselung einschalten, auch wenn sie 'keinen' wirklichen Schutz, grade bei kleinen Verschlüsselungen, so signaliertsiert sie doch den WarDrivern STOP, das Netz ist nicht für dich bestimmt, in wieweir sie sich daran halten, sei mal dahingestellt, es kann aber hinterher nicht behauptet werden "ich dacht es wäre ein öffentlich zugänglicher HotSpot". WLAN & CUPS: Grundsätzlich sollte man alle Sicherheitsmöglichkeiten von CUPS ausschöpfen, Broadcasting nur an bestimmte IP-Adressen, Freigabe von Druckern nur für definierte user. *Zusätzlich* sollte man gerade bei Tintenpi***n nur so wenig wie möglich Papier drin haben, nur soviel wie man standardmässig braucht, um mal eben schnell was auszudrucken, das kann im Fall einer unbefugten Benutzung ganz schön Geld sparen helfen. hth cu Gerald