Am 23.08.2010 12:52, schrieb Fred Ockert:

Harald Oehlmann schrieb:

...

Hallo Liste,

da wir 2 DSL-Verbindungen haben, möchte ich gerne beide nutzen: dsl1 (adsl): genereller Internetverkehr dsl0 (sdsl): eingehende VPN's und Entlastung für dsl1 (multipath route mit einer großen Gewichtung für dsl1, dann geht noch was falls dsl1 ganz ausfällt)

na ja .. VPN geht dann trotzdem nicht denke ich mir so..

Naja, VPN wird ja von aussen initiiert und somit ist die Quell-IP bekannt. Also theoretisch gehts. Nur ist NAT eben normalerweise auf 1-zu-n gebaut oder ich habe einfach zu wenig Ahnung davon.

...

Beide dsl haben feste IP's (im Internet), geben wir aber als lokale IP unterschiedliche IP Adressen. Da die Telecom die dsl einmal am Tag abbaut bekommen wir lokal vermutlich immer eine neue IP.

Häää ... intern ist dein Bier, wenn schon bekommt die externe Seite gelegentlich mal eine neue IP (dyndns hilft).. also nach jedem Netzumbau oder DHCP-Server Reset (beim Provider)

Ja, habe Mist geschrieben. Beim dsl-Connect wird eben übergeben: Gateway (die Gegenstelle) und lokal (meine Feste IP-Adresse). Nur der Gatway kann sich ändern, was vermutlich selten passiert. Dyndns brauche ich nicht, feste ip.

...

Der SuSE-Linux Rechner macht nur Firewall und NAT-Routing zwischen den zwei DSL und einem Ethernet zu dem eigentlichem Linux Server, wo auch OpenVPN läuft. Ich habe SuSE 11.0 darauf gespielt, da nur 384MB RAM. Bisher habe ich nur einen Forward in den Firewall-Regeln für VPN drin: UDP port 443. Trotzdem benötigt das Interface mit vpn den default route, sonst gehen wohl keine Pakete zurück.

nicht wirklich.. aber natürlich müssen die Antwortwege bekannt sein, ich kann auch die vpn-Kiste einfach als (Standard)Gate eintragen..oder eben extra VPN-Routen (hier...bei Net-2-Net Kopplungen)

huch sooo grosse Kisten mit soviel Heizleistung :) ....da musst du aber schon richtig dicke sDSL-Leitungen haben... Hier tut openVPN auf einem AlixBoard (LX800 CPU mit 256 MB RAM) ..eine Kiste via Kabel Deutschland, eine via Vodafone... die Clients haben einen Fall-Back-Liste, der erste Treffer gilt...und wenn der nicht antwortet dann eben der nächste Treffer in der Liste...

Ja, ich habe einen alten Rechner genommen mit 256MB RAM und wollte SuSE-Linux 11.2 darauf spielen und der Installer sagte, daß 384 Minimum sind. So habe ich noch einen Riegel eingesteckt. Ich habe es wohl nicht drauf ohne X11 zu installieren. Die Sache ist sowohl energetisch als auch wegen Ausfallsicherheit blöd, aber ich wollte die Funktion nicht in den Server schieben, wegen Sicherheit.

Outgoing Traffic .. kann man Loadbalancer machen... oder einfach per DHCP unterschiedliche Gateways zuweisen :)

Nun, der Router-PC hat nach innen nur einen Clienten, den Server. Vom Arbeitsplatz hat niemand einen Route nach draussen, alles Proxy etc...

Also durchasu mehrere Lösungen.. aber vorher bitte ein wenig in Router/routing einlesen..es erspart viel Zeit (manchmal) .

Hast du hier einen besonderen Tipp ? Danke, Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

On Mon, Aug 23, 2010 at 03:43:41PM +0200, Harald Oehlmann wrote: [ 8< ]

Eine Schleife in einem Script etc, überrollt mich erst mal und muß ich erst ausprobieren.

/etc/sysconfig/network/scripts/postup-br1 als weitere Anregung im Anhang. Nicht elegent. Aber es funktioniert so bereits seit mehreren Jahren und hat viele Upgrades unbeschadet überstanden. Sicherlich auch nicht die effektivste Art. Da das Skripte aber nur alle paar Wochen nach einem Reboot aufgerufen wird, konnte ich damit bisher gut leben. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

