Linux Schulungen: http://www.opensource-training.de  
 
Foren > Firewalling mit Linux > Probleme Multilink Gatway
Navigation
Schulungen
Foren
  Allgemeines Forum
  Intrusion Detection
  VPN mit Linux
  Firewalling mit Linux
  SELinux/AppArmor
SELinux/AppArmor Buch
IDS-Buch
VPN-Buch
Firewall-Buch
Nachrichten
Vorträge/Tutorials
Artikel
Linux-Magazin Artikel
Anmelden / Daten ändern
Messen
Impressum
Serverspiegel
Zertifizierungen
GPG Public Key

Flavours
English
German

Search

Visitors
Besucher 727638
Ansichten 519
Online 0


Probleme Multilink Gatway

Springe zu
Thema Verfasser Letzte Antwort
Probleme Multilink Gatway Udo ( ---.vdv-ag.de) 12 Aug 2008 12:42
Hallo zusammen,

ich weiß nicht, ob ich im richtigen Part gelandet bin aber ich lege einfach mal los,
erstmal zur Theorie:

ich betreibe einen Debian Linuxserver in Deutschland und einen für unsere Muttergesellschaft in Griechenland, die zwei Privaten Netze die dahinter hängen habe ich mit OpenVPN gebündelt, da die einzelnen Host, sowohl von Deutschland nach Griechenland, als auch umgekehrt über ihre Adresse erreichbar sein sollen, da verschiedene Datenbankserver dort stationiert sind.

Da die Internetleitungen in Griechenland nicht so stabil sind wie hier, hat mein Mann vor Ort eine zweite Leitung eingekauft, die ich nun mit einbinden möchte.

Struktur des Aufbaus:

------------Provider 1----eth0--
/
Lan1 Deutschland <---> Firewall (DE)<-----> Internet <------ Linux Gateway Greece (eth2) <----- >Lan2 Greece
-------------Provider2----eth1--/

Bezeichnen wir mal die einzelnen Teilabschnitte mit IP Adressen, die öffentlichen ersetze ich.

Lan1 = 192.168.0.0/24
Firewall DE = 193.xxx.xxx.xxx/29
tun DE = 192.168.100.1

Provider1 = 63.xxx.xxx.xxx/28
Provider2 = 82.xxx.xxx.xxx/28

GW Greece = Debian Etch mit 2.6.18-6-686
eth0 = 63.xxx.xxx.210 - gw 63.xxx.xxx.209
eth1 = 82.xxx.xxx.180 - gw 82.xxx.xxx.177
tun GR = 192.168.100.10
eth2 = 192.168.1.0/24

Provider 1 ist zwar langsamer aber stabiler, deshalb soll dieser als default Gateway erhalten bleiben und das Tun device an sich binden (ich muß gestehen das ich nicht weiß, ob es auch anders geht)

Provider 2 ist schneller, neigt aber zu ausfällen, deshalb sollen dort, für uns, "unwichtige" Dienste darüber laufen, momentan läuft nur Squid darüber, da ich in der config bestimmen kann, wie er wo rausgehen soll.

Was ich bisher gemacht habe, mit der Hilfe der Linux Advanced Routing & Traffic Control HOWTO

ip route add 63.xxx.xxx.xxx/28 dev eth0 src 63.xxx.xxx.210 table Provider1
ip route add default via 63.xxx.xxx.209 table Provider1
ip route add 82.xxx.xxx.xxx/28 dev eth1 src 82.xxx.xxx.180 table Provider2
ip route add default via 63.xxx.xxx.209 table Provider2

ip route add 63.xxx.xxx.xxx/28 dev eth0 src 63.xxx.xxx.210
ip route add 82.xxx.xxx.xxx/28 dev eth1 src 82.xxx.xxx.180

ip route add default via 63.xxx.xxx.209

ip rule add from 63.xxx.xxx.210 table Provider1
ip rule add from 82.xxx.xxx.180 table Provider2

ip route add 192.168.1.0/24 dev eth2 table Provider1
ip route add 82.xxx.xxx.xxx/28 dev eth1 table Provider1
ip route add 127.0.0.0/8 dev lo table Provider1
ip route add 192.168.1.0/24 dev eth2 table Provider2
ip route add 63.xxx.xxx.xxx/28 dev eth0 table Provider2
ip route add 127.0.0.0/8 dev lo table Provider2

Was alles klappt:
Alles bis auf Squid läuft über Provider 1, setze ich das Default Gateway auf Provider 2 funktioniert es umgekehrt.
Egal worauf das Gateway steht, kann ich den Server über beide öffentlichen IP per ssh erreichen, auch kein Problem
Den Webserver im internen Lan GR kann ich aber nur über die öffentliche IP erreichen, dessen Gateway gerade als Default eingetragen ist, hier Auzug meiner Iptables Regeln (learning by doing :-) ):

echo "...for Provider1"
$FW -t nat -A POSTROUTING -o $WORLDIF -s $LAN -j MASQUERADE

echo "...for Provider2"
$FW -t nat -A POSTROUTING -o $WORLDIF2 -s $LAN -j MASQUERADE

Folgender Eintrag funktionierte nicht, obwohl er richtig wäre, da eine feste IP vorhanden ist.
Das Problem: auch die Pakte im Tunnel wurden maskiert, was einige Server unerreichbar machte
#$FW -t nat -I POSTROUTING -j SNAT -s $LAN -d $WORLD --to-source 82.xxx.xxx.180
echo "$LAN:MASQUERADE"


