PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : RSYNC von PC aus anderem Netz



Ragamuffin
23.05.07, 21:47
Nabend Leute,

hab hier auf meinem kleinen Debian-Server (Etch, 4.0) RYNC laufen und das replizieren der Daten von meinen Arbeitsstationen im Netz 192.168.0.0/27 klappt einwandfrei. Der Server selbst hat die IP 192.168.0.2.

Nun hab ich noch ein kleines, zweites Mini-Netz 192.168.2.0/30, eine DMZ, mit genau einem Suse-Server auf 192.168.2.2. Der Router zwischen diesen beiden Netzen ist mein IPCop mit den IPs 192.168.0.1 und 192.168.2.1.

Was ich will: Der Suse-Server in der DMZ soll einen Teil seiner Daten ebenfalls auf dem Debian-Server replizieren können!

Mittels DMZ-Schlupflöcher (also sprich via iptables) hab ich IPCop nun gesagt "Erlaube Zugriff auf 192.168.0.2:873 (RSYNC) von 192.168.2.2", da bei IPCop standardmäßig jeglicher Zugriff von der DMZ auf das normale LAN verwehrt wird - was ja auch Sinn macht, sonst bräuchte ich keine DMZ.

Hat auch toll geklappt, die Pakete werden nun durchgeroutet wenn ich vom Suse-Server RSYNC ausführe, statt in der Firewall hängen zu bleiben - jedoch merke ich davon am Debian-Server selbst nix. In keiner Log-Datei wird irgendwas von 192.168.2.2 oder VITTRA (der Hostname der Suse-Büchse) protokolliert, auch RSYNC selbst vermeldet keinen Zugriff. Am Suse-Server kriege ich daher erwartungsgemäß nur einen Timeout.

Die Frage die sich mir stellt ist: Wo ist das Paket? Wenn es den Router passiert hat, sollte es den Weg zum PC gefunden haben. Wird es dort kommentarlos verworfen, weil es nicht aus dem gleichen Netz kommt? Iptables am Debian-Server steht derzeit noch auf "Alles zulassen". In der /etc/rsyncd.conf hab ich testweise derzeit hosts allow = * eingetragen.

Jemand eine Idee? IPCop hat leider kein tcpdump oder ähnliches, um den Weg des Pakets verfolgen zu können. :/

Ragamuffin
23.05.07, 22:28
Problem gelöst. Ursache: Eigene Dummheit.

Ich hab in dem Debian-Server zwei NICs. Einmal eth0 für LAN und einmal ath0 für WLAN. Das Standard-Gateway hab ich jedoch nur für ath0 definiert, wo also die Route zum IPCop drin steht.

ath0 hatte ich zu Testzwecken deaktiviert und nicht bedacht, dass dadurch auch das Standard-Gateway rausgeschmissen wird. Aufgefallen ist es mir erst bei dem Versuch mittels apt-get install tcpdump auf dem Debian-Server tcpdump zu installieren und dieser dann (logischerweise) keine Verbindung zu den Servern bekam.

Aber eine Frage hab ich noch: Ist es normal, dass wenn ich beiden Interfaces IP-Adressen aus DEMSELBEN Netzwerk gebe (192.168.0.2 und 192.168.0.3), dass dann jedes Interface bei Deaktivierung des jeweiligen anderen Interfaces über beide Adressen angesprochen werden kann?

Beispiel: eth0 hat 192.168.0.2 und ath0 hat 192.168.0.3. Ich gebe ifdown ath0 ein und der PC ist weiterhin mit 192.168.0.2 UND 192.168.0.3 erreichbar, wo in beiden Fällen eth0 blinkt.