Routing mit nur einem Netzwerkinterface

**Qndre** · 24.02.06, 13:53

Hallo Leute.

Mein Ziel ist es, mit nur einem Netzwerkinterface per NAT/Masquerading zu routen. Das liegt nicht daran dass der Netzwerkserver nur eine Ethernetkarte hat, nein im Gegenteil, er hätte sogar zwei Interfaces (eth0 und eth1) von denen aber nur eines genutzt wird (nämlich eth1). Der Grund für diese ungewöhnliche Anordnung ist der, dass den Clients auch weiterhin die Möglichkeit offen stehen soll, bei Bedarf unabhängig vom Server eine direkte, eigene PPPoE Verbindung aufzubauen. Aus diesem Grund befindet sich der Server netzwerktechnisch gesehen eher dort wo man einen Client erwarten würde und nicht wie gewöhnlich zwischen Internet und LAN (wo man ja einen Gatewayserver vermuten würde), das einzige was ihn zum Server macht sind die darauf ablaufenden Dienste sowie natürlich die IP-Adresse 192.168.0.1! Diese Struktur muss aus oben genannten Gründen beibehalten werden.

So sieht mein Netzwerk aus:

(anklicken für größere Darstellung)

So sieht normales Routing aus:

(anklicken für größere Darstellung)

Das Ganze macht das Routing natürlich problematisch, da externes und internes Interface ja das selbe sind. Folgende Methode brachte keinen Erfolg:

Code:

/sbin/iptables -F
/sbin/iptables -X
/sbin/iptables -N POSTROUTING
/sbin/iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -d \! 192.168.0.0/24 -j MASQUERADE

Ebenfalls erfolglos blieb:

Code:

echo "1" > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -A FORWARD -p TCP -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
/sbin/iptables -A FORWARD -p UDP -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
/sbin/iptables -A FORWARD -p icmp -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
/sbin/modprobe ip_tables
/sbin/modprobe ip_nat_ftp.
/sbin/modprobe iptable_nat
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
/sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Irgendeine Idee, wie es umzusetzen wäre? Ich weiß, dass es funktioniert (es lief schonmal, allerdings auf einer älteren Linuxversion), aber ich habe keine Idee wie. Mein System ist ein x86_64 mit Fedora-Core 4. Zum Routing verwende ich "iptables". Nähere Details zu meinem System gibt der PYS-Link in meiner Signatur.

Danke schonmal im Vorraus.

**geronet** · 24.02.06, 14:57

"/sbin/iptables -N POSTROUTING" ist sinnlos, da diese Chain schon vordefiniert ist (siehe iptables -t nat -L)

Versuchs doch mal so:

/sbin/iptables -F
/sbin/iptables -X
echo "1" > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Grüsse, Stefan

**Qndre** · 24.02.06, 15:05

Nein, leider weiterhin erfolglos. Die Clients haben den Server als DNS-Server sowie als Gateway eingetragen, auf dem Server läuft auch ein DNS-Dienst, daran kann es nicht liegen. Pingen lässt sich der Server von den Clients aus auch. Die Clients haben die fortlaufenden IPs (192.168.0.2, 192.168.0.3, ...) und die gleiche Subnetzmaske wie der Server (255.255.255.0), das ist also ebenfalls alles in Ordnung.

**bla!zilla** · 24.02.06, 15:58

Denk daran das du den Verkehr über das ppp0 Interface maskieren musst, nicht über eth0. Ich würde es auch so wie geronet machen. Was klappt denn bei dir nicht, wenn du es nach geronets Beispiel versuchst?

**Qndre** · 24.02.06, 16:18

Es klappt nicht, dass die Verbindung dann von den Clients nicht genutzt werden kann. Die Clients verhalten sich so als würde der Server gar keine Verbindung ins Internet zur Verfügung stellen. Das NAT ist völlig wirkungslos. Pings oder Anfragen an einen Computer im WAN sind von den Clients aus erfolglos, während der Server sowohl eine völlig intakte Verbindung zum WAN als auch zum LAN hat und Computer sowohl im LAN als auch im WAN pingen kann.

Zitat von bla!zilla

Denk daran das du den Verkehr über das ppp0 Interface maskieren musst, nicht über eth0.

