Debianserver aufsetzen - Endspurt (-probleme)

[Quintus14]

Hast du einen Gateway auf der Winworkstation eingetragen?

Auf den Win-Workstations ist die IP-Adresse des Routers, der vorläufig noch im internen Netz hängt, als Gateway ordnungsgemäß eingetragen.

Auf dem Debian-Server ist auch der Router als Gateway definiert, allerdings unter einer anderen IP-# - diese muss ich im Router immer umändern, wenn ich selbigen auf die zweite NIC umhänge, damit der Linuxserver Kontakt zum Internet kriegt. Shorewall ist auch drauf, allerdings noch nicht konfiguriert.

Nachdem ich annehme, dass Shorewall (wenn man noch keine Ahnung davon hat, wie's geht) nicht in einer halben Stunde funktionieren wird, werde ich mit der Konfiguration derselben auf einen Tag warten, wo es nichts ausmacht, wenn der Internetbetrieb stundenlang nicht funktioniert. Nächste Woche voraussichtlich.

MfG
Quintus

[Sloter]

Da laufen die Pakete im Kreis
Hat der Debianserver eine echte IP?

Sloter

[Quintus14]

Shorewall-Konfiguration

Hab' jetzt begonnen, das Dokument http://www.shorewall.net/two-interface.htm durchzuackern, hab' auch das Sample runtergeladen und - wie geheißen - die Dateien nach /etc/shorewall entpackt.

Sollte funktionieren, denn wie in der Beispieldatei ist eth0 -> Router und eth1 -> intern.

Neu gestartet - er meckert beim Booten bzw. Start der Shorewall:

iptables: no chain/target/match by that name.

Dass Shorewall sich nicht starten lässt, wäre nicht das Schlimmste - ich komm' jetzt aber nicht mehr auf den Server, Webmin funktioniert nicht und Zugriff auf meine Daten gibt's auch keinen ....

Was tun?

Thx,
Quintus


P.S.: @Sloter: ja, der Debianserver hat echte IPs. Vielleicht kriegen wir doch kurzfristig die Shorewall zum Laufen, dann erübrigt sich das Problem vielleicht.

[Quintus14]

Hilfe - die angefangene Shorewall-Konfiguration hat mir anscheinend einen Stealth-Modus eingeschaltet - ich kann den Server nicht mal mehr anpingen.

Wie krieg' ich das jetzt kurzfristig wieder weg (damit ich wenigstens auf die Daten komm)? Und wie die Shorewall aus der Autostart raus?

Thx
Quintus


P.S.: 'ifup -a' bringt lo eth0 eth1 already configured

[flinx]

In deinem Link (http://www.shorewall.net/two-interface.htm) ganz unten gibts Tipps zu 'Starting and Stopping Your Firewall'. Hast das schon ausprobiert?

[Quintus14]

Puh, *zweistundenschwitz* - ich konnt' mir soeben selbst helfen, hab' die 6 Beispiel-Files aus /etc/shorewall rausgelöscht (liegen noch sicherheitshalber woanders), die shorewall.conf umbenannt und neu gebootet - der Trick hat funktioniert, weil der Start der Shorewall jetzt in die Hose geht *).

Jetzt seh' ich zumindest meine Daten wieder .

Muss an die Installation der Shorewall nochmal rangehen, wenn mehr Zeit ist (ein Kinobesuch der Family ist zu wenig).

Ich frag' mich nur, was da alles noch schief gelegen ist bzw. warum der Server auf Pings nicht geantwortet hat. Jemand eine Idee????

Thx,
Quintus


*) = russische Methode

[spunz]

ich kenn diese fw nicht, aber guck mal unter /etc/init.d/ ob nicht hier das startscript zu finden ist. wenn ja solltest du es zb mit "/etc/init.d/name stop" anhalten und mit start starten können.

für mich klingt das ganze eher danach das die firewall zur sicherheit mal alles dicht gemacht hat.

[Quintus14]

für mich klingt das ganze eher danach das die firewall zur sicherheit mal alles dicht gemacht hat.

Richtig - steht auch in der Installations Procedure:

IF YOU ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC.

Problem dabei war/ist nur: dass der Server weder mit '/etc/init.d/shorewall stop' noch mit dem im o.g. Dokument angegebenen 'shorewall clear' im Netz wieder sichtbar wird .

Russische, provisorische Lösung: Umbenennen des /etc/shorewall/-Directories und reboot.

----------------------------------------------------

Aber wie krieg' ich Shorewall jetzt zum Laufen? Folgendes hab' ich gemacht:

• Die 6 Dateien aus dem Two-Interfaces-Sample entpackt und ins Shorewall-Verzeichnis kopiert - meine eth0 hängt auch am Router, eth1 ist intern, somit sollte das Beispiel gleich für mich passen.
• Den Eintrag 'norfc1918' laut dem Two-Interfaces-Dokument aus der /shorewall/interfaces entfernt, weil ich den 192.168.x.x-Bereich intern nutze.
• Die zwei Einträge 'NAT_ENABLED=Yes' sowie 'IP_FORWARDING=On' sollte man (ebenfalls lt. Two-Interfaces-Dokument) in die shorewall.conf schreiben - dort wiederum steht, man solle selbige als icmpdef wegkopieren und Änderungen ebendort vornehmen. Ich hab' die Einträge jetzt in der icmpdef vorgenommen.

Es bleibt dabei: Shorewall kann nicht ordnungsgemäß gestartet werden, Message: No chain/target/match by that name.

Dieselbe Fehlermessage schreibt er auch beim 'etc/init.d/shorewall stop'-command.

Was hat es mit der Fehlermeldung auf sich, was fehlt noch bzw. wie krieg' ich die Shorewall jetzt zum laufen ?



Thx,
Quintus

[spunz]

wie gesagt, ich kenne diese fw nicht. aber es wäre ev hilfreich wenn du deine config noch etwas genauer beschreiben könntest.

welche ip adressen auf welcher nic?
steht im log file genaueres? (guck mal unter /var/log)
was für eine chain will er da? gibts die auch?

[Quintus14]

welche ip adressen auf welcher nic?

Dazu die /etc/network/interfaces:

-------------------

auto lo eth0 eth1

iface lo inet loopback

iface eth0 inet static
address 10.168.110.xx
netmask 255.0.0.0
gateway 10.168.110.yy

iface eth1 inet static
address 192.168.0.zzz
netmask 255.255.255.0

-------------------

Die Netzwerkverbindungen funktionieren tadellos, wenn ich den ISDN-Router vom internen Netz (Provisorium) auf Debian-Server's eth0 hänge, kriegt auch selbiger tadellosen Zugriff aufs Internet.

steht im log file genaueres? (guck mal unter /var/log)

Puh .... da steht viel, aber keine Shorewall.log - keine Ahnung, was wichtig ist.

Im Fraglichen Zeitraum, in dem ich gestern abends keinen Serverzugriff hatte, findet sich in einer syslog.0: 'Packet send failed to 10.255.255.255(137) ERRNO:Operation not permitted' - wobei interessant ist, wo er die IP-Nummer her hat.

Es findet sich auch: 'retransmit_or_expire_response_records: Failed to resend packet id 5788 to IP 10.255.255.255 on subnet 10.168.110.xx

Verwechselt der Kerl da IP-Nummern mit Subnet-Masken?

was für eine chain will er da? gibts die auch?

Wo seh' ich, was er will?

Thx
Quintus (bis mittags offline)