Hallo, ich betreibe in meinem lokalen Netzwerk einen Server der die gesamten Aufgaben des Routers übernimmt. ics-dhcp-server sorgt für das nötige DHCP für die Clients bind9 fungiert als DNS Server Das Netzwerk ist wie folgt: Das Modem hat die IP 10.10.0.40 Der Server hat zwei Karten, eth0 und eth1. Eth0 = 10.10.0.1 (10.10.0.40 als Gateway) Eth1 = 10.10.0.2 Ein Client der verbindet bekommt eine IP im Bereich von .5X - .1XX zugewiesen, als DNS 10.10.0.1 sowie 10.10.0.2 und als Gateway die 10.10.0.1 Das passt alles soweit. Nach einem iptables -t nat -s 10.10.0.0/24 -o eth0 -j MASQUERADE Haben die Clients dann auch Internetzugriff (ip4 Forward auf 1) Soweit so gut. Nun habe ich aber noch tun0 (10.8.0.6) und tun1(10.9.0.6) Dies sind zwei VPN Server. Wie kriege ich den Traffic nun über die VPNs? Wenn ich bei den VPN Servern ein push "redirect-gateway def1" mache und dann mittels IP Tables ein MASQUERADE auf das tun anstatt auf das eth dann wird der Traffic über den vpn geroutet. Mache ich das nun bei beiden vpn Servern klappt das ganze trotzdem nur mit tun0 Habe ich jetzt jedoch nur eine normale vpn Verbindung (ohne das Push) und Versuche jetzt mittels Route die Pakete zu Routen... Crasht mir alles... Route add default gw 10.8.0.6 Dev tun0 bewirkt, das ein Ping endlos leer bleibt.. iwann kommt dann nen Connect Fehler.. Lösche ich die Route und mache das mit Route add default gw 10.10.0.40 Dev eth0 Geht wieder alles Ich verstehe das ganze nicht.... Wie kriege ich es hin das ich sagen kann... Jetzt leite les durch vpn1...und jetzt durch vpn2 .... Ist es aber der Magenta Receiver (Magenta TV) Route nicht über den vpn wegen dem IPTV.. Wie macht man das?
Du hast einen Router zwischen 10.10.0.0/24 und 10.10.0.0/24, was ja praktisch zwei mal das selbe Netz ist. Ich weiß nicht genau ob das ein Problem werden kann mit weiteren Netzen usw. Z.b Ping Antwort geht in welches Netz? Vielleicht klemmt es da und Masquerade hat ne Kriese. Es kann dann nur noch per 'Eth-Device' unterschieden werden. Versuch evtl das Modem Netz zu ändern. (Bzw dort, wo du 'weniger' umstellen müsstest -zum testen) Z.b. Netzblock u. Bereich ändern, eine Netzmaske /30 nur für den Server, wenn sonnst keine weiteren Geräte an der Modem-Seite vorhanden sind. Keine Ahnung ob das was bringt!? Viel Spaß.
:
Bearbeitet durch User
Sind die IPs mit .6 am Ende die der tun devices oder die des VPN Servers. Die Route muss selbstverständlich auf diesem zeigen. Denk auch dran, dass der VPN Client seinen eigenen Traffic weiter über das lokale Gateway leiten muss (push route bei OpenVPN legt hierzu eine extra route an!). Schau dir dazu doch einfach mal die generierten routing Tabellen an. Ein masquerade kannst du einfach auf alle outbound interfaces setzen (auch ohne source argument)
Rolf H. schrieb: > Der Server hat zwei Karten, eth0 und eth1. > Eth0 = 10.10.0.1 (10.10.0.40 als Gateway) > Eth1 = 10.10.0.2 Zwei Karten beide im gleichen SubNetz ? Warum ? Das ist milde gesagt grober Umfug oder hat einem ganz speziellen Grund. Oder Simpler Typo ? > Route add default gw 10.8.0.6 Dev tun0 bewirkt, das ein Ping endlos leer DEFAULT heiß auch "Gateway of Last Resort“, mehr als ein Default Gateway macht üblicherweise keinen Sinn auf einem Router. (eine menge ausnahmen bestätigen die regeln, sind dann aber spezielle Routing Tabellen die nur für bestimmte IP Bereichen gelten (Stichwort policy based routing) Du möchtest wahrscheinlich einzelne (netz)Routen und PNAT (MASQUERADE) für die Bereiche auch zu deinem Externen Interface. also iptables -t nat -s 10.8.0.6/24 -o eth0 -j MASQUERADE iptables -t nat -s 10.9.0.6/24 -o eth0 -j MASQUERADE > Wie macht man das? Deine Texte Dazwischen machen nur bedingt (für Fremde) Sinn, fehlen doch alle möglichen Angaben über netze, Software, Einstellungen und Ausgaben von aktuellen Einstellungen. z.B: Je nach VPN software (und deren Einstellungen) werden ggf. Policy Routen angelegt die ein "ip route“ nicht anzeigt („ip rule list“ ist dein freund zum starten), oder und die Firewall werden noch regeln gehauen um ggf. Kommunikation zu unterbinden....oder oder oder....
Also ich dachte das mit der verkabelung ist klar.... Fritzbox hat die IP 10.10.0.40 (DHCP usw AUS) von dort zwei Kabel zum Server (eth0 und eth1, mit den IPs .1 und .2) Dort hängt ein Switch und ein WLAN Accesspoint zwischen... Der Server macht DHCP, DNS, Gateway etc. Und dieser soll nur entscheiden, was über das inet direkt und was über welchen VPN geht. Ich will nun das der Server entscheidet, was durch den VPN(s) geht und was nicht.. Beispiel... Client A schaut Netflix ===>>> Route über eth0 und die Fritzbox ins Internet Client B surft auf google.de => Route über tun0 ODER tun1 tun0 und tun1 im besten alle als LoadBalancer... Also je nach auslastung mal da lang und mal da lang
Beitrag #7062839 wurde vom Autor gelöscht.
Beitrag #7062840 wurde vom Autor gelöscht.
Unabhängig von dem etwas verwirrenden Routing innerhalb des gleichen IP-Netzes für Clients, Server und Fritz würde mich interessieren, woran du auf Routing-Ebene Google erkennen willst?
:
Bearbeitet durch User
Bestimmte Geräte (Stream Boxen) sollen VPN NICHT nutzen. Die anderen Geräte schon, per load balancing. Daher nur die lokale Source IP und ggf Ziel Port als Kriterium nehmen. - nicht von DNS Query. (Man könnte es irgendwie' mit etwas Scripting auch mit DNS-Zielen u. den Anfragen genauer aufteilen. Die Routing Tablelle immer neu bauen. Usw. Ist aber zum Glück gar nicht gefragt worden und das vom TO hier ist viel weniger komplex, falls ich ihn richtig verstanden habe.)
:
Bearbeitet durch User
Rolf H. schrieb: > Client A schaut Netflix ===>>> Route über eth0 und die Fritzbox ins > Internet > > Client B surft auf google.de => Route über tun0 ODER tun1 das kannst du über verschiedene routing tables lösen. In der normalen "main" Table lässt du die Fritzbox als Gateway, in einer zusätzlichen "durchs_vpn"-Table legst du die Routen auf dein VPN. (die Tables sind numeriert, Namen kannst du in /etc/iproute2/rt_tables vergeben) Danach kannst du per "ip rule" oder per iptables-rules + "ip rule fwmark" pro Client, pro Destination Host/Port, pro TCP-Verbindung usw. festlegen, welche Routing-Tabelle benutzt werden soll.
Deine Konfiguration ist etwas... merkwürdig. Normalerweise müsstest Du Dein Netz aufteilen: 10.10.0.0/24 zwischen Fritzbox und Deinem Gateway eth0 (10.10.0.1/24). Dann ein zweites Netz, z.B. 10.10.1.0/24, wo eth1 Deines Gateways (10.10.1.1/24) angeschlossen wird. Du kannst auch den gleichen Switch switch nehmen, ist zwar nicht sonderlich sauber aber funktioniert. Die Clients bekommen dann eine IP aus dem 10.10.1.0/24 Subnetz zugeteilt und 10.10.1.1 als Default-Route und DNS. Wenn das Routing von der Quelladresse abhängen soll (also vom Gerät), müsstest Du wohl Policy Routing machen. Ob das mit dem LoadBalancer und den zwei Tunnel sinnvoll ist kann ich nicht beurteilen, verstehe nicht ganz was es bringen soll. Letztendlich begrenzt doch die Bandbreite Deines Anschlusses die Geschwindigkeit, wie soll das mit zwei Tunnel schneller werden?
Ach ja, für's load-balancing: zwei extra routing tables, eine für jedes VPN. Jede mit dem anderen VPN-Gateway als Fallback mit niedrigerer Prio, falls bei Ausfall einer VPN-Verbindung die andere übernehmen soll. dann per iptables mit contrack und "--ctstate NEW -m statistic --mode nth --every 2 --packet 0/1 -j MARK --set-mark 10/11" "-j CONNMARK --save-mark" "--ctstate ESTABLISHED,RELATED -j CONNMARK --restore-mark" "ip rule add fwmark 10 table VPN1" "ip rule add fwmark 11 table VPN2" usw. die Verbindungen auf die beiden Tables verteilen. Das "contrack, related,save-restore" gewurschtel dient dazu, dass alle Pakete einer TCP-Verbindung, aber auch offensichtlich zusammengehörende UDP-Packets auf derselben Verbindung "kleben" bleiben, sonst kommt der Empfänger durcheinander. Nein, ich schreib dir das Script dazu nicht. Manpages zu iptables und iproute2 lesen.
Ach ja, brauchst du vielleicht nicht sofort, macht m.E.n. aber Sinn: Das "Fritzbox"-Lan könntest du auf ein eigenes Vlan am eth1 bridgen. Spätestens wenn du dir ein SIP-Telefon ins Netzwerk hängen willst, bist du froh wenn dieses die zusätzliche Masquerade umschiffen kann.
iptables Regeln händisch schreiben, du stehst auf Schmerzen, oder? https://shorewall.org/shorewall_setup_guide.htm Ich empfehle dir Shorewall, damit bekommst du das alles einfach konfiguriert. Und wenn du das nächste Mal einen Router möchtest kannst du direkt auf OpenWRT/pfSense setzen, die sind extra für diese Anwendung ausgelegt.
Rolf H. schrieb: > Beispiel... > > Client A schaut Netflix ===>>> Route über eth0 und die Fritzbox ins > Internet > > Client B surft auf google.de => Route über tun0 ODER tun1 Oh, also eine Verbindung zu einem „VPN Anbieter“ und nicht ein eigener VPN Server... die Salami schiebe ist mir entgangen... Policy Based Routing ist wird dein Freund aber das sagten ja schon andere hier...
gierig schrieb: > Oh, also eine Verbindung zu einem „VPN Anbieter“ und nicht ein eigener > VPN Server... die Salami schiebe ist mir entgangen... Wat wo wie? Nein, das sind meine eigenen VPN Server... Naja.. egal... Ein paar gute Antworten wären dabei... Ich werde dann mal weiter lesen und probieren... Es ist auch ziemlich egal ob ein vpn oder ein anderer inet Anschluss... Also wenn man das schon nicht versteht ... Es können auch 5 Internet Anschlüsse sein, 10 vpn oder what ever... Route XXX über Device YYY Egal WAS das Device ist... Nun gut... Danke euch
Εrnst B. schrieb: > Ach ja, brauchst du vielleicht nicht sofort, macht m.E.n. aber Sinn: > Das "Fritzbox"-Lan könntest du auf ein eigenes Vlan am eth1 bridgen. > Spätestens wenn du dir ein SIP-Telefon ins Netzwerk hängen willst, bist > du froh wenn dieses die zusätzliche Masquerade umschiffen kann. Hierfür läuft auf dem Server Asterisk. Die Fritzbox fungiert noch rein als Modem, kein IPTV, kein VoIP, kein DHCP, kein NAT, kein Routen, nichts. Alles, absolut alles muss vom Netzwerkserver übernommen werden. Asterisk ist der VoIP Server, mit IAXModem und Hylafax auch noch ein Faxserver. Bind9 läuft als DNS Server und ics-dhcp-server als DHCP Server. Minidlna stellt den MediaServer fürs LAN zur Verfügung. Der Server muss alles übernehmen, einfach alles, inkl Firewall und co für die Clients. Und dazu soll er eben entscheiden, welche Pakete welchen Weg wählen!!! Inet/vpn1/vpn2
Rolf H. schrieb: > Ich will nun das der Server entscheidet, was durch den VPN(s) geht und > was nicht.. Das wird schwierig. Da das Ziel sowohl für den lokalen Internetzugang als auch für die beiden VPNs wohl "das Internet" ist, kann der Router keine Entscheidung treffen, denn alle drei Ziele sind identisch. Er wird also die default route, also den lokalen Internetzugang verwenden. Es liegt also an dir, Kriterien zu schaffen, anhand derer das Routing separiert werden kann. Am einfachsten wären die Quelladressen. Also: PC1 geht über den lokalen Internetzugang rein, PC2 über VPN1 und PC3 über VPN2. Das ist aber vermutlich nicht das Gewünschte... Bleiben: Zieladresse, Zielport und Protokoll. Und es ist klar, dass viele zu benutzende "Dienste" nicht hinreichend darüber beschreibbar sind. Das reicht vielleicht, um die initiale Verbindung über den gewünschten Weg herzustellen, aber nicht, um den Dienst wirklich benutzen zu können. Ist aber alles so konfiguriert, dass der Dienst benutzt werden kann, ist es wiederum überaus wahrscheinlich, dass viele andere Dienste nicht mehr funktionieren, die über einen der anderen Wege in's Internet funktionieren sollen. Kurz: das kannst du vergessen! Mit deinen Kenntnissen sowieso.
c-hater schrieb: > dass viele zu benutzende "Dienste" nicht hinreichend darüber > beschreibbar sind. Beispiel: Das oben genannte Google hat via DNS alle paar Minuten eine andere IP-Adresse. Für solche Unterscheidung ist ein Proxy besser geeignet als L3 Routing, weil der den Servernamen sieht.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Beispiel: Das oben genannte Google hat via DNS alle paar Minuten eine > andere IP-Adresse. Für solche Unterscheidung ist ein Proxy besser > geeignet als L3 Routing, weil der den Servernamen sieht. Nun, das stimmt zwar, ist aber nicht was ich meinte. Zumindest ist es nur ein sehr einfacher Fall von dem, was ich meinte. Denn er ließe sich dadurch erschlagen, das man halt eine Liste der Zieladressen für diesen einen Dienst auf diesem einen Port mit diesem einen Protokoll aufsetzen (und ggf. ergänzen) könnte. Bei den Diensten, die der TO aber offensichtlich tatsächlich ansprechen will, ist das längst nicht so einfach. Das Problem ist hier, dass Teile davon bei den "Großen" gehostet sind, wo auch viele Teile vieler anderer Dienste liegen. Wenn man so ein System also soweit hat, das z.B. Netflix-USA perfekt funktioniert, wird Netflix-DE nicht mehr funktionieren. Und darüber hinaus viele andere Dienste, die ihrerseits ebenfalls was bei den "Großen" hosten. Denn all dieser Scheiß geht typisch davon aus, das der Client der Dienste über seine öffentliche IP zu einem bestimmten Zeitpunkt eindeutig identifzierbar ist. Sicherungen auf höherer Ebene (Session-Tokens usw.) werden erst benutzt, wenn die grundlegende Identifizierung passt. Wenn nicht, gelangt die Anfrage erst garnicht dorthin, wo das geprüft wird.
c-hater schrieb:
[...]
Vergessen:
Im Prinzip das klassische Multi-WAN-Problem auf L3, nur exportiert auf
die höheren Layer.
Rolf H. schrieb: > Der Server muss alles übernehmen, einfach alles, inkl Firewall und co > für die Clients. Du möchtest Virtualisierung. Und zwar aus einer ganzen Mengen guter Gründe!
c-hater schrieb: > Denn all dieser Scheiß geht typisch davon aus, das der Client der > Dienste über seine öffentliche IP zu einem bestimmten Zeitpunkt > eindeutig identifzierbar ist. Das ist doch aber bereits heute nicht mehr machbar. Siehe Carrier-Grade NAT mit IPv4 ohne dem Kunden eine IPv6 anzubieten.
Reinhard S. schrieb: > c-hater schrieb: >> Denn all dieser Scheiß geht typisch davon aus, das der Client der >> Dienste über seine öffentliche IP zu einem bestimmten Zeitpunkt >> eindeutig identifzierbar ist. > > Das ist doch aber bereits heute nicht mehr machbar. Siehe Carrier-Grade > NAT mit IPv4 ohne dem Kunden eine IPv6 anzubieten. Doch klar. Bei CGNAT ist der Client immer noch eindeutig identifizierbar, seine Absenderadresse aus Sicht des Dienstes ist ja konstant. Er ist halt nur halt nicht eineindeutig identifizierbar. Deswegen gibt's halt die Tokens weiter oben im Stack. Ist eben nur blöd, wenn schon die Prüfung auf Eindeutigkeit fehlschlägt und deswegen die potentiell erfolgversprechende Prüfung auf Eineindeutigkeit garnicht mehr vorgenommen wird...
Rolf H. schrieb: > Der Server hat zwei Karten, eth0 und eth1. > Eth0 = 10.10.0.1 (10.10.0.40 als Gateway) > Eth1 = 10.10.0.2 [...] > Das passt alles soweit. Nein, tut es nicht. Das ist Bullshit. Die beiden Netzwerkkarten brauchen separate Netze. Also z.B.: Eth0: 10.10.0.1/24 Eth1: 10.10.1.1/24
Rolf H. schrieb: > Wat wo wie? > > Nein, das sind meine eigenen VPN Server... Naja.. egal... Ein paar gute > Antworten wären dabei... Ich werde dann mal weiter lesen und > probieren... Rolf H. schrieb: > Und dazu soll er eben entscheiden, welche Pakete welchen Weg wählen!!! > Inet/vpn1/vpn2 Das beißt sich irgendwie alles und macht im Auge des fremden Betrachters alles so garkeine Sinn. Mal bitte deinen NetzPlan auf (ja ein paar kreise mit IP ud nsgrichen würde ja reichen) um zu skizzieren was du hast oder wie es sein soll Zusammen mit allen IP/Masken/Gateways und VON wo nach WO was soll und was das Ziel ist.
OMG ist das ein klassischer Unfug. Von Netzen keine Ahnung aber auf die Kacke hauen wollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.