$FW -t nat -A PREROUTING -i $WORLDIF -p tcp --sport 1024:65535 -d $HTTP_AUSSEN --dport 80 -j DNAT --to $HTTP_INNEN
$FW -t nat -A PREROUTING -i $WORLDIF2 -p tcp --sport 1024:65535 -d $HTTP_AUSSEN2 --dport 80 -j DNAT --to $HTTP_INNEN

$FW -t nat -A PREROUTING -p tcp --dst $HTTP_INNEN --dport 80 -j DNAT --to $LANIP

$FW -t nat -A PREROUTING -p tcp --dst $HTTP_INNEN --dport 80 -s $LAN -j DNAT --to $HTTP_AUSSEN
$FW -t nat -A PREROUTING -p tcp --dst $HTTP_INNEN --dport 80 -s $LAN -j DNAT --to $HTTP_AUSSEN2

$FW -t nat -A OUTPUT --dst $HTTP_AUSSEN -p tcp --dport 80 -j DNAT --to-destination $HTTP_INNEN
$FW -t nat -A OUTPUT --dst $HTTP_AUSSEN2 -p tcp --dport 80 -j DNAT --to-destination $HTTP_INNEN

$FW -A FORWARD -i $WORLDIF -o $LANIF -p tcp --sport 1024:65535 -d $HTTP_INNEN --dport 80 -m state --state NEW -j ACCEPT
$FW -A FORWARD -i $WORLDIF2 -o $LANIF -p tcp --sport 1024:65535 -d $HTTP_INNEN --dport 80 -m state --state NEW -j ACCEPT


Was nicht klappt:
Steht das Default Gateway auf Provider 1 läßt ist der Webserver nicht über eine öffentliche IP von Provider 2 erreichen und umgekehrt
Mache ich ein tcpdump auf eth1 kommt noch nicht mal eine Anfrage am Interface an, was die Fehlersuche nicht erleichtert.

Da das ein Produktivsystem ist, habe ich ein wenig mit dem SMTP Port herumgespielt, da über diesen hauptsächlich nur Mails an den Admin rausgehen
Ziel war es, wenn Provider1 das Default Gateway ist, die Mails über Provider 2 heraus zu senden, was aber nicht klappte und den Hauptmailserver unerreichbar machte

$FW -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark 0x2

ip rule add fwmark 0x2 table SMTP
ip route add default via 82.xxx.xxx.177 dev eth1 table SMTP
(eigentlich sollte es damit alles gewesen sein aber bei mir will es nicht klappen)

Was in der Zukunft klappen sollte:

Tunnel läuft über Provider 1, alles andere über Provider 2, sollte ein Provider ausfallen, soll alles über den laufen, der noch da ist.
Dieses Ziel muß nicht automatisiert erreicht werden, es reicht auch schon, wenn manuell ein Script angestoßen wird.

Nur bin ich mit meinem Latein am Ende und suche Rat bei den Profis.

Gruß

der Udo

RE: Probleme Multilink GatwayRalf ( ---.dip.t-dialin.net)12 Jul 2008 11:53
Hallo Udo,

> Folgender Eintrag funktionierte nicht, obwohl er richtig wäre, da eine feste IP vorhanden ist.
> Das Problem: auch die Pakte im Tunnel wurden maskiert, was einige Server unerreichbar machte
> #$FW -t nat -I POSTROUTING -j SNAT -s $LAN -d $WORLD --to-source 82.xxx.xxx.180
> echo "$LAN:MASQUERADE"
>
Das sollte sich lösen lassen, indem Du hier vorher ACCEPT-Regeln einfügst für die Systeme, die nicht genattet werden sollen.

Gruß,

Ralf
RE: RE: Probleme Multilink GatwayUdo ( ---.vdv-ag.de)15 Jul 2008 06:38
Hallo Ralf,

vielen Dank für's antworten, also wenn ich das richtig verstanden habe, ich definiere in den ACCEPT Regeln, das alles was als Ziel den Tunnel bzw. Ziele in anderen Lan's hinter dem Tunnel hat, nicht genattet wird, ist die Destination aber WORLD, dann wird genattet?

O.K. damit bin ich schon mal auf dem Weg, mein Firewall Script politisch korrekter aussehen zu lassen, nur für mein eigentliches Problem, das ich den Tunnel über Leitung A und Mail und sonstigen Traffic über Leitung B route, solange beide online sind, hilft es mir nicht weiter, stimmt's?

Gruß,
Udo
RE: RE: RE: Probleme Multilink GatwayRalf ( ---.dip.t-dialin.net)12 Aug 2008 12:42
Was die Routen betrifft, kannst Du dass auch mit iptables und -j ROUTE erledigen. Dann kannst Du entsprechende Firewall Regeln für alle drei Fälle vorbereiten:
1. Beide verfügbar
2. a verfügbar und b nicht
3. a nicht und b verfügbar
Diese Skripte können dann von Dir manuell angestossen werden.

Gruß,

Ralf

[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.


Umfrage

Welche Distribution verwenden Sie?

 A) Fedora Core
 B) SuSE
 C) Debian
 D) Mandriva
 E) Red Hat Enterprise Linux
 F) SuSE Enterprise Linux
 G) Slackware
 H) Ubuntu
 I) Gentoo
 J) Andere


Latest News
17 Oct 2008: Neue Schulung: Netzwerküberwachung mit Nagio...
17 Oct 2008: Neue Schulung: Virtualisierung mit KVM
24 Sep 2008: Business-Online Messe in Münster
24 Sep 2008: Eröffnungskonferenz am 25. September 2008
28 Aug 2008: Zertifizierung nach LPIC-3
Weitere News...

Login
eMail


Passwort



© 2002-2005 Ralf Spenneberg, OpenSource Security, Germany