In meinem Falle eth1, denn das Interface eth0 liegt brach. (Liegt daran, dass eth0 über PCI läuft und eth1 direkt im Chipsatz integriert ist. Man sagt das sei performancetechnisch besser. Wie viel da dran ist weiß ich nicht aber ich nutze eben eth1.) Was meinst Du im Klartext mit "Verkehr über das ppp0 Interface maskieren"? Könntest Du eine iptables Regel dafür formulieren?

EDIT: Die PPP Verbindung zum Provider läuft über ein DSL-Modem, das auch über das Interface eth1 angebunden ist, also über das selbe, wie auch das LAN angebunden ist, dessen Rechner die Verbindung nutzen sollen (Modem, Clients und Server hängen ja am selben Hub, siehe Grafik). Vielleicht sind das wichtige Fakten.

EDIT2: Vielleicht ist es auch von Bedeutung, dass das Netzwerk heterogen ist. Der Server läuft auf Linux während auf den Clients Windows XP betrieben wird.

**bla!zilla** · 24.02.06, 16:32

Dein Server macht aber die PPPoE Einwahl, oder? Wenn ja, müsste es nach der Einwahl ein ppp0 Interface geben. Und wenn das so ist, musst du ppp0 für das NAT verwenden, nicht eth0.

**Qndre** · 24.02.06, 16:38

Zitat von bla!zilla

Dein Server macht aber die PPPoE Einwahl, oder? Wenn ja, müsste es nach der Einwahl ein ppp0 Interface geben. Und wenn das so ist, musst du ppp0 für das NAT verwenden, nicht eth0.

Ja, der Server macht die PPPoE "Einwahl" und ja, das entsprechende Interface ppp0 gibt es auch. Vom Server aus kommt man auch problemlos ins Internet und auch in's LAN, es scheint also wirklich an der Konfiguration der iptables zu liegen. Was mir gerade noch eingefallen ist: Der nForce-4 Chipsatz des Servers hat ja eine integrierte Hardwarefirewall, diese ist allerdings Schrott und BIOS-seitig selbstverständlich deaktiviert.

Sorry. "ppp0 für das NAT verwenden, nicht eth0" verursacht bei mir immernoch pures Unverständnis, tut mir Leid ich verwende Linux noch nicht so lange. Erstens gibt es eth0 bei mir überhaupt nicht, eine entsprechende Hardware ist zwar in Form eines Marvell-Controllers vorhanden, jedoch deaktiviert. Die einzige Verbindung zum Netzwerk die der Server hat ist über eth1 (= Netzwerkinterface des nForce4-Chipsatzes). Über diese Verbindung wird sowohl die Verbindung zum PPPoE Dienstanbieter als auch zu den Clients im LAN hergestellt. Außerdem: Was meinst Du mit "für das NAT verwenden". Mir wäre eine Formulierung wie "als Zielinterface des NAT's verwenden" oder "als Quellinterface des NAT's verwenden" wesentlich lieber, da ich ja ein "in-interface" beziehungsweise ein "out-interface" in meinen iptables zu definieren habe. Könntest Du das bitte noch ein wenig genauer erläutern. ;-)

**geronet** · 25.02.06, 09:58

Also.. zuerst einmal zu der pppoe-Sache:

Wenn der pppd startet und sich verbunden hat, erstellt dieser ein ppp0-Interface. Alles was über dieses gesendet wird, landet beim pppd-Prozess. Dieser packt die Pakete in das PPPOE-Protokoll ein und sendet diese wiederum über die Ethernetschnittstelle aus. Das scheint bei dir eth1 zu sein, sonst könntest du nicht vom Server direkt ins Internet. In der Empfangsrichtung ist es genau andersrum. Über das Ethernetinterface laufen nur PPPOE-Pakete, deshalb bräuchte das Interface auch keine IP-Adresse (bei einer Konfiguration wo das DSL-Modem allein dranhängt, wie du oben beschrieben hast).

Mit "ppp0 für das NAT verwenden, nicht eth0" ist diese Zeile gemeint:
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Und das sollte für beide Konfigurationen funktionieren, so auch deine.

"da ich ja ein "in-interface" beziehungsweise ein "out-interface" in meinen iptables zu definieren habe"
Beim Masquerading reicht es normalerweise, ein Ziel-Interface anzugeben. Den Rest macht das schlaue iptables selber

Hast du eventuell noch eine andere Firewall von Fedora laufen? Sonst müsstest du diese deaktivieren (evt. /sbin/iptables -t nat -F /sbin/iptables -t nat -X verwenden).

Zeige doch mal die Ausgabe von
iptables -vL
iptables -t nat -vL

Grüsse, Stefan

**Qndre** · 25.02.06, 11:51

Ich denke nicht, dass noch ein anderer Firewall läuft, ich habe keinen anderen konfiguriert und jeden Kniff von FC4 kenne ich leider nicht. Wenn ich wüsste was ich dazu zu prüfen hätte könnte ich vielleicht genauere Angaben machen.

Habe jetzt mal die Befehle ausgeführt die Du genannt hast:

Code:

[root@server /]# /sbin/iptables -vL
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain INPUT (policy ACCEPT 34 packets, 5167 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain OUTPUT (policy ACCEPT 55 packets, 10007 bytes)
 pkts bytes target     prot opt in     out     source               destination 
[root@server /]# /sbin/iptables -t nat -vL
Chain OUTPUT (policy ACCEPT 3 packets, 183 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain POSTROUTING (policy ACCEPT 3 packets, 183 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 MASQUERADE  all  --  any    ppp0    anywhere             anywhere 

Chain PREROUTING (policy ACCEPT 22 packets, 3788 bytes)
 pkts bytes target     prot opt in     out     source               destination 
[root@server /]#

Die Regel " 0 0 MASQUERADE all -- any ppp0 anywhere anywhere " gefällt mir irgendwie nicht, klingt irgendwie so als könne jeder aus dem Internet sich hinter meinem Server verstecken und damit allerlei Humbuk treiben. Sollte man die Source nicht lieber auf eth1 legen statt auf "any"?

**geronet** · 25.02.06, 12:25

Was soll das bringen wenn er nur 1 Interface hat? Gar nix.

So wie es da steht sollte es aber funktionieren, wenn ip-forward eingeschaltet ist (cat /proc/sys/net/ipv4/ip_forward sollte 1 ergeben), die Clientrechner den 192.168.0.1 als Gateway eingestellt haben und das DNS funktioniert.

Pinge doch mal von einem Clientrechner die 141.1.1.1, falls das funktioniert liegts am DNS-Server.

**Qndre** · 25.02.06, 12:30

ip-forward ist eingeschaltet, das habe ich schon mehrfach überprüft, aber hier zur Vollständigkeit nochmal:

Code:

[root@server /]# cat /proc/sys/net/ipv4/ip_forward
1
[root@server /]#

141.1.1.1 ist vom Client aus erreichbar. Das ist doch das DSL-Modem oder?

Wenn nur DNS nicht geht müsste ich doch vom Client aus http://66.249.93.104/ aufrufen können. Das ist die IP vom "google.de" Server. Ich teste das mal schnell.

EDIT: Cool! Das geht! Es liegt wirklich nur noch am DNS. Das muss ich doch irgendwie forwarden, weil es nicht routingfähig ist, korrekt? Irgendnen Plan wie das funktioniert?

**bla!zilla** · 25.02.06, 14:55

Du musst nix forwarden für DNS. Du solltest dringend an deinen Skills in Sachen Routing und Netzwerkgrundlagen arbeiten. Du hast zwei Möglichkeiten:

1. DNS Server auf deinem Server aufsetzen und dort ein Forwarding einrichten (also alles was er nicht kennt soll er bei einem anderen DNS erfragen).
2. Einen öffentlichen DNS (z.B. den deines ISP) an den Clients eintragen.

**Qndre** · 25.02.06, 15:28

Hey cool, danke das funzt.

**geronet** · 25.02.06, 18:04

Man könnte DNS auch forwarden mit iptables, und zwar so:

iptables -t nat -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 53 -j DNAT --to-destination $DNS_SERVER

Dann noch auf allen Clients den Router als DNS Server einstellen und gut is

PS: 141.1.1.1 ist nicht das DSL-Modem, das hat nämlich keine IP-Adresse (das versteht nur PPPOE, klaro?)