Hallo Liste, Ziel ist auf einem SuSE 11.3, der nur als Router und Maskerading Firewall fungiert, mit 2 DSL-Verbindungen via pppoe und einer Netzwerkverbindung zu einem Server mit OpenVPN die VPN-Pakete über die eine dsl- und die restlichen Pakete über die andere dsl-Verbindung zu routen. Auf dem Router ist: - dsl0 (via eth1): T-COM SDSL mit fester IP - dsl1 (via eth2): T-COM ADSL mit fester IP - eth0: zum Server Das dsl0 soll nur für VPN genutzt werden. Hier sollen sich unsere Home-Offices Verbinden. dsl1 soll all unseren Internetverkehr abwickeln. vpn nutzt udp Port 443. Für Multiroute hat Lars Müller schon ein gutes Skript gepostet (Das Ziel "Multiroute" habe ich erst einmal zurückgestellt). Das Thema sind die Outbound-Pakete, also VPN gegen die default route aus dsl0 zu senden. SuSE-Firewall: - In der SuSE-Firewall unter Maskerading ein Port forward gesetzt: Von "Fester IP von DSL0:443" nach "Server-IP:443" Damit kommen die Pakete gut hinein. Falls das "DNAT" ist, sollte auch der Rückweg über das selbe Interface gehen, das klappt aber nicht, die Rückpakete gehen via dsl1. - Einen schönen Trick steht in "Guide to IP Layer Network Administration with Linux": Man konfiguriert auf dem Server eine zweite IP (unter Netzwerkkarte alias). Jetzt richtet man den Port forward auf diese zweite IP. OpenVPN empfängt also jetzt mit dieser zweiten IP die Pakete und sollte dort auch Antworten. Dies tut OpenVPN aber nicht, es antwortet mit der ersten Serveradresse, ausser wenn man ihm mit "local <zweite Server IP>" in der Konfigurationsdatei sagt, nur auf diese Adresse zu antworten. Jetzt kann man auf dem Router Pakete von der zweiten Server-IP auf dsl0 routen. Ich habe diese Lösung wieder rückgebaut, da ich oft ICMP-Pakete mit "No route to host" sah und Arp-spoofing vermutete. Ich wollte ja eigentlich erreichen, daß man über beide dsl Leitungen vpn Verbinden kann (Multiroute). Das verhindert aber der "local". Deshalb dachte ich, es ist einfacher, im Router alle VPN-Pakete durch ihren Quellport auf dsl0 zu routen. Dann brauche ich den Server nicht modifizieren. <Schnell-Ende> - Policy routing von udp Quellport 443 auf dsl0 1) Splitroute aufgesetzt: Dafür eine neue Routing-Tabelle mit Namen "dsl0" als Kopie der Tabelle main aufgesetzt, nur daß das default-Route auf dsl0 statt 1 steht: An Datei "/etc/iproute2/rt_tables" angefügt: "1<tab>dsl0" ip route show table main | grep -vE "^default" \ | while read ROUTE ; do ip route replace table dsl0 $ROUTE done ip route add default dev dsl0 table dsl0 src $DSL0_IP Ich habe diese Lösung genutzt, da ich so die Peer-Adressen der pppoe, die jeweils ein route haben, gleich mit kopiere. Jetzt diese getestet: ip rule add table dsl0 prio 20001 Jetzt gehen alle Pakete über dsl0 statt dsl1. VPN verbindet auch. Gut, test wieder gelöscht: ip rule del table dsl0 prio 20001 2) Jetzt nur die Pakete mit udp sport 443 auf diese Tabelle: iptables -A PREROUTING -t mangle -p udp --sport 443 -j MARK \ --set-mark 4 ip rule add from all fwmark 4 table dsl0 prio 20000 ip route flush cache Mit "iptables -Lv -tmangle" kann man sehen, daß die Pakete über die Regel laufen. Nur nach dsl0 werden sie nicht geroutet (Ich teste das mit Wireshark, was überall mitläuft). Hat hier jemand eine Idee ? Ich vermute, ich muß an der Firewall etwas drehen oder (oh-nein !) diese manuell aufsetzen. Danke für jede Idee, Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Übersicht: ---------- Am 31.08.2010 09:54, schrieb Harald Oehlmann:

