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)
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.
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.
Ich habe jetzt die Howto's gelesen: - Linux Advanced Routing & Traffic Control HOWTO - www.linuxhorizon.ro/iproute2.html
Wie komme ich da hin: Zwei Tabellen in /etc/iproute2/rt_tabels einbauen -> kein Problem.
Jetzt ist mit "ip route" einiges zu setzen. Nur wo mache ich das ? In welche Datei lege ich am besten die Routerkonfigurationsbefehle ab ? Ich muß ja irgendwie mit vielen Variablen mit den aktuellen IP-Adressen die Sache konfigurieren.
Ich wollte erst einmal nur den Split-Access aufsetzen und schauen, ob das reicht. Falls nicht, würde ich noch alle VPN'pakete via ipchain tagging der udp:443 fest über dsl0 routen.
- Sind das so gute Ideen ? - Gibt es hier Beispiele ?
Vielen dank für jede Hilfe, Harald
Hallo zusammen,
On Montag 23 August 2010, Harald Oehlmann wrote:
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.
Als Tipp auf die Schnelle: Sind das Business-Anschlüsse? Dann kannst Du über das Webinterface der Telekom die feste IP aktivieren. Ich denke, das dürfte recht praktisch sein bei dem, was Du vorhast.
Liebe Grüße
Erik
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..
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)
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...
Outgoing Traffic .. kann man Loadbalancer machen... oder einfach per DHCP unterschiedliche Gateways zuweisen :)
Einfach die Last(en) ansehen...
- Linux Advanced Routing& Traffic Control HOWTO
- www.linuxhorizon.ro/iproute2.html
Wie komme ich da hin: Zwei Tabellen in /etc/iproute2/rt_tabels einbauen -> kein Problem.
Also durchasu mehrere Lösungen.. aber vorher bitte ein wenig in Router/routing einlesen..es erspart viel Zeit (manchmal) .
Fred
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
On Mon, Aug 23, 2010 at 09:37:24AM +0200, Harald Oehlmann wrote:
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)
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.
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.
11.0 bekommt keine Sicherheitsupdates mehr. 11.3 kann man mit so viel RAM ohne Probleme benutzen. Stichworte: ohne X11 + swapon im Installationssystem. Das YaST-Installationssystem-Biest ist so geschnittenbrotig, dass es das sogar von sich aus vorschlägt, wenn es eine Partition, die als swap markiert ist, findet.
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.
Ich habe jetzt die Howto's gelesen:
- Linux Advanced Routing & Traffic Control HOWTO
- www.linuxhorizon.ro/iproute2.html
Wie komme ich da hin: Zwei Tabellen in /etc/iproute2/rt_tabels einbauen -> kein Problem.
Gut. Richtige Stelle gefunden!
Jetzt ist mit "ip route" einiges zu setzen. Nur wo mache ich das ? In welche Datei lege ich am besten die Routerkonfigurationsbefehle ab ? Ich muß ja irgendwie mit vielen Variablen mit den aktuellen IP-Adressen die Sache konfigurieren.
Das ist nicht erforderlich. Besser: Es sollte nicht erforderlich sein.
Warum "sollte"? Weil ich es bisher lediglich auf Systemen konfiguriert habe, die statische Adressen benutzt haben.
Ich habe dazu in der /etc/sysconfig/network/ifcfg-<IF_NAME>
POST_UP_SCRIPT="postup-<IF_NAME>"
gesetzt. In /etc/sysconfig/network/scripts/postup-<IF_NAME> wird per
ip rule add from $ip table ${INTERFACE} prio $offset
in einer Schleife das source based oder policy routing aufgesetzt.
Nachdem die rule gesetzt wurden sind noch passende "ip route add table" Aufrufe erforderlich. Ich benenne the table schlicht nach dem jeweiligen Interface.
ip route add table ${INTERFACE} ip_network/mask dev ${INTERFACE}
Einen eleganteren Weg habe ich bisher nicht gefunden. Ich würde mich freuen, wenn es eine generische Lösung geben würde.
Lars
Harald Oehlmann schrieb:
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)
[.....]
Naja, VPN wird ja von aussen initiiert und somit ist die Quell-IP bekannt.
was für VPNB (?) openVPN oder IPSec ( bist du Server oder Client ) reden wir von net-2-net oder von Roadwarriors ?
Muss man die Quell-IP wissen ? Wird so was nicht eigentlich mit Zertifikaten geregelt (wem man über den Weg traut..)?
auch wegen Ausfallsicherheit blöd, aber ich wollte die Funktion nicht in den Server schieben, wegen Sicherheit.
ja ist ja auch nicht verkehrt ... testweise darf das eine 400Watt Brate ...heizt schön :)
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.
dann gib dem Server einen Zusatzroute für das VPN-Net und fertig... Gateway-Konfiguration macht erst Sinn, wenn es mehrerere sind.
Zum Loadbalancing..siehe andere Mail (nicht von mir)... zu NAT .... letztlich musst du nur den (die) VPN-Ports vom Internetgate auf den VPN-Server "werfen"
also Beispiel: (openVPN) Internet: 11.11.11.11:12345 (der kommt also auf dem Internet auf Port 12345 rein ... und wird dann auf (intern) 172.19.19.19:54321 weitergeleitet , wo der VPN-Server lauscht (weggelassen: ob UDP oder TCP).. da kann zwischendurch genattet werden, wie will...wichtig ist nur, dass die benötigten Ports exakt durchgereicht werden... auch über mehrere Geräte mit NAT
(mache hier openVPN unbd NATte 2..3 mal je nachdem :) )
Fred
PS: nach meinen bisherigen Erfahrungen, ist ein Providerausfall wahrscheinlicher, als ein Hardwaredefekt bei Dir..und wenn T-Com weg ist, ist alles von T-Com weg :). Entweder du hast 2 verschiedene Netze (DSL + UMTS) oder T-Com (und Anmieter) und TV-Kabel-Internet... oder .. tjä
Am 23.08.2010 14:39, schrieb Lars Müller:
On Mon, Aug 23, 2010 at 09:37:24AM +0200, Harald Oehlmann wrote: 11.0 bekommt keine Sicherheitsupdates mehr. 11.3 kann man mit so viel RAM ohne Probleme benutzen. Stichworte: ohne X11 + swapon im Installationssystem. Das YaST-Installationssystem-Biest ist so geschnittenbrotig, dass es das sogar von sich aus vorschlägt, wenn es eine Partition, die als swap markiert ist, findet.
Ja, danke, hilft!
Jetzt ist mit "ip route" einiges zu setzen. Nur wo mache ich das ? In welche Datei lege ich am besten die Routerkonfigurationsbefehle ab ? Ich muß ja irgendwie mit vielen Variablen mit den aktuellen IP-Adressen die Sache konfigurieren.
Warum "sollte"? Weil ich es bisher lediglich auf Systemen konfiguriert habe, die statische Adressen benutzt haben.
Meins ist auch statisch. Ich war hier vorher (und bin es immer noch) unklar, welche IP sich trotzdem ändern kann...
Ich habe dazu in der /etc/sysconfig/network/ifcfg-<IF_NAME>
POST_UP_SCRIPT="postup-<IF_NAME>"
gesetzt. In /etc/sysconfig/network/scripts/postup-<IF_NAME> wird per
ip rule add from $ip table ${INTERFACE} prio $offset
in einer Schleife das source based oder policy routing aufgesetzt.
Nachdem die rule gesetzt wurden sind noch passende "ip route add table" Aufrufe erforderlich. Ich benenne the table schlicht nach dem jeweiligen Interface.
ip route add table ${INTERFACE} ip_network/mask dev ${INTERFACE}
Einen eleganteren Weg habe ich bisher nicht gefunden. Ich würde mich freuen, wenn es eine generische Lösung geben würde.
Danke, sysconfig etc. gefällt mir schonmal sehr gut. Ich möchte eben immer so nahe am SuSE bleiben wie möglich und auch der Firewall etc. nicht in die Quere kommen.
Eine Schleife in einem Script etc, überrollt mich erst mal und muß ich erst ausprobieren.
Vielen dank, das geht für mich in die richtige Richtung.
Danke, Harald
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
Am 23.08.2010 16:26, schrieb Lars Müller:
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
Hallo Lars,
ok, tolles skript, was vollen Multilink aufbaut. Passt gut zu dem advanced routing howto. Leider fangen jetzt die Fragen erst an...
Ich komme leider nicht raus, was hier was ist. Im vergleich zum Howto ist einiges mehr und einiges weniger...
Sind die IP_Adressen in IP_ADDRESSES (6 Stück) alles links nach draussen? Oder sind das die sekundären Netzwerkinterfaces, die Primären werden mit der Standardmimik abgebildet und tauchen hier nicht auf ?
Beispiel mit nur 2 statt 6: Devices: dsl0, dsl1 Eigene Feste IP-Adressen: 192.168.62.160 10.8.1.94 Gateway des Providers: 192.168.63.254, ?
/etc/iproute2/rt_tabels hinzufügen: 1 dsl0 2 dsl1
Es wird also pro verbundenem Interface (hier dsl1) gesetzt: 1)ip rule add from 192.168.62.160 table dsl1 prio 3000 2)ip rule add from 10.8.1.94 table dsl1 prio 3001
3)ip route add table dsl1 192.168.62.0/23 dev dsl1 4)ip route add table dsl1 10.8.0.0/14 dev dsl1 5)ip route add table dsl1 via 192.168.63.254 dev dsl1
Diese 5 Regeln existieren also bei Verbindung von dsl0 und dsl1 für jedes Interface ein mal.
Sollte Regel 1 und 2 nicht jeweils für das Interface gesetzt sein ? Hier wird es doch immer für beide gesetzt? Also bei dsl1 eben nur Regel 2 und nicht 1 ?
Regel 3 und 4 Routen alle Adressen auf das neue Interface. Regel 5 macht den Default route immer auf eine Adresse.
Vielen dank, vor mir liegt scheinbar noch einiges an Weg.
Danke, Harald
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.
<für Schnelleser diesen Absatz bitte überspringen> - 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
Harald Oehlmann schrieb:
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.
läuft hier...wenn auch nicht auf susi11,3 (tut auf IPCop) simple: dsl1 ist das Standardgateway
(du ermittelst bitte, mit welchen Netz VPN reinkommt) Gate für VPN ist dann dsl1 ...fertich!
VPNs haben wohl auch kein eth-x Device sondern Tun/tap-Devices.. (hier tut übrigens openVPN )..und da ist auch nix mit Firewall - der Tunnel endet eh innen ( von innen: vor der Firewall) Wenn Susi die Tunnel mitmacht, alles kein Thema, Rest wäre geschickter Netzaufbau (mit einem [Standard]router ...oder jeder beteilgte Server bekommt eine extra (VPN) Route.
Ich habe hier 2 (3) Roadwarrior Einstiege und 2 Net-2-Net Verbindungen. Die Roadwarriors steigen wahlweise auf 2 verschiedenen Providern ein (kommen also mit unterschiedlichen IPs rein) ..connecten nur eine überschaubere Serveranzahl.. somit kennen die Server alle (Rück)routen zu VPN...und was sie nicht kennen, geht eben ins Internet weiter! Auf die Art laufen auch die Aussenarbeitsplätze über unseren Squid-Webproxy...
Fred
Ü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
-
Erik P. Roderwald -
Fred Ockert -
Harald Oehlmann -
Lars Müller