7
Konfiguration Mikrotik-Router für IPsec-Richtfunkverbindung mit Ausfallsicherung
Hallo!
Wir haben zwei parallele Richtfunkstrecken mit 400 (primär) und 70 (Backup) Mbit/s, die als Bridge alle Daten (auch alle VLANs) vom einen zum anderen Ende übertragen sollen. Ich bekomme die beiden Strecken einzeln zum Laufen. Aber bei der Gesamtkonfiguration wird es schwierig.
Die Antennen sind jeweils an einen Mikrotik Cloud-Core-Router angeschlossen (10.77.75.21 und 10.77.75.22). Gewünscht ist:
Kann uns jemand einen Tipp geben, wie man unsere Probleme am besten angeht? Lässt sich das überhaupt so umsetzen, wie von uns gedacht? Bzw. macht es überhaupt Sinn, unser Konstrukt?
Kenne mich im Netzwerkbereich leider nicht so gut aus...
Wir haben zwei parallele Richtfunkstrecken mit 400 (primär) und 70 (Backup) Mbit/s, die als Bridge alle Daten (auch alle VLANs) vom einen zum anderen Ende übertragen sollen. Ich bekomme die beiden Strecken einzeln zum Laufen. Aber bei der Gesamtkonfiguration wird es schwierig.
Die Antennen sind jeweils an einen Mikrotik Cloud-Core-Router angeschlossen (10.77.75.21 und 10.77.75.22). Gewünscht ist:
- Datenverkehr über primäre RF-Verbindung verschlüsseln per IPsec. Wir haben an einen EoIP-Tunnel gedacht. Die Backupstrecke kann antennenseitig AES, da wird kein IPsec benötigt.
- Die Management-Oberflächen der primären RF-Strecke (10.77.75.23 und 10.77.75.24) sollen nicht unverschlüsselt über die RF-Bridge übertragen werden. Der Zugriff müsste also immer über den Router umgeleitet werden (laienhaft: Verbindung über die RJ45-Leitung zurück zum Router, dort mit in den IPsec-Tunnel reinpacken und dann erst über die RF-Strecke senden). Wir haben uns überlegt, das per VLAN zu lösen. Oder gibt es eine andere Idee?
- Bei der Backupverbindung besteht dieses Problem nicht, da wird ja der gesamte Datenverkehr antennenseitig AES-verschlüsselt, also auch die Übertragung der Managementoberflächen (10.77.75.5 und 10.77.75.6).
- Es soll eine automatische Umschaltung von primärer auf sekundärer Leitung geben, falls die primäre Leitung ausfällt. Was setzt man denn hier am besten ein? RSTP? OSPF? RIP? Habe alle drei Varianten noch nie selbst eingesetzt.
- Es sollen immer alle vier Antennen per Ping/Weboberfläche erreichbar sein, um die Verfügbarkeit prüfen zu können. Also auch wenn die Backupverbindung (Bridge) nicht aktiv ist, sollen die Antennen erreichbar sein. Folglich geht vermutlich die RSTP-Variante nicht, oder?
- Ideal wäre es, wenn der Router im Falle der Umschaltung auf die Bacjupverbindung eine Mail versenden könnte. Das setzten wir bei unseren Lancom-Routern in den Außenstellen ein. Aber die Mikrotik können das meines Wissens nicht. Da werden wir dann unser Netzwerkmonitoringtool so konfigurieren müssen, dass es die Auslastung der Routerports überwacht : Laufen plötzlich viele Daten über den Backup-Antennen-Port, soll das Netzwerkmonitoringtool eine Fehlermail erzeugen.
- (Optional könnte man auch, unabhängig vom VLAN, den Datenverkehr zum/vom Proxyserver 10.70.100.254 immer über die Backupleitung laufen lassen, um den Datenverkehr zu entzerren, aber das ist vermutlich zu kompliziert zum konfigurieren.)
- Bemerkung: Die Router und Antennen hängen aktuell im selben VLAN wie ein Teil der Clients in der Filiale. Sollte das geändert werden?
Kann uns jemand einen Tipp geben, wie man unsere Probleme am besten angeht? Lässt sich das überhaupt so umsetzen, wie von uns gedacht? Bzw. macht es überhaupt Sinn, unser Konstrukt?
Kenne mich im Netzwerkbereich leider nicht so gut aus...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 300848
Url: https://administrator.de/forum/konfiguration-mikrotik-router-fuer-ipsec-richtfunkverbindung-mit-ausfallsicherung-300848.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
7 Kommentare
Neuester Kommentar
Kenne mich im Netzwerkbereich leider nicht so gut aus...
Das merkt man leider an deinem Konzept, denn du machst fundamentale Designfehler.die als Bridge alle Daten (auch alle VLANs) vom einen zum anderen Ende übertragen sollen.
Das ist so technisch nicht möglich, denn so hast du, wie jeder Netzwerker weiss, einen Loop gebaut im Ethernet.Aber bei der Gesamtkonfiguration wird es schwierig.
Kein Wunder...siehe oben !Wenn du das so zusammenschaltest, hast du wie gesagt einen Loop, was so technisch nicht geht im Ethernet.
Mit Spanning Tree hast du eine Loop Protection, das bedeutet aber auch das dann ein Link tot ist. Wegen der schlechteren Cost ist das der 70 Mbit Link.
Aus Netzwerk Sicht ist das sehr übel, denn du bezahlst für einen Link den du aktiv nicht nutzen kannst.
Man könnte mit viel Aufwand und einem PVSTP Verfahren oder auch mit MSTP die VLANs pro Link verteilen. Das wäre viel Konfig Aufwand und müsste deine Switch Infrastruktur auch supporten.
So ist das also in einem reinen Layer 2 Design nicht umsetzbar.
Wenn dann müsstest du routen, das wäre in jedem Falle sinnvoller ! Dann nutzt du am besten OSPF, denn damit hast du eine Failover Zeit von max. 3 Sekunden bei automatischer Umschaltung.
So ein Routing Konzept erfordert aber eine Umstellung deines IP Adress Designs.
Auch im Hinblick auf die Performance ist ein Layer 2 Konstrukt eher kontraproduktiv, denn der gesamte Broad- und Multicast Traffic aller lokalen LANs auf beiden Seiten belastet den oder die Bridge Links.
Vielen Dank für deine Antwort und Entschuldigung für meine späte Antwort!
Es ist natürlich schon so, dass wir wissen, dass man keine Loops produzieren darf. Ganz so schlimm ist es dann doch nicht.
Daher auch die Frage nach RSTP.
Verstehe ich das richtig, dass bei RSTP die Switche jeweils einen Port komplett abschalten? Das heißt, im folgenden Beispiel wären auch nur die beiden aktiven Richtfunkantennen A1 und A2 per Ping erreichbar, die beiden passiven (Backup) nicht?
Aber als Übergangslösung bis zur Anpassung der anderen IP-Bereiche und Einführung des Routings würde die RSTP-Variante funktionieren, oder? Klar, einer der beiden Richtfunklinks wäre dann immer "tot". Aber die Variante wäre vorübergehend doch noch besser, als die bisher genutzte Variante des "manuellen Umsteckens". Da liegt die Umschaltzeit dann nämlich je nach meiner Anwesenheit zwischen 30 Minuten und 2 Tagen...
Es ist natürlich schon so, dass wir wissen, dass man keine Loops produzieren darf. Ganz so schlimm ist es dann doch nicht.
Daher auch die Frage nach RSTP.Verstehe ich das richtig, dass bei RSTP die Switche jeweils einen Port komplett abschalten? Das heißt, im folgenden Beispiel wären auch nur die beiden aktiven Richtfunkantennen A1 und A2 per Ping erreichbar, die beiden passiven (Backup) nicht?
Aber als Übergangslösung bis zur Anpassung der anderen IP-Bereiche und Einführung des Routings würde die RSTP-Variante funktionieren, oder? Klar, einer der beiden Richtfunklinks wäre dann immer "tot". Aber die Variante wäre vorübergehend doch noch besser, als die bisher genutzte Variante des "manuellen Umsteckens". Da liegt die Umschaltzeit dann nämlich je nach meiner Anwesenheit zwischen 30 Minuten und 2 Tagen...
Verstehe ich das richtig, dass bei RSTP die Switche jeweils einen Port komplett abschalten?
Ja, das verstehst du genau richtig !wären auch nur die beiden aktiven Richtfunkantennen A1 und A2 per Ping erreichbar,
Richtig !die beiden passiven (Backup) nicht?
Nein...oder Jein.Welcher Switchport geblockt wird ist abhängig von der RSTP Priority ! Wenn du das nicht definiert hast wie man es eigentlich soll gehen die Switches nach dem mit der niedrigsten Mac Adresse.
Angenommen Switch A hat die höhere Prio dann kommt es aufs Port Numbering an an Switch B welcher Port in Blocking Mode geht.
Es wird aber nur ein Port geblockt z.B. der Port an dem "RF B2" angeschlossen ist.
Damit wäre dann "RF B1" auch noch pingbar aber der Link an sich wäre tot bzw. inaktiv durch RSTP. Er würde erst aktiv werden wenn der andere Link ausfällt. Klassisches STP eben.
Aber als Übergangslösung bis zur Anpassung der anderen IP-Bereiche und Einführung des Routings würde die RSTP-Variante funktionieren, oder?
Ja, natürlich, das klappt fehlerlos.Aber die Variante wäre vorübergehend doch noch besser, als die bisher genutzte Variante des "manuellen Umsteckens".
Absolut richtig !
Danke aqui!
Nachdem die RSTP-Frage erklärt wäre, kommt Teil 2 unseres Problem:
Wie müssen die beiden Mikrotik-Router konfiguriert werden, damit sie den gesamten Datenverkehr zwischen ihnen verschlüsselt übertragen? Dies soll transparent (Layer 2) erfolgen, also als Bridge. (Bitte nicht nach dem Warum fragen..)
Gefunden habe ich http://www.manitonetworks.com/mikrotik/2016/3/9/eoip-tunnel:
bzw. auf der anderen Seite:
bzw. auf der anderen Seite:
=> Jetzt sollten wir eine transparente Layer-2-Bridge zwischen den Routern haben, die den gesamten Datenverkehr, der an den beiden LAN-Ports (ether2) anliegt, direkt durchleitet. Also auch unabhängig von VLANs etc.
Was mir nicht klar ist: Müssen wir jetzt noch eine Regel erstellen, dass an den beiden WAN-Ports jeglicher Datenverkehr außerhalb des Tunnels geblockt/verworfen wird? Wie sieht eine solche Regel aus? Oder geschieht das automatisch?
Nachdem die RSTP-Frage erklärt wäre, kommt Teil 2 unseres Problem:
Wie müssen die beiden Mikrotik-Router konfiguriert werden, damit sie den gesamten Datenverkehr zwischen ihnen verschlüsselt übertragen? Dies soll transparent (Layer 2) erfolgen, also als Bridge. (Bitte nicht nach dem Warum fragen..)
Gefunden habe ich http://www.manitonetworks.com/mikrotik/2016/3/9/eoip-tunnel:
- Ether1 (=WAN-Port): IP-Adresse vergeben: 1.1.1.2 bzw. 2.2.2.2 (beliebig)
- Ether2 (=LAN-Port): IP-Adresse vergeben: 10.77.75.21 bzw. 10.77.75.22 (damit Mikrotik-Router per IP erreichbar sind).
- EoIP-Tunnel auf beiden Routern anlegen:
/interface eoip add comment="Zur Außenstelle" name="Zur Aussenstelle EoIP" remote-address=2.2.2.2 tunnel-id=0 ipsec-secret=jfvowev8rg844bg0 /interface eoip add comment="Zur Zentrale" name="Zur Zentrale EoIP" remote-address=1.1.1.2 tunnel-id=0 ipsec-secret=jfvowev8rg844bg0 - Bridge jeweils vom Ethernetport 2 (=LAN-Port) zum EoIP-Tunnel einrichten
/interface bridge add name="EoIP Bridge"
/interface bridge port
add bridge="EoIP Bridge" interface=ether2
add bridge="EoIP Bridge" interface="Zur Aussenstelle EoIP" /interface bridge add name="EoIP Bridge"
/interface bridge port
add bridge="EoIP Bridge" interface=ether2
add bridge="EoIP Bridge" interface="Zur Zentrale EoIP" => Jetzt sollten wir eine transparente Layer-2-Bridge zwischen den Routern haben, die den gesamten Datenverkehr, der an den beiden LAN-Ports (ether2) anliegt, direkt durchleitet. Also auch unabhängig von VLANs etc.
Was mir nicht klar ist: Müssen wir jetzt noch eine Regel erstellen, dass an den beiden WAN-Ports jeglicher Datenverkehr außerhalb des Tunnels geblockt/verworfen wird? Wie sieht eine solche Regel aus? Oder geschieht das automatisch?
damit sie den gesamten Datenverkehr zwischen ihnen verschlüsselt übertragen?
Hier findest du eine Anleitung dazu:IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
EoIP ist nicht verschlüsselt. Das ist lediglich ein IP in IP Tunnel mit GRE.
Danke für die schnelle Antwort!
OK, mag sein. Aber der Datenverkehr ist dann über den im Hintergrund automatisch erzeugten GRE-Tunnel verschlüsselt. Sonst würde ja die ipsec-Einstellung beim eoip-Tunnel keinen Sinn machen, oder?
Was mir leider trotz der Wissensbeiträge und etwas Google-Suche nicht klar ist: Wie sage ich dem Mikrotik-Router, dass er an Ethernet1 wirklich nur den EoIP-Tunnel-Datenverkehr annehmen soll und sonst nichts? Gibt es da keine einfache Funktion? (darauf hoffe ich, finde aber leider nichts)
OK, mag sein. Aber der Datenverkehr ist dann über den im Hintergrund automatisch erzeugten GRE-Tunnel verschlüsselt. Sonst würde ja die ipsec-Einstellung beim eoip-Tunnel keinen Sinn machen, oder?
/interface eoip
add allow-fast-path=no clamp-tcp-mss=no ipsec-secret=\"blablalbla" !keepalive local-address=\10.200.255.1 mac-address=00:00:5E:FF:FF:F1 mtu=1504 name=eoip-tunnel1 \remote-address=10.100.255.2 tunnel-id=100 Was mir leider trotz der Wissensbeiträge und etwas Google-Suche nicht klar ist: Wie sage ich dem Mikrotik-Router, dass er an Ethernet1 wirklich nur den EoIP-Tunnel-Datenverkehr annehmen soll und sonst nichts? Gibt es da keine einfache Funktion? (darauf hoffe ich, finde aber leider nichts)
Aber der Datenverkehr ist dann über den im Hintergrund automatisch erzeugten GRE-Tunnel verschlüsselt.
Nein, natives GRE nutzt keinerlei Verschlüsselung.MT kombiniert hier 2 Verfahren. Sie machen GRE (EoIP) und verschlüsseln den Link mit IPsec. Sorum wird ein Schuh draus.
Den Traffic am Eth1 klassifiziert man mit einer ACL buw. in der Parametriesierung des Tunneltraffics.