Ziel ist auf einem SuSE 11.3, der nur als Router und Maskerading Firewall fungiert (im folgenden *Router* genannt), mit 2 DSL-Verbindungen via pppoe und einer Netzwerkverbindung zu einem Server (im folgenden *Server* genannt) mit einem OpenVPN Server, die VPN-Pakete über die eine dsl- und die restlichen Pakete über die andere dsl-Verbindung zu routen.

Auf dem Router ist: - dsl0 (via eth1): T-COM SDSL mit fester IP 8.8.8.8 - dsl1 (via eth2): T-COM ADSL mit fester IP 9.9.9.9 (beide haben kein Gateway, da pppoe) - eth0: zum Server mit IP 192.168.201.2

Das dsl0 soll nur für VPN genutzt werden. Hier sollen sich unsere Home-Offices Verbinden. dsl1 soll all unseren Internetverkehr abwickeln.

vpn nutzt udp Port 443.

Da ich auf dem Router-PC es nicht hin bekommen habe, Pakete für udp port 443 eine andere Route zu geben (siehe Post vom 31.8.2010 9:54) (ich hätte dafür die SuSEFirewall analysieren müssen), habe ich jetzt folgende Lösung implementiert: Auf dem Server wird auf das Ethernetinterface eine zweite IP-Adresse gelegt. Dieses wird nur vom OpenVPN Service genutzt. Der Router schickt via Port Forward alle VPN-Pakete zu der zweiten IP-Adresse. Alle Daten von der zweiten IP-Adresse werden via dsl0 geroutet. Die erste wird via dsl1 geroutet. Vorgehensweise: --------------- 1) Servereinrichtung 1.1) Server IP alias YaST->Netzwerkgeräte->Netzwerkeinstellungen-> <Schnittstelle zum Router>[Bearbeiten] (hat bei mir IP: 192.168.201.147) ->Zusätzliche Adressen [Hinzufügen] Aliasname: 1 (wird hinterher hinter denn Gerätenamen gehängt) IP-Adresse: 192.168.201.148 (wird in diesem Text *zweite IP-Adresse* genannt) Netzmaske:/24 (die selbe wie die primäre Adresse) 1.2) OpenVPN auf zweites Interface In Datei "/etc/openvpn/server.conf" die zweite IP-Adresse als Server-Adresse hinzufügen: "local 192.168.201.148" (ohne diese Zeile sendet der Server Pakete, die via 192.168.201.148 empfangen wurden munter über die erste IP-Adresse (192.168.201.147) zurück) (Wenn man möchte, daß OpenVPN auf beiden Schnittstellen antwortet, könnte man einen zweiten Server einrichten) 2) Routereinrichtung 2.1) Den Default route via dsl1 setzen: YaST->Netzwerkgeräte->DSL->dsl0/1[Ändern]->3 Seiten weiter->[IP-Details]: für dsl0: Option "Standardroute" aus, für dsl1 an 2.2) In Firewall Weiterleitung aktivieren: YaST->Sicherheit->Firewall->Masquerading->Anfrage an Masqueraded IP umleiten[Hinzufügen] Quell-Netzwerk: 0/0 (von jedem im Internet) Benötigte IP: 8.8.8.8 (feste IP von dsl0 im Internet) Protokoll: UDP Benötigter Port: 443 An Masquerading IP umleiten: 192.168.201.148 (die zweite IP-Adresse) An Port umleiten: 443 2.3) Eine neue Routing-Tabelle mit dem Namen "dsl0" aufsetzen und diese für Pakete *von* der zweiten IP-Adresse nutzen. Die neue Tabelle ist identisch zur Standardtabelle, bis auf die Default Route, die auf dsl0 zeigt. 2.3.1) Routing-Tabellennamen anlegen An Datei /etc/iproute2/rt_tables anhängen: (<tab> ist der Tabulator) 1<tab>dsl0 2.3.2) Script einbinden, das beim dsl-connect das routing konfiguriert. Dafür zu den Dateien /etc/sysconfig/networt/ifcfg-dsl0 und /etc/sysconfig/networt/ifcfg-dsl0 hinzufügen: POST_UP_SCRIPT='postup-dsl01' (bei solchen Sachen immer darauf achten, daß jede Zeile (und auch die letzte) mit "<lf>" abgeschlossen ist). 2.3.3) Script schreiben und ausführbar machen Folgende Datei in /etc/sysconfig/networt/scripts/postup-dsl01 ablegen: #! /bin/bash PATH="/sbin:/bin:/usr/sbin:/usr/bin" set -x INTERFACE=$2 DSL0_IP="8.8.8.8" ALIAS_IP="192.168.201.148" # Aufbau: table dsl0 # Kopiere die main Tabelle ausser der default-route ip route show table main | grep -vE "^default" \ | while read ROUTE ; do ip route replace table dsl0 $ROUTE done # Setze default route auf dsl0 # (einziger Unterschied zu table main) if [ "${INTERFACE}" = "dsl0" ] ; then ip route replace default dev dsl0 table dsl0 src $DSL0_IP fi IP_RULE_SHOW=$( ip rule show) echo ${IP_RULE_SHOW} | grep -q "2000:" || \ ip rule add from $ALIAS_IP table dsl0 prio 2000 ip route flush cache -EOF- und ausführbar machen: chmod a+x /etc/sysconfig/networt/scripts/postup-dsl01 Bemerkungen: ------------ Erstmal einen großen dank an Lars Müller für sein Beispielskript, was hier schamlos abgewandelt wurde. Sein Wunsch nach einem generischen Script ist hier leider nicht in Erfüllung gegangen. Es bleibt also spannend. Einiges zum Skript: - Man das "set -x" löschen, sobald man genug von Debug-Ausgaben hat. - Meine Main Routing Table sieht so aus (Mit Buchstaben zum späteren referenzieren): # ip route list table main (a)9.9.9.23 dev dsl1 proto kernel scope link src 9.9.9.9 (b)8.8.8.44 dev dsl0 proto kernel scope link src 8.8.8.8 (c)192.168.201.0/24 dev eth0 proto kernel scope link src 192.168.201.2 (d)127.0.0.0/8 dev lo scope link (e)default dev dsl1 scope link - wird ein dsl device geschlossen, so werden ja alle Referenzen aus den Routing-Tabellen gelöscht. Man kann auch nur Sachen anlegen, wo die Devices wirklich existieren. Deshalb lasse ich das Skript bei den Connects von beiden Schnittstellen laufen. Wenn dsl1 Connected, so erscheinen eben erst die dsl1-spezifischen Sätze in der Main-Tabelle (a,e). - Ich kopiere die Main Routing Tabelle, da sich die Ziele der pppoe-Tunnels (9.9.9.23 in (a) und 8.8.8.44 in (b)) pro Verbindung ändern. Ich nutze "ip route replace" (und nicht add), damit es keine Fehlermeldungen gibt und ein Existenztest mit grep mir zu schwierig war. (Trick von http://linux-ip.net/html/adv-multi-internet.html Ex1.1) - Der Default route wird in die Tabelle dsl0 nur gesetzt, wenn gerade dsl0 connected. - Damit die Regel verwendet wird ist nötig: ip rule add from 192.168.201.148 table dsl0 pri 2000 Hier wird also gesagt: Pakete *von* dieser IP werden (zuerst) mit der Routingtabelle dsl0 geroutet. Falls Device dsl0 nicht up ist, existiert kein Default route und es wird an main weiter gegeben, womit sie dann via dsl1 geroutet werden. Falls dsl0 up ist steht dort ein default route auf dsl0 und alles purzelt da raus. Die Priorität muß zwischen 2 und 65534 liegen. Diesen Befehl könnte man schon ausführen, während das Routing beim Systemstart eingerichtet würde. Er darf eben nicht zweimal ausgeführt werden. Deshalb wird vorher geprüft, ob schon eine Regel mit der Priorität 2000 existiert (also der String "2000:" von "ip rule show" zurück gegeben wird. Danke an alle, Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org