Routing zwischen eth0(LAN) und eth1(WLAN)

dumbman

Newbie
Guten Tag!

Ich habe hier einen Rechner, der über zwei NICs verfügt.
Die eine führt über Fast Ethernet zu einem switch, an denen div clients und ein IPCop-Router hängt. Darüber wurde bisher der Netzwerkverkehr geleitet.
Zusätzlich wurde jetzt eine WLAN-Karte installiert.
eth0 (LAN) 192.168.6.5
eth1 (WLAN) 192.168.1.1
Mein Notebook kann beide IPs anpingen (über WLAN).
Das Routing zu anderen Rechnern im 192.168.6.0 Netzwerk und ins Internet funktioniert aber noch nicht.
Route gibt folgendes aus:

Ziel Router Genmask Flags Metric Ref Use Iface
192.168.6.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.6.1 0.0.0.0 UG 0 0 0 eth0

Sieht doch gut aus, oder?
Unschlüssig bin ich aber ob der iptables Befehle.
Kann mir jemand sagen, was ich insgesamt alles an Routen und iptables-Befehlen brauche?
Das dürften doch nicht mehr als 3-4 Befehle sein, soweit ich das verstehe?
Hinterher würde ich natürlich restriktive Regeln setzen, damit mir niemand von der Straße aus Ärger macht.

Schonmal vielen Dank.
 

Martin Breidenbach

Ultimate Guru
IPCOP hat die 192.168.6.1 nehme ich an ?

Erforderliche Einstellungen:

IPCOP-Router (im 192.168.6.0/24 Netz):

- statische Route für 192.168.1.0/24 über 192.168.6.5
- Routing, Firewall etc aktiviert

LAN-Client (im 192.168.6.0/24 Netz):

- default gateway 192.168.6.5 oder IPCOP-Router

WLAN-Client (im 192.168.1.0/24 Netz):

- default gateway 192.168.1.1

Linux Router (192.168.1.1 / 192.168.6.5):

- Routing/IP-Forwarding eingeschaltet
- default gateway IPCOP-Router
- erstmal keine Firewall erforderlich
 
OP
D

dumbman

Newbie
Danke für die schnelle Antwort.
Soweit habe ich das alles auch gemacht.
Problematisch ist das Routing zwischen eth0 und eth1. Hier herscht meine Unwissenheit.
Ist meine Routingtabelle denn richtig? Forwarding ist aktiviert, aber es wird de facto nichts weitergeleitet.
Dass vom NB aus ein ping auf 192.168.6.5 klappt, liegt, glaube ich, am kernel und nicht an meinem Routing.
Kann der Fehler noch ein anderer als zu restriktive iptables Regeln sein?
Ich weiß nicht, welche iptables-Befehle von Nöten sind...
Fehlen auch noch Routingeinträge?
 

Martin Breidenbach

Ultimate Guru
Damit ein PING in das andere Segment klappt muß der betreffende Rechner ja auch den Rückweg kennen.

Der IPCOP braucht eine statische Route denn sonst hat der keinen Plan wo 192.168.1.0 denn sein soll.

Falls Clients irgendwelche Firewalls haben (incl XPSp2) dann sollten die zumindest für den Verbindungstest mal abgeschaltet werden.

Beispiel: von 192.168.1.2 wird 192.168.6.1 angepingt

192.168.1.2 schickts an sein default gateway 192.168.1.1
der routets durch auf 192.168.6.5
192.168.6.5 schickts an 192.168.6.1
wenn der jetzt keine Route für 192.168.1.0 hat - wo soll er's denn hinschicken ? Der ist nicht so schlau daß er sich merkt daß er das ja mal an 192.168.6.5 schicken könnte; vielleicht weiß der ja wo's hin soll...

Ich nehme an daß Clients in 192.168.6.0 momentan den IPCOP als default gateway haben. Wenn man die aus dem anderen Segment anpingt schicken die also ihre Antwort-PINGs an den IPCOP und der muß jetzt wissen daß das bei 192.168.6.5 weitergeht.

Hast Du sowas wie ethereal oder tcpdump und kannst es bedienen ? ethereal gibts auch für Windows und ist hervorragend um sowas zu debuggen. Da kann man nämlich direkt schauen ob die icmp-Pakete vom ping ankommen. Wenn Du's noch nicht hast - probier's einfach mal aus.

EDIT: probier's doch erst mal OHNE Firewall. Wenn's klappt kann man die immer noch einschalten. Sonst kriegst Du nie raus woran es liegt.
 
OP
D

dumbman

Newbie
Du hast natürlich recht, ich habe die (ICMP-)Antwortpakete komplett verdrängt.
Hab den Fehler nur auf dem Rechner mit der neuen NIC gesucht und erwartet.
Über die Weboberfläche vom IPCop finde ich spontan keine Einstellungen für statische Routen, aber das lässt sich per ssh sicher ändern.
Danke für den Hinweis. Auch der Verkehr ins Internet kann so natürlich nicht klappen.

> Ich nehme an daß Clients in 192.168.6.0 momentan den IPCOP als default gateway haben.
Alles, was du bisher angenommen hast, ist richtig! :)
Ist halt nen klassisches Setup.

> Hast Du sowas wie ethereal oder tcpdump und kannst es bedienen ?
Alles kein Problem, wobei es mit einer statischen Route auf 192.168.6.1 jetzt wirklich klappen sollte.

> EDIT: probier's doch erst mal OHNE Firewall. Wenn's klappt kann man die immer noch einschalten. Sonst kriegst Du nie raus woran es liegt.
Auf den clients sind die FWs kein Problem. Ich bin mir nur nicht sicher, ob mit iptables -F wirklich alles weg ist?!

Reichen denn zum forwarden
iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d 192.168.6.0/24 -j ACCEPT
iptables -A FORWARD -p tcp -s 192.168.6.0/24 -d 192.168.1.0/24 -j ACCEPT
aus?

Im Notfall habe ich noch fli4l einsatzbereit auf Diskette. Dort kann man statische Routen eintragen.

Danke für den geistigen Anstoß.
 

Martin Breidenbach

Ultimate Guru
Dann kommt von 192.168.6.0 keine Antwort auf PINGs zurück weil die ja alle den Weg nicht kennen.

Man könnte mal probehalber einem Client das default gateway auf 192.168.6.5.umbiegen und dann schauen ob der sich anpingen läßt.

Reichen denn zum forwarden
iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d 192.168.6.0/24 -j ACCEPT
iptables -A FORWARD -p tcp -s 192.168.6.0/24 -d 192.168.1.0/24 -j ACCEPT
aus?

Wirklich nicht. Falls die default policy 'deny' ist dann bleibt da jedes Paket hängen das kein tcp ist. Also z.B. jeder ping denn das ist ja icmp Protokoll. Außerdem wird udp nicht weitergeleitet.

Ich denke (bin aber nicht 100% sicher) daß iptables -F die NAT Regeln nicht löscht. Das sollte iptables -t nat -F machen. Glaub ich.

Mit

iptables -L

und

iptables -t nat -L

kannst Du die Dir anschauen.
 
OP
D

dumbman

Newbie
> Wirklich nicht. Falls die default policy 'deny' ist dann bleibt da jedes Paket hängen das kein tcp ist. Also z.B. jeder ping denn das ist ja icmp Protokoll. Außerdem wird udp nicht weitergeleitet.
Das ging in der Hektik jetzt unter: Natürlich das ganze dreimal mit tcp, udp und evtl icmp.

Bin über ssh auf den IPCop gegangen und habe gesagt
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.6.5
Logischerweise kann ich jetzt mit dem NB surfen. Wunderbar.
Drei Tage für einen Befehl, großes Kino ;)

Wäre noch das Aufsetzen einer korrekten restriktiven FW.
Würdest du es denn grundsätzlich gutheißen, wenn ich mit Konstrukten wie
iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d 192.168.6.0/24 -j DROP
iptables -A FORWARD -p tcp -s 192.168.6.0/24 -d 192.168.1.0/24 -j DROP
erst alles verbiete und dann wieder gezielt Dienste öffne?
 
OP
D

dumbman

Newbie
> ... aber HIER hast Du erst vor nicht mal 2 Stunden gefragt :D
Vollkommen richtig. Ein Hoch auf linux-club.de, ein Hoch auf dich.
Ich hatte vorgestern in einem anderen großen Forum schonmal gefragt, aber lassen wir das... ;)

> Dafür gibts ja die DEFAULT POLICY. Setz die auf DROP oder REJECT (je nachdem wie gemein Du sein willst) und schalte dann frei was Du brauchst.
So werde ich das machen. Danke für deine klasse Hilfe. Großer Denksport. 8)

Ich habe gelesen, dass DROP nicht so der Bringer ist, was meinst du?
Aber das disktutieren wir jetzt nicht aus ;)
 

Martin Breidenbach

Ultimate Guru
Das hängt davon ab was Du willst.

Bei DROP wird die Anfrage einfach weggeworfen. Bei REJECT kommt ein 'du kommst hier net rein' als Antwort zurück.

Wenn man also z.B. Portscans blocken will dann ist DROP besser weil die dann ja auf eine Antwort warten und jedenfalls länger brauchen.

Allerdings wirst Du ja genügend Ports freischalten müssen so daß jemand der portscannt sowieso weiß daß da was ist.

Und Clients im internen Netz bringen bei REJECT ordentliche Fehlermeldungen. Bei DROP hängen die sich ggf auf weil die auf Antwort warten und mehrere Retries machen..
 
OP
D

dumbman

Newbie
Ich weiß. Hatte nur irgendwo was gelesen, DROP wäre nicht so doll, da deine Existenz bei Angriffen aus dem Internet
irgendwie trotzdem durch die Fehlermeldung des vorhergehenden Routers festgestellt wird.
So oder ähnlich,
schön' Abend noch :D
 
Oben