• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Routing futsch bei Server

Ist das Thema hier richtig?

Es geht um einen LTSP-Server unter Suse Leap 42.2. Ich bin fast fertig mit der Konfiguration, da geht plötzlich das Routing nicht mehr. Das heißt, die Clients finden das Internet nicht mehr, weil es auf der externen IP liegt:

eth0 = 192.168.10.1 = extern
eth1 = 192.168.11.1 = intern (Clients)

Ich habe das deshalb so gemacht, weil das alte Netz mit 10.x noch aktiv ist und die beiden Server (auch DHCP) sich nicht ins Gehege kommen sollen. Das Internet und die Drucker hängen auch am 10er Subnetz.

Firewall ist an, IP-Forwarding ist an, Masquerading ist an.

Ich steh da ein bisschen auf dem Schlauch, wo fange ich an zu suchen? Da es bis vorgestern funktioniert hat, muss ich ja wohl irgendwas verstellt haben, die Frage ist nur, wo?

Danke für eure Geduld!

Rolf
 
OP
R

Rolf-Werner

Hacker
Ok, da kommt folgendes:

Code:
server:~ # ip route list
default via 192.168.10.2 dev eth0
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.1
192.168.11.0/24 dev eth1  proto kernel  scope link  src 192.168.11.1

Für mich sieht das ok aus, oder fehlt da was? Auf dem alten Server sieht es so aus (der hat jeweils die IP .103):

Code:
default via 192.168.10.2 dev eth0 
127.0.0.0/8 dev lo  scope link 
169.254.0.0/16 dev eth0  scope link 
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.103 
192.168.11.0/24 dev eth1  proto kernel  scope link  src 192.168.11.103

Da verwundert mich die 169.254.0.0 - was ist das? Und der hat eine Zeile für lo - die fehlt oben.
Aber ansonsten... :???:

Grüße
Rolf
 
169.254.0.0/16 gehört zu zeroconf und dient dazu Rechner, im lokalen Netz, die keine zugewiese IP haben trotzdem miteinander kommunizieren zu lassen. Guckst Du Unter Windows nennt sich das APIPA.
 
OP
R

Rolf-Werner

Hacker
169.254.0.0/16 gehört zu zeroconf und dient dazu Rechner, ...
Danke für den Link, hab ich mir durchgelesen. Ich komme aber nicht darauf, wodurch das auf dem alten Server eingerichtet wurde. In der /etc/hosts steht es auch nicht drin.

Das ist aber auch auf dem alten Server, und den lasse ich jetzt einfach so laufen, der läuft seit 5 Jahren problemlos. Es geht um den neuen, bei dem ich jetzt nur noch dieses Routingproblem lösen muss, damit ich ihn in Betrieb nehmen kann.

Grüße
Rolf
 
OP
R

Rolf-Werner

Hacker
Ich habe noch etwas gefunden. Oben genanntes Routing trifft auf den Server selbst zu, und wenn man am Server sitzt, funktioniert auch alles. Das Problem tritt ja nur bei den Clients auf, und wenn man das bei einem Client eingibt, kommt dies dabei raus:

Code:
default via 192.168.11.1 dev eth0
192.168.11.0/24 dev eth0 proto kernel scope link src 192.168.11.97

Meiner Meinung nach bedeutet das, dass der Client nach einem Device "eth0" unter der 11er Adresse sucht. Die Aufteilung ist aber in Wirklichkeit genau andersrum: 10er Netz für eth0 (extern) und 11er Netz für die Clients. Verstehe ich diese Ausgabe richtig, oder ist gemeint "VON 11.1 NACH eth0"?

Schon klar, dass ihr euch nicht mit LTSP auskennt, aber wenn ihr das bestätigen könntet, wäre es schon mal ein Punkt, wo ich weiter suchen könnte...

Grüße
Rolf
 
Das
Code:
default via 192.168.10.2 dev eth0
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.1
192.168.11.0/24 dev eth1  proto kernel  scope link  src 192.168.11.1
und das
Code:
default via 192.168.11.1 dev eth0
192.168.11.0/24 dev eth0 proto kernel scope link src 192.168.11.97
ergibt das
Code:
|       CLIENT     |         |                      SERVER                          |         |     ROUTER      |
192.168.11.97 [eth0] <-----> [eth1] 192.168.11.1 |--forwarding--| 192.168.10.1 [eth0] <-----> [ethx] 192.168.10.2
 
OP
R

Rolf-Werner

Hacker
Toll aufgeschlüsselt, vielen Dank dafür!

Demnach müsste aber alles korrekt sein. Und auf dem Server selbst läuft es ja auch. Der Fehler liegt also ausschließlich bei den Clients, die von dem ganzen Routing nichts mitbekommen. Da es aber ursprünglich problemlos lief, hab ich wohl irgendwann irgendwo irgendwas zerkonfiguriert, ohne es zu merken. Leider konnte mir auf der LTSP-Mailingliste bisher auch noch niemand den entscheidenden Hinweis geben.

Auf einer freien Platte hab ich jetzt noch einmal ein frisches Leap 42.3 aufgesetzt, und bei der EInrichtung des Netzwerks gab es für mich einige Unklarheiten. Das Netz wollte ich wieder so aufsetzen wie ursprünglich angedacht, d. h. zwei NICs, davon einer ins alte Netz und nach draußen (Subnetz .10.x) und einer für die Clients (Subnetz 11.x). Dadurch kann das alte Netz und die Drucker und der Router zunächst parallel weiterlaufen.

Aus technischen Gründen (der Chipsatz-NIC auf dem Board scheint langsamer zu sein als der nachgerüstete) hab ich diesmal

Code:
eth0 = 192.168.11.1
eth1 = 192.168.10.1

genommen. Alle Netzwerkeinstellungen hab ich im Yast gemacht, und dabei kam folgendes raus:

Code:
Global:
- Wicked-Service
- IPv6 aus
- Standard-Route über DHCP ändern -> aus

Code:
Hostname/DNS
- Hostname: "server", Domain "eilert"
- Hostnamen der Loopadresse zuweisen -> ja
- Nameserver vom Provider eingetragen
- Domänensuche: eilert

Zu dem "eilert" gleich noch ein Kommentar...

Jetzt war ich etwas unsicher. Die Ports hab ich so eingerichtet:
eth1 = 192.168.10.1 (externe Leitung) = "server.eilert"
eth0 = 192.168.11.1 (interne Leitung) = "server.intern"
Ursprünglich hatte ich server.extern, dann hat er aber das ganze Netz "extern" genannt und das auch für die Domänensuche eingetragen. Nachdem ich auf "eilert" umgestellt hatte, hat er den Netzwerknamen und die Domänensuche gelöscht. Erst beim dritten Versuch hatte ich überall wieder "eilert" drinstehen. Yast kann ganz schön zickig sein...


Und hier bin ich mir nicht ganz sicher:
Code:
Routing:
- Gateway 192.168.10.2, Gerät eth1
- IPv4 Weiterleitung an
- IPv6 Weiterleitung aus

Gateway ins Internet ist die Fritzbox, aber die hängt HINTER eth1. Bedeutet dies im Yast also "ÜBER welches Gerät ist das Gateway erreichbar", oder "Welches Gerät IST das Gateway"? :???:

Da wäre ich jetzt mal dankbar, wenn jemand sagen könnte, ob das so richtig eingestellt ist.

Grüße
Rolf
 
Zu deinem ganzen Yast-Geraffel kann ich dir nichts sagen, aber bei einer route gibst Du für ein Ziel als gateway an "an welchen Rechner/Router weitergereicht wird" und evtl. noch "über welches Netzwerkinterface dieses Ziel erreichbar ist". Also sollte auf deinem Routing-Rechner die IP der Fritzbox eingetragen sein und das eth-device über welches die Fritzbox erreichbar ist.
Dann mußt Du explizit Paket-forwarding und NATting einrichten. Forwarding dürfte klar sein (/proc/sys/net/ipv4/ip_forward Inhalt 1 statt 0) NAT wirst Du um iptables nicht herum kommen. Also Adressen von intern (11er Netz?) auf extern (10er Netz?) umsetzen (und zurück). NAT von extern (10er Netz?) auf öffentliche IP macht die Fritzbox.

Ich hoffe ich habe deinen Aufbau richtig verstanden und Du verstehst meine Anleitung ;-)
 
OP
R

Rolf-Werner

Hacker
Ja ok, dann habe ich das aber richtig interpretiert.

Ach, bei manchen Sachen ist der Yast schon ganz nützlich, z. B. hab ich mich noch nie um NAT kümmern müssen, der trägt die Routen offenbar selber richtig ein. Wobei man das Ding natürlich nicht überfordern darf. Und es gibt auch einige Module, die ziemlich unübersichtlich sind. Aber für den Standardkram reicht es.

Grüße
Rolf
 
OP
R

Rolf-Werner

Hacker
So, ich habe gerade einen Hinweis erhalten von der Mailingliste, der auf die richtige Stelle hingewiesen hat:

in
Code:
/etc/sysctl.conf
stand "net.ipv4.ip_forward = 0" statt "1". Bei Yast war das nicht zu sehen. :irre:

Also jetzt läuft es wieder, so scheint mir, und ich habe wenigstens was für meine Dokumentation, was ich mir für alle Fälle aufheben kann.

Trotzdem setze ich den Server noch einmal von vorn auf, um zu sehen, ob die Konfiguration jetzt glatt durchläuft. Dann hab ich eine Version, die sauber durchkonfiguriert ist.

Danke für eure Hilfe!

Rolf
 
Rolf-Werner schrieb:
Also jetzt läuft es wieder ..

Sehr gut!
Es wäre für mich interessant zu erfahren, was Yast und seine Automatismen erzeugen.
Vielleicht könntest du mir vom Server das Resultat von
# iptables -S -t filter | grep eth0
zur Verfügung stellen..?

Gruß
Gräfin Klara
 
@Rolf-Werner,

magst Du dir noch mal mein letztes Posting durchlesen? Gerade den Punkt wo ich von ip_forward auf 1 statt 0 schrieb? Dämmert was?
 
OP
R

Rolf-Werner

Hacker
Oh ja, es dämmert, es dämmert :)

Bin vermutlich nachher nochmal in der Firma, dann schaue ich es mir an und schreibe was dazu...

Grüße
Rolf
 
OP
R

Rolf-Werner

Hacker
Hallo Gräfin Klara :)

Das ist jetzt von dem Server, der jetzt wieder geht (nicht von dem gestern frisch aufgesetzten):

Code:
-A FORWARD -i eth0 -j forward_ext
-A forward_ext -d 192.168.11.0/24 -i eth0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED, -j ACCEPT
-A forward_ext -d 192.168.11.0/24 -i eth1 -o eth0 -m conntrack --ctstate NEW,RELATED,ESTABLISHED, -j ACCEPT

Grüße
Rolf
 
OP
R

Rolf-Werner

Hacker
Hallo Geier0815 ;)

Also /proc/sys/net/ipv4/ip_forward steht jetzt auf "1", das passt also.

An die Drucker im 10er Netz komme ich noch nicht ran, mal sehen... Wenn ich Probleme habe, melde ich mich wieder :

Rolf
 
Mir ist dein Aufbau noch nicht so wirklich klar. Du hast zwei Switche? An einem hängt das 11er und am anderen das 10er und der Router hat jeweils ein Bein in jedes Netz? Vom 11er kommst Du jetzt über das 10er Netz und dann über die Fritzbox nach draußen aber an keinen anderen Rechner im 10er Netz? Also Anfrage aus 11er --> an 192.168.11.1, der dann forwardet auf 192.168.10.1 (zweite Netzwerkkarte) --> Switch im 10er Netz --> Fritzbox --> Internet? Und vom Router kannst Du deine Drucker pingen? Aber nicht vom 11er Netz aus?
 
Oben