Mal wieder Masquerading/Forwarding [gelöst]

[Hoshpak]

Ich versuche nun schon seit mehreren Stunden mit der netinstall einen kleinen Server aufzusetzten, die Sitution ist die folgende:

Der zu installierende Rechner hängt per Lan-Kabel an einem Router
mein PC hängt ebenfalls an dem Router und gleichzeitig per Wlan am DSL-Router
der DSL-Router stellt die Verbindung ins Internet her.

Nach stundenlangem ausprobieren von verschiedenen Iptables-Regeln habe ich jetzt auf ipmasq zurückgegriffen, welches folgenmde Regeln setzt: http://nopaste.debianforum.de/3327

Auf dem anderen Rechner ist folgendes eingetragen:
IP:192.168.1.34
Standardgateway: 192.168.1.33
Subnet:255.255.255.0

Teilweise scheint das auch zu funktionieren, ich bekomme solche Meldungen im syslog:

Code: Alles auswählen

Jun  3 17:49:25 localhost kernel: IN=eth0 OUT=wlan0 SRC=192.168.1.34 DST=141.76.2.4 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46996 DF PROTO=TCP SPT=1036 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0 

Also scheint schonmal was rauszugehen (DST ist der deutsche Debian-Mirror), es kommt aber nichts zurück. Woran könnte das liegen? Ich habe so langsam das Gefühl, dass das, wa sich vorhabe schlicht unmöglich ist.

[gms]

Teilweise scheint das auch zu funktionieren, ich bekomme solche Meldungen im syslog:

Code: Alles auswählen

Jun  3 17:49:25 localhost kernel: IN=eth0 OUT=wlan0 SRC=192.168.1.34 DST=141.76.2.4 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46996 DF PROTO=TCP SPT=1036 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0 

Also scheint schonmal was rauszugehen (DST ist der deutsche Debian-Mirror)

Da behaupte ich das Gegenteil. DIe LOG Regel in der FORWARD Chain wird direkt vor der DROP Regel aufgerufen. Du kannst daher davon ausgehen, daß alle Pakete die geloggt werden auch gedroppt werden.
Du solltest also noch Regeln in die FORWARD Chain einbauen, die den erwünschten Traffic erlauben.

Gruß
gms

[DynaBlaster]

Ich verstehe nur Bahnhof. Könntest du ne Zeichung deines Netzes anfertigen bzw. dein Posting besser strukturieren. Ich kann beim besten Willen nicht erkennen, welcher PC wie (Ethernet oder WLAN) verkabelt ist, geschweige denn, welcher PC welche IP-Adressen, GW's, Routen usw. hat.

Wenn ich es versuche, würde ich vermuten, daß dort ein SOHO-DSL-Router vorhanden ist. Und an den ist bereits ein Debian-PC (über WLAN ?) angeschlossen. Hinter (bzw. über) diesen Debian-PC soll ein weiterer PC installiert werden (über dessen "normale" NIC ?). Und auf diesem "mittleren" PC hakt das Routing oder wie ?

[npi]

deine iptables sehen n weng kompliziert aus, bist du sicher, das du das alles so brauchst?
naja, egal, also zum ausprobieren machst du auf dem Rechner der als Router dienen soll einfach:

Code: Alles auswählen

#erst mal alles rausschmeissen
iptables -t nat -F
iptables -t filter -F
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t nat -P OUTPUT ACCEPT

#jetzt die Weiterleitung aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward
#quick and dirty
iptables -t nat -A POSTROUTING -j MASQUERADE

Der erste Teil ist nur nötig, wenn die iptables schon verändert wurden

Die sauberere Methode wäre

Code: Alles auswählen

echo 1 > /proc/sys/net/ipv4/ip_forward
ifconfig wlan0:virtual 192.168.178.31 up
iptables -t nat -A PREROUTING -d 192.168.1.31 -j DNAT --to-dest 192.168.1.34
iptables -t nat -A POSTROUTING -s 192.168.1.34 -j SNAT --to-source 192.168.1.31

wenn das so funktioniert, dann kannst du evtl aus Sicherheitsgründen noch andere Regeln hinzufügen, aber eigentlich sollte dich der DSL-Router schon so weit vom Internet abschotten, das da nicht mehr viel getan werden muss.

gruß,
npi

[gms]

@npi
Ich habe das Problem eigentlich ziemlich genauso wie "DynaBlaster" verstanden und sehe daher eigentlich keine Notwendigkeit für SNAT/DNAT und schon gar nicht für MASQUERADE
Wieso glaubst du, daß das notwendig sein soll ?
Das alles sollte über "normales" Routing funktionieren, nur wenn er das Routing am DSL Router nicht konfigurieren kann, braucht er SNAT/MASQUERADE

Gruß
gms

[npi]

soweit ich das verstanden hab hat DynaBlaster das gar nicht verstanden , ich lese das auf jeden Fall so,
Netz 1:
Rechner1: 192.168.1.34
Rechner2: 192.168.1.33

Netz2: Wlan
DSL-Router
Rechner2: 192.168.178.30

Jetzt soll Rechner2 die Verbindung zum Internet für Rechner1 herstellen, der kein Wlan hat.

Deshalb, DNAT/SNAT. MASQUERADE war nur die Quick and Dirty Methode, die eigentlich immer funktioniert und wo man am wenigsten konfigurieren muss.

gruß,
npi

[DynaBlaster]

[...]und sehe daher eigentlich keine Notwendigkeit für SNAT/DNAT und schon gar nicht für MASQUERADE
Wieso glaubst du, daß das notwendig sein soll ?

Najo, hatte das bisher nicht gepostet weil ich die Skizze/Antwort des Topic-Starters abwarten wollte. Aber wahrscheinlich fehlt dem SOHO-Router die Route zurück (also die Route in das kabelgebundene Netz zwischen dem "neue" Rechner und dem "mittleren". Folglich jagt der SOHO-Router alle Pakete, die nicht ins WLAN gehen über sein Standard-GW raus: und das zeigt ins Internet - also kommt kein Paket zurück.

Wenn man beim SOHO-Router eine Route einstellen kann, ist das der unkompliziertere Weg. Im anderen Fall (wie bei mir zu Hause - der SMC Barricade 7004 unterstützt keine zusätzlichen Routen) muss der "mittlere" PC SNAT oder Masquerading machen, damit die Antwort-Pakete vom SOHO-Router "den Weg zurück finden" .

Nachtrag: @npi, doch, genau so habe ich das auch verstanden. Im Grunde meinen wir alle das gleiche und reden (bzw. redeten) mangels Skizze aneinander vorbei

[npi]

Hoshpak machts spannend...

[gms]

Deshalb, DNAT/SNAT. MASQUERADE war nur die Quick and Dirty Methode, die eigentlich immer funktioniert und wo man am wenigsten konfigurieren muss.

Sehe ich auch als Quick und Dirty Methode, die aber leider oft nicht also solche gekennzeichnet wird.
Es gibt auch noch einfachere Methoden, die weit weniger "dirty" sind.
a) Mit Proxy-Arp könnte er die zwei physisch getrennten Netze zu einem "zusammenfassen" und bräuchte dazwischen weder SNAT noch MASQUERADE.
b) Am wenigsten für das System belastend wäre es, wenn er das Routing auf seinem DSL-Router korrekt konfigurieren könnte

Gruß
gms

[npi]

b) Am wenigsten für das System belastend wäre es, wenn er das Routing auf seinem DSL-Router korrekt konfigurieren könnte

Das versteh ich jetzt ehrlich gesagt nicht ganz, wenn der Rechner2 nix macht erreichen die Packete von Rechner1 den DSL-Router doch gar nicht.

gruß,
npi

[DynaBlaster]

Code: Alles auswählen

#jetzt die Weiterleitung aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward

Das reicht:, denn diese Zeile aktiviert das Forwarding im Kernel: und solange die Default-Policy der FORWARD-CHAIN auf ACCEPT steht funktioniert Forwarding. Aber der SOHO-Router braucht die Route zurück

[npi]

ok, der Router müsste dann aber an eine IP zurückschicken, auf die Rechner2 hört, also braucht Rechner2 noch ne virtuelle Adresse, bei der die Packete für Rechner1 ankommen, aber wenn Rechner1 nicht auf diese virtuelle Adresse hört, dann hilft auch echo 1 > ...../ip_forward nix.

Deshalb eben SNAT und DNAT, um die Adressen zwischen den beiden Netzen zu übersetzen.

gruß,
npi

[gms]

Nachtrag: @npi, doch, genau so habe ich das auch verstanden. Im Grunde meinen wir alle das gleiche und reden (bzw. redeten) mangels Skizze aneinander vorbei

kann nicht sagen, ob wir richtig liegen, aber wir düften zumindest die gleichen Vorstellungen von diesem Netzwerk haben.

Im anderen Fall (wie bei mir zu Hause - der SMC Barricade 7004 unterstützt keine zusätzlichen Routen) muss der "mittlere" PC SNAT oder Masquerading machen, damit die Antwort-Pakete vom SOHO-Router "den Weg zurück finden" .

richtig, den Weg zurück finden sie nicht, weil sie zu einem anderen Subnet gehen müssen. Mit Proxy-Arp kannst du die zwei physischen Netze in ein Subnet zusammenfassen und brauchst daher dazwischen kein SNAT oder MASQUERADE.

[npi]

btw, so belastend für den Rechner 2 wird das bisschen NATing wohl nicht sei

gruß,
npi

[gms]

ok, der Router müsste dann aber an eine IP zurückschicken, auf die Rechner2 hört, also braucht Rechner2 noch ne virtuelle Adresse, bei der die Packete für Rechner1 ankommeni

Kein Rechner braucht eine "virtuelle Adresse", der Router muß nur wissen, daß er Pakete für das LAN an der Rechner1 ausliefern soll.
Das ist stink normales Routing

Bei der zweiten Methode "Proxy Arp" werden nur die ARP Anfragen/Antworten über die zwei Interfaces dupliziert.

Wenn DNAT bzw MASQUERADE keine Vorteile bietet, sind daher die oben genannten Methoden vorzuziehen, weil sie den Rechner1 am wenigsten belasten.

Gruß
gms

[npi]

Mit Proxy-Arp kannst du die zwei physischen Netze in ein Subnet zusammenfassen und brauchst daher dazwischen kein SNAT oder MASQUERADE.

Was braucht man denn konkret für Proxy-Arp?
(übrigens: http://de.wikipedia.org/wiki/Address_Re ... #Proxy_ARP für welche wie mich denen das nix sagt)

gruß,
npi

[gms]

Was braucht man denn konkret für Proxy-Arp?

Abgesehen davon, daß die IP Adressen und Gateway auf den Rechnern umgesetzt werden müssen, wird nur folgendes benötigt:

Code: Alles auswählen

echo "net.ipv4.conf.all.proxy_arp = 1">>/etc/sysctl.conf
sysctl -p

Gruß
gms

[npi]

Kein Rechner braucht eine "virtuelle Adresse", der Router muß nur wissen, daß er Pakete für das LAN an der Rechner1 ausliefern soll.
Das ist stink normales Routing

ok, das ist dann aber nicht auf IP-Ebene, sondern darunter, oder versteh ich das jetzt falsch?
Ich meine wird der Rechner2 die Packete auch weiterleiten, wenn sie laut IP-Adresse gar nicht bei ihm ankommen sollten/für ihn gedacht sind?

gruß,
npi

[gms]

Kein Rechner braucht eine "virtuelle Adresse", der Router muß nur wissen, daß er Pakete für das LAN an der Rechner1 ausliefern soll.
Das ist stink normales Routing

ok, das ist dann aber nicht auf IP-Ebene, sondern darunter, oder versteh ich das jetzt falsch?

das Ausliefern an Rechner1 ist auf der IP-Ebene. Rechner1 wäre hier das Gateway für das interne LAN.

Ich meine wird der Rechner2 die Packete auch weiterleiten, wenn sie laut IP-Adresse gar nicht bei ihm ankommen sollten/für ihn gedacht sind?

Hier sind wir im gleichen Subnet
Rechner1 fragt also über das ARP Protokoll, welcher Rechner die IP-Adresse hat und bekommt als Antwort die MAC-Adresse

Gruß
gms

[npi]

das Ausliefern an Rechner1 ist auf der IP-Ebene. Rechner1 wäre hier das Gateway für das interne LAN.

Rechner2 wäre das Gateway, also haben die IP-Pakete die IP-Ankunftsadresse von Rechner2, oder?
Wie weiss dann Rechner1, das diese Pakete eigentlich für ihn sind, wenn im IP-Header doch als Adresse die von Rechner2 steht?

gruß,
npi

[gms]

jetzt bin ich etwas verwirrt.
Für mich war Rechner1 jetzt immer der mittlere Rechner, mit dem DSL Router auf der einen Seite und dem neuen aufzusetzenden Server auf der anderen.
Hast du die jetzt die gleiche Namenskonvention oder nummerierst du andersrum ?

[DynaBlaster]

Ich meine wird der Rechner2 die Packete auch weiterleiten, wenn sie laut IP-Adresse gar nicht bei ihm ankommen sollten/für ihn gedacht sind?

Genau das bewirkt "echo 1 > /proc/sys/net/ipv4/ip_forward". Wenn Pakete an einem Interface des PC's ankommen, die nicht für ihn selbst bestimmt sind, der PC aber weiss, wie diese Pakete ihr eigentliches Ziel erreichen können (nämlich über sein zweites Interface), dann leitet er sie entsprechend (und unverändert) weiter. Bei "echo 0 > /proc/sys/net/ipv4/ip_forward" würde dein PC solche Pakete einfach ignorieren.

Beim "unveränderten" Weiterleiten der Pakete stellt sich am SOHO-Router aber nun folgendes Problem ein (analog zu unserem Beispiel hier):

Da kommt ein Paket von Rechner 1 mit der IP 192.168.1.34 an. Der SOHO-Router weiss aber nur, daß er alle Rechner im Netz 192.168.178.0/24 direkt erreichen kann. Alle anderen Rechner erreicht er über sein Standard-GW (also ein Rechner beim DSL-Provider). Folglich schickt er seine Antwortpakete an 192.168.1.34 nicht nach 192.168.178.30 (Rechner 2), über den sie weitergeleitet worden sind, sondern ins Internet. Die Lösung für dieses Dilemma ist simpel: teile dem SOHO-Router mit, daß er das Netz 192.168.1.0/24 über die IP 192.168.178.30 (Rechner 2) erreicht. Das kann man unter Linux oder Windows mit dem Kommando route erreichen. Viele SOHO-Router bieten in ihrem Webinterface deshalb die Möglichkeit an, "Additional Routes" zu konfigurieren.

Wenn ich das mit dem Proxy-ARP richtig verstanden habe, hat das gegenüber DNAT und MASQUERADE den Vorteil, daß nicht das eigentliche IP-Paket manipuliert werden muss - sprich man spart sich das Umschreiben der Quell-IP im IP-Paket. Stattdessen antwortetet der (Proxy-ARP-)Router einfach auf beiden physikalischen Interfaces auf ARP-Anfragen mit beiden MAC-Adressen - die anderen Rechner bekommen also immer eine MAC-Adresse "vorgegaukelt", zu der sie auch den Weg kennen - sprich, die sie erreichen können, auch wenn diese MAC-Adresse physikalisch eigentlich nicht für sie erreichbar ist.

[DynaBlaster]

@gms

Netz 1:
Rechner1: 192.168.1.34
Rechner2: 192.168.1.33

Netz2: Wlan
DSL-Router
Rechner2: 192.168.178.30

Er hat das genau anders herum. Rechner 2 ist in der Mitte

[gms]

Wenn ich das mit dem Proxy-ARP richtig verstanden habe, hat das gegenüber DNAT und MASQUERADE den Vorteil, daß nicht das eigentliche IP-Paket manipuliert werden muss - sprich man spart sich das Umschreiben der Quell-IP im IP-Paket.

genau, und natürlich auch das "Connection Tracking" welches dafür benötigt wird.

Stattdessen antwortetet der (Proxy-ARP-)Router einfach auf beiden physikalischen Interfaces auf ARP-Anfragen mit beiden MAC-Adressen.

Hier bin ich mir jetzt unsicher, welche "beiden MAC-Adressen" du meinst.
Daher in anderen Worten:
Wenn der DSL-Router eine ARP Anfrage mit der IP des "neuen Servers" absetzt, antwortet der ARP Proxy mit seiner eigenen MAC-Adresse und erhält daher auch das Paket. Danach muß er dieses Paket nur ganz normal routen. Er hat die MAC-Adresse schon in seinem ARP Cache und braucht das Paket nur an diese weiterleiten.

Gruß
gms

[npi]

Genau das bewirkt "echo 1 > /proc/sys/net/ipv4/ip_forward". Wenn Pakete an einem Interface des PC's ankommen, die nicht für ihn selbst bestimmt sind, der PC aber weiss, wie diese Pakete ihr eigentliches Ziel erreichen können (nämlich über sein zweites Interface), dann leitet er sie entsprechend (und unverändert) weiter. Bei "echo 0 > /proc/sys/net/ipv4/ip_forward" würde dein PC solche Pakete einfach ignorieren.

Reine Neugier, nur wenn er es weiss, oder leitet er einfach alle Pakete an alle Interfaces weiter (so kannte ich es).

gruß,
npi