• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

openSUSE 10.3 als Router - Zielprotokoll nicht erreichbar

Als allererstes mal Ahoii aus Wien!, da es mein erster eigener Thread ist... *gg*

Folgende Problematik: oSUSE 10.3 läuft hier bei mir als DHCP und Router mit 3 NICs.

eth0: internal network @ 10.10.0.0
eth1: internal network @ 192.168.123.0
eth2: external network @ ISP (static ip provided: 84.x.x.73) - Hängt direkt an nem Kabelmodem

Der DHCP vergibt in den internen Netzen IPs von .200 - .254
Firewall ist aktiv, Forwarding und Masquerading auch. Ich kann von jedem Client aus ins WWW, Portfreigabe per YAST gelöst, läuft soweit ganz gut.

Die Probleme beginnen erst, wenn ich versuche von "client an eth0" zu "client an eth1" und umgekehrt zu verbinden! Alleine schon ein PINGversuch verläuft sich im Nirvana, da wie im Betreff genannt, das Zielprotokoll nicht erreichbar ist.
Edit: Vom Server aus sind "selbstverständlich" alle Clients anpingbar.

Ich forwarde zur Zeit so:
10.10.0.0 bei Maske 255.255.255.0 via 10.10.0.1 an eth0
192.168.123.0 bei Maske 255.255.255.0 via 192.168.123.1 an eth1
0.0.0.0 bei Maske 0.0.0.0 via 84.x.x.73 an eth2

Vielen Dank für eure Antworten! :wink:
 

spoensche

Moderator
Teammitglied
Wenn ich mich nicht irre, müssten die Regeln dafür so lauten:

Code:
iptables -A FORWARD -i eth0 -o eht1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
 
OP
N

nichtsooft

Newbie
jengelh schrieb:
Das hat nichts mit iptables zu tun -- hier fehlt eindeutig eine Route zu 84.x.x.73.

Da muss ich mich meinem Vorposter anschließen!

Und selbst wenn ich ne Route zu 84.x.x.0 lege, kann ich die nicht allgemein für beide internen Netze gültig machen, weil ich ja 2 versch. Gateways hab.

Ich hab jetzt in der sysconfig unter:
Code:
fw_custom_before_denyal() {
iptables -A FORWARD -i eth0 -o eht1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
}
eingefügt!

Edit: Hab auch ne route zu 84.x.x.73 hinzugefügt, trotzdem...

Kein Erfolg!
 

spoensche

Moderator
Teammitglied
nichtsooft schrieb:
Code:
fw_custom_before_denyal() {
iptables -A FORWARD -i eth0 -o eht1 -j ACCEPT

}
]
Bei der Regel muss es eth1 heissen, Tippfehler von mir, sorry. Biswt du sicher, dass die Regeln in der richtigen Funktion stehen? Du forwardest ja.
 
Oops ;-)
nichtsooft schrieb:
Und selbst wenn ich ne Route zu 84.x.x.0 lege, kann ich die nicht allgemein für beide internen Netze gültig machen, weil ich ja 2 versch. Gateways hab.
Die Route zu 84 ist ja nur für den Gateway selber, nicht für die internen.
Hosts aus dem 10.0.0.0/24 Subnetz haben 10.0.0.1 als GW, solche aus 192.168.123.0/24 eben 192.168.123.1.
 
OP
N

nichtsooft

Newbie
spoensche schrieb:
Bei der Regel muss es eth1 heissen, Tippfehler von mir, sorry. Biswt du sicher, dass die Regeln in der richtigen Funktion stehen? Du forwardest ja.

Versteh ich jetzt nicht ganz!? Wie meinste das? ist ja eh von eth0 -> eth1 und vice versa :?:
jengelh schrieb:
Die Route zu 84 ist ja nur für den Gateway selber, nicht für die internen.
Hosts aus dem 10.0.0.0/24 Subnetz haben 10.0.0.1 als GW, solche aus 192.168.123.0/24 eben 192.168.123.1.

Route hinzugefügt (für beide Netze) und trotzdem läuft's nicht! :evil:
 

spoensche

Moderator
Teammitglied
Ja so meinte ich das. Hatte bei meinem ersten Post mit den Regeln statt eth1 eht1 geschrieben, was ein Tippfehler (eht1 ist falsch) meinerseits war.

Sieh dir mal die Funktionen after_spoofprotection oder so ähnlich. Ich vermute, das die Regeln dort besser untergebracht sind, weil danach sofort das Forwarding kommt, wenn ich das richtig in Erinnerung habe.

Ein Beispiel bezüglich des SuSEfirewall2-custom findest du unter http://www.linux-tips-and-tricks.de/index.php/Beispielkonfigationsrepository/View-category.html?ascdesc=DESC&orderby=dmdatecounter
 

Tooltime

Advanced Hacker
Warum versucht eigentlich jeder seine eigenen iptables-Regeln zu schreiben anstatt die vorgefertigten Mechanismen zu nutzen?

Versuch mal
  • YaST -> System -> Editor für /etc/sysconfig-Dateien
unter
  • Network -> Firewall -> SuSEfirewall2
der Parameter

  • FW_FORWARD = 10.10.0.0/24,192.168.123.0/24 192.168.123.0/24,10.10.0.0/24
 
OP
N

nichtsooft

Newbie
Tooltime schrieb:
Warum versucht eigentlich jeder seine eigenen iptables-Regeln zu schreiben anstatt die vorgefertigten Mechanismen zu nutzen?

Versuch mal
  • YaST -> System -> Editor für /etc/sysconfig-Dateien
unter
  • Network -> Firewall -> SuSEfirewall2
der Parameter

  • FW_FORWARD = 10.10.0.0/24,192.168.123.0/24 192.168.123.0/24,10.10.0.0/24


Wenn du mir einfach sagst welche Datei das ist, mach ich das mit VIM. Ich betreibe das OS im Textmodus und habe die von dir genannten Parameter nicht in meinem Yast! :p
 

whois

Ultimate Guru
HI

Ich sitze zwar nicht vor einem Suse PC aber guck mal hier.

Code:
/etc/sysconfig/SuSEfirewall2

cu
 

Tooltime

Advanced Hacker
Ganz einfach:
Yast starten,
in linker Spalte der dritte Eintrag -> System auswählen und mit TAB in recht Spalte wechseln.
Bei 10.1 zweiter Eintrag "Editor für /etc/sysconfig-Dateien" auswählen.
Bei 11.0 erster Eintrag "/etc/sysconfig-Editor" auswählen.
Mit Alt+s nach FW_FORWARD suchen.

Ich finde wenn es schon extra so ein Tool gibt, dann sollte man es auch Benutzen.
 
OP
N

nichtsooft

Newbie
Tooltime schrieb:
Ganz einfach:
Yast starten,
in linker Spalte der dritte Eintrag -> System auswählen und mit TAB in recht Spalte wechseln.
Bei 10.1 zweiter Eintrag "Editor für /etc/sysconfig-Dateien" auswählen.
Bei 11.0 erster Eintrag "/etc/sysconfig-Editor" auswählen.
Mit Alt+s nach FW_FORWARD suchen.

Ich finde wenn es schon extra so ein Tool gibt, dann sollte man es auch Benutzen.

Danke für deine genaue Beschreibung! Leider abe ich die besagten Optionen nicht in meinem Yast!
Unter "System" finden sich bei mir lediglich folgende Einträge:
  • Boot Loader
  • Date and Time
  • LVM
  • Language
  • Partitioner


whois schrieb:
HI
Ich sitze zwar nicht vor einem Suse PC aber guck mal hier.
Code:
/etc/sysconfig/SuSEfirewall2
cu

So hab das jetzt mal per VIM in die von whois genannte Datei (die übrigens den Eintrag FW_FORWARD="" hatte) eingetragen. Ich teste gleich mal...

Edit: Nö! Leider nur ein Telerfolg!
Versuche ich jetzt zu pingen bekomme ich in beide Richtungen versch. Ergebnisse!
Pinge ich von 10.10.0.254 den client 192.168.123.19 an klappt das wunderbar!
Pinge ich jedoch von 192.168.123.19 den 10.10.0.254 an bekomm ich ne Zeitüberschreitung.

Einträge hab ich nochmal überprüft, die sollten so weit passen!
 
OP
N

nichtsooft

Newbie
SRY wegen Doppelpost; Scheint mir aber so übersichtlicher zu sein...

Also was das connection Problem angeht muss ich hinzufügen, dass nichtmal der Server selbst in der Lage ist, den Client 10.10.0.254 anzupingen!
Ich hatte ein ähnliches Problem schon mit nem Linksys-Router. Selbe Netze PING A->B ok, aber B->A unmöglich.
Könnte das Problem daher rühren, dass ich ne 10.10.0.x/24-IP an ner 255.255.255.0 Netmask verwende!? Oder ist das rein IP-Mathematisch ok!?
 

Tooltime

Advanced Hacker
Ich kenne keinen Grund warum man nicht ein Klasse A Netz in B- oder C-Subnetze aufteilen sollte, dafür ist die Netzmake ja da. Probleme treten eigenlich immer nur mit Broacast auf. In der Vor-Switch-Zeit mit BNC-Kabeln hat man oft so größere Netze vom Gateway auf Gebäude und dann Etagen, Abteilungen oder Institute aufgeteilt.

Ich kenne aber auch keinen Grund oder eine entsprechende Firewall-Regel die ein ping aus der Firewall verhindern, bzw. die Antwort des Clients abweisen. Ist Zufällig auf 10.10.0.254 auch eine Firewall aktiv die ein ping verhindert. Funktionieren den ssh bzw. andere tcp oder udp Verbindungen mit dem Ziel 10.10.0.x/24 (ping benutzt icmp)? Wenn eine Firewall-Regel scheinbar nicht funktionert wiederspricht sie vielleicht einer anderen.
Beispiel:

  • FW_FORWARD = 10.10.0.0/24,192.168.123.0/24
    FW_FORWARD_DROP = 10.10.0.0/24,192.168.123.0/24
wer wird gewinnen. Aber die interessantes Frage ist für mich, Antwortet 10.10.0.254 überhaupt auf ein ping. Wenn ja sind eth0 u. eth1 wirklich als internes Interfaces definiert (Stichwort DMZ).
 
OP
N

nichtsooft

Newbie
Ja loooooooooooooooooooooooooooooooooooool!

DANKE tooltime!!! Stutzig hat mich folgender Kommentar gemacht:
Tooltime schrieb:
Ich kenne aber auch keinen Grund oder eine entsprechende Firewall-Regel die ein ping aus der Firewall verhindern...
Wie ich ja schon mal gepostet hatte kann ich den 10...254er nicht mal vom Server aus anpingen! Und welches dumme Programm aus Redmont verhindert nen Ping?
SRY 4 word: Ich idiot hatte tatsächlich vergessen auf dem betreffenden Client die Win-Firewall zu deaktivieren! :roll:
Eigentlich sollte man mich ja steinigen, aber eins will ich noch los werden:

Danke an alle Poster, die sich hier eingebracht haben! Ihr seit echt ne super Truppe! :!: Jetzt muss ich es nur noch zu Stande bringen den SHCP automatisch beim Booten zu starten...
Hat dafür jmd nen Plan, oder soll ich dafür nen eigenen Thred starten? Übersichtlicher wär's (sollte irgendjemand die Suche verwenden) ;) .
 
Oben