internes Routing - Grundsatzfragen

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
rubiconpalace
Beiträge: 19
Registriert: 09.08.2006 11:09:08

internes Routing - Grundsatzfragen

Beitrag von rubiconpalace » 06.01.2009 09:30:30

Hallo zusammen,

ich muss einen Router einrichten, um (temporär) über rsync Dateien zwischen zwei Servern in unterschiedlichen Netzen abzugleichen.
Beides sind interne Class-C Netze: 192.168.77.0 und 192.168.1.0
Der Rechner mit der IP 192.168.77.100 hat zwei NICs (eth0 = .77.100, eth1= .1.100).
Forwarding ist auf dem Rechner aktiviert, beide Netze sind von dem Rechner erreichbar.

Der Rechner selber ist Xen-Host, zwei weitere Rechner laufen als DomUs (.101, .105) im gleichen Netz.

Auf der anderen Seite habe ich einen alten ct-Server mit IPCop in UML am laufen.
IP-Adresse des IPCop (Router): 192.168.1.1
UML-Server: 192.168.1.2

Der Zugriff soll nun zwischen 192.168.77.105 und 192.168.1.2 über die 192.168.77.100 erfolgen. Der IPCop sollte somit eigentlich aussen vor sein (diente früher mal als Gateway zum Internet, DMZ und WLAN).
Sowohl für den 192.168.77.105 habe ich eine statische Route auf das 192.168.1.0-Netz eingetragen und entsprechend
für den 192.168.1.2 eine statische Route auf das 192.168.77.0-Netz.

Vermutlich muss ich aber auf dem Rouer (192.168.77.100) noch die IPTABLES anpassen, damit die Pakete von einem ins andere Netz kommen.
Was für Regeln muss ich dort eintragen? Habe bisher folgende Einträge:

Code: Alles auswählen

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     0    --  ftp                  anywhere            PHYSDEV match --physdev-in vif2.0
ACCEPT     udp  --  anywhere             anywhere            PHYSDEV match --physdev-in vif2.0 udp spt:bootpc dpt:bootps
ACCEPT     0    --  samba                anywhere            PHYSDEV match --physdev-in vif3.0
ACCEPT     udp  --  anywhere             anywhere            PHYSDEV match --physdev-in vif3.0 udp spt:bootpc dpt:bootps
ACCEPT     0    --  192.168.1.0          anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Leider bisher ohne Erfolg...

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: internes Routing - Grundsatzfragen

Beitrag von rendegast » 08.01.2009 04:45:39

Chain FORWARD (policy ACCEPT)
Da kannst Du Dir die Regeln dort eigentlich sparen.


So wie Du es beschreibst, müßte 192.168.1.* auf 192.168.77.* und vice versa zugreifen können.

Was gibt denn

Code: Alles auswählen

iptables -v -n -L
iptables -v -n -L -t nat
für die Systeme? Möglicherweise ein Verbot auf dem IPCop?

/etc/sysctl.conf:

Code: Alles auswählen

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
spiegelt sich in /proc/sys/net/ipv4/ip_forward wieder?
Gib mal die Ausgaben von

Code: Alles auswählen

route -n
für die drei Systeme wieder, vielleicht ist ein Zahlendreher drin?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
Duff
Beiträge: 6321
Registriert: 22.03.2005 14:36:03
Wohnort: /home/duff

Re: internes Routing - Grundsatzfragen

Beitrag von Duff » 08.01.2009 08:49:20

Immer hilfreich ist auch das Logging in iptables einzuschalten. Dann kann man z.B. im Logfile sehr schnell erkennen, dass Packet A mit dem Ziel xy nicht erlaubt/durchgeroutet wird.
Oh, yeah!

rubiconpalace
Beiträge: 19
Registriert: 09.08.2006 11:09:08

Re: internes Routing - Grundsatzfragen

Beitrag von rubiconpalace » 10.02.2009 10:35:08

Ganz dummer Fehler:

Das Interface eth1 hat immer irgendwann vom IPCop über DHCP eine IP bekommen - demzufolge war es dann nicht die 192.168.1.100 ... :D
Kann dem Interface aber auch keine feste IP dauerhaft zuweisen, das bringt wieder Probleme mit dem DomUs... Soll ja auch nur vorübergehend helfen, also IP mittels ifconfig "eth1 192.168.1.100" gesetzt, und alles ist gut...

Antworten