Hardware/Router/EdgeRouter X-SFP: Unterschied zwischen den Versionen
K |
|||
Zeile 160: | Zeile 160: | ||
IPSec Performance : | IPSec Performance : | ||
MSS 1398 (max MTU, 1438) | |||
- - - - - - - - - - - - - - - - - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - - - - - - | ||
Zeile 165: | Zeile 167: | ||
[ 5] 0.00-300.02 sec 6.61 GBytes 189 Mbits/sec 13342 sender | [ 5] 0.00-300.02 sec 6.61 GBytes 189 Mbits/sec 13342 sender | ||
[ 5] 0.00-300.00 sec 6.60 GBytes 189 Mbits/sec receiver | [ 5] 0.00-300.00 sec 6.60 GBytes 189 Mbits/sec receiver | ||
=> ~17000 packets/sec | |||
MSS 536 (eq. MTU 576) | |||
- - - - - - - - - - - - - - - - - - - - - - - - - | |||
[ ID] Interval Transfer Bitrate Retr | |||
[ 5] 0.00-30.02 sec 160 MBytes 44.8 Mbits/sec 178 sender | |||
[ 5] 0.00-30.00 sec 157 MBytes 44.0 Mbits/sec receiver | |||
=> ~10000 packets/sec | |||
MSS 90 (eq. MTU 130) | |||
- - - - - - - - - - - - - - - - - - - - - - - - - | |||
[ ID] Interval Transfer Bitrate Retr | |||
[ 5] 0.00-30.02 sec 46.0 MBytes 12.9 Mbits/sec 2625 sender | |||
[ 5] 0.00-30.00 sec 43.1 MBytes 12.1 Mbits/sec receiver | |||
=> ~12200 packets/sec | |||
Testgerät Gegenseite : Fortigate 100D (via Innonet FTTH) | Testgerät Gegenseite : Fortigate 100D (via Innonet FTTH) |
Version vom 11. Januar 2022, 11:17 Uhr
Allgemeines zum Gerät
Die SFP-Version des EdgeRouter X bietet auf allen fünf Gigabit-Ethernet-Ports passive PoE. Das ermöglicht den Betrieb aktiver Antennen ohne zusätzliche Spannungsversorgung. Das mitgelieferte Netzteil mit Hohlstecker liefert 24V 2,5A, der Router benötigt etwa. 80mA. Entgegen der Produktbeschreibung kann er auch über passive PoE am ersten Ethernet-Port versorgt werden. Für Einsatz im Freien gibt es die EdgePoint R6 Variante.
Betrieb mit Original-Firmware
Hier eine Übersicht, des derzeit üblichen Setups. Mit diesem Gerät können ein/mehrere Antennen mittels am Router laufenden OLSR daemon (Wizard ermöglicht eine simple Installation und Verwaltung per GUI) im Bridgemodus laufend verwendet werden. Hierbei muss keine Custom Firmware aufgespielt werden, und es kann weiterhin das gewohnte Upgrade vom Hersteller aufgespielt werden.
Initiales Konfigurieren
- Schritte zur Konfiguration der Original-Firmware
- Aktuellstes Firmware Upgrade einspielen und danach auf Werkseinstellungen reseten (Hardware Reset mit Reset-Taster am Router! Bei Software Reset per CLI/GUI wird nur die Startup-Config zurück gesetzt. Ab EdgeOS 2.0.6 mit aktuellem Bootloader muss man den Reset Knopf rechtzeitig (nachdem eth4 nach schnellem und dann langsamen Blinken aus geht) loslassen, damit der Reset durchgeführt wird, ansonsten geht der Router in den TFTP flash Modus.)
- Bootloaderupdate prüfen. Nur auf ER-X / ER-X-SFP aktualisieren (NICHT EdgePoint EP-R6!!!) - könnte in einer aktuellen Firmware-Version bereits enthalten sein. Nach dem ersten Reboot mit der neuen Firmware-Version ggf. noch ein zweites Mal rebooten, um das Bootloader-Update wirksam zu machen. Der CLI-Command "show system boot-image" gibt Auskunft über den Zustand.
- Firmwareupdate auf aktuelle EdgeOS-Version
- Einfache Methode - (falls es Probleme gibt, bitte bei @pocki melden)
- Setup0xFF - Wizard installieren
- Notwendige Daten eintragen, Apply klicken & warten bis alles automatisch konfiguriert ist.
- ...oder manueller Methode - Schritte zur Konfiguration der Original-Firmware (bzw. Google Docs)
- Anlegen Bridge-Interface mit public 0xFF-IPv4-Adresse
- Anlegen Management-VLAN 1100 mit interner 10-er IP, NAT/masquerade (evtl. Portforwarding)
- Installation OLSRd-Wizard (v1 für IPV4, v2 für IPv6)
Links zu Wizards (OLSR,...)
- Setup0xFF - Oneclick-Erstkonfiguration/Installation
- OLSRd_V1
- OLSRd_V2
- LetsEncrypt, BMK-Webstatus
- Übersicht & weitere Wizards
Known Issues
- In der VLAN-Config scheinen die ID des Eintrags und die VLAN-ID übereinstimmen zu müssen. Außerdem scheint es einen Reboot für das Übernehmen der VLAN zu brauchen.
- Manchmal "verschwinden" Interfaces, ersichtlich an schwarzem Symbol oben in der Mitte auf der Weboberfläche, dies kann behoben werden, indem bei der Config das Interface manuell wieder hinzugefügt wird. VLANs und Bridges müssen ebenso wieder konfiguriert werden.
Betrieb mit OpenWrt
Der Router kann alternativ zur Original-(Ubiquiti-)-Firmware mit OpenWrt betrieben werden. Ein paar Unterschiede, die die Entscheidung erleichtern können:
- Die Original-FW hat einen Wizard für OLSR, das fehlt in OpenWrt bisher
- Man kann mit der Original-FW PoE ein- und ausschalten, das funktioniert in OpenWrt bisher nur über die Kommandozeile
- Mit OpenWrt sind sämliche OpenWrt-Pakete nutzbar
- OpenWrt ist im Gegensatz zur Original-FW open source, das heißt, die Community kann laufend Verbesserungen vornehmen (und tut das auch)
- Der EdgeRouter X(-SFP) wird offiziell von OpenWrt unterstützt, das heißt, es gibt laufend fertige Firmware zum Download
- 4-in-6 funktioniert momentan mit der Original-FW nicht brauchbar, das Kernel-Modul verpackt die IPv4-Pakete doppelt und fehlerhaft. Wer 4-in-6 nutzen möchte, ist mit OpenWrt besser beraten, oder verwendet zusätzlich OLSRv1 für IPv4 mit der Original-FW.
Initiales Flashen von OpenWrt
Damit es möglich ist bei Problemen mit der Firmware ein TFTP Recovery durchführen zu können, ist es Empfehlenswert EdgeOS 2.0.6 zu flashen und dann den Bootloader zu aktualisieren, siehe How to Update the Bootloader
Anschließend kann ganz normal z.B. folgende Firmware installiert werden, die klein genug ist, dass es mit EdgeOS funktioniert: OpenWrt 18.06 initramfs-factory
Unter Linux kann das automatisiert mit einem bash Skript erledigt werden: https://github.com/damadmai/edgemax_openwrt
Upgrade von OpenWrt (bei bereist installiertem OpenWrt)
Einfach über CLI oder Web-Interface (LuCI) das neue Sysupgrade-Image flashen.
Recovery
Der Weg zurück zu EdgeOS kann über TFTP Recovery gegangen werden, alternativ ist es auch möglich die serielle Konsole dafür zu verwenden.
Siehe https://an.undulating.space/post/181228-erx_install_openwrt_recover_edgeos/ bzw. https://community.ubnt.com/t5/EdgeMAX/ERX-ERX-SFP-System-Recovery/td-p/2056921 bzw. Manual TFTP Recovery
- Gummi-Stöpsel aus dem SFP-Port entfernen
- Die zwei Schräubchen auf der Rückseite rausdrehen, Gerät öffnen
- TFTP-Server mit OpenWrt-Image (initramfs) vorbereiten. Das Initramfs entweder selbst kompilieren oder mich (David) anschreiben. Werde ich in Zukunft irgendwo raufladen.
- Serial-Header identifizieren, das ist der mit den vier Pins, die nach oben wegstehen. Von der Vorderseite (mit den Ports) aus gezählt, sind das +3,3 V, TX, RX, GND.
- USB-TTY-Konverter verbinden (die +3,3 V werden nicht verbunden), gibt's auch im Automaten im MetaLab. Serielle Konsole öffnen.
- ER-X booten und beim Erscheinen des Boot-Menüs die entsprechende Option wählen und IP-Konfig eingeben
- Sobald OpenWrt gestartet ist, kann man sich via 192.168.1.1 (nicht über die IP, die oben eingegeben wurde!) einloggen. Anschliessend das Sysupgrade-Image wie gewohnt flashen (CLI oder Web-Interface (Luci)).
NAT performance benchmark der unterschiedlichen Betriebssyteme
https://an.undulating.space/post/180927-er_alternate_firmware_benchmarks/
Experimental /dev/crypto Support unter OpenWRT
OpenWrt SNAPSHOT r18523-8c501bf9fe + https://github.com/vschagen/mtk-eip93
Neue sha1.h und sha2.h Headers aus der Kernel Version 5.14+ nötig. Ein einfaches kopieren der Headerfiles ist aber ausreichend. Build Anleitung / Fertige Images folgen.
root@OpenWrt:~# openssl engine -t -c (dynamic) Dynamic engine loading support [ unavailable ] (devcrypto) /dev/crypto engine [DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-CTR, AES-192-CTR, AES-256-CTR, AES-128-ECB, AES-192-ECB, AES-256-ECB] [ available ]
root@OpenWrt:~# openssl engine -pre DUMP_INFO devcrypto (devcrypto) /dev/crypto engine Information about ciphers supported by the /dev/crypto engine: Cipher DES-CBC, NID=31, /dev/crypto info: id=1, driver=cbc(des-eip93) (hw accelerated) Cipher DES-EDE3-CBC, NID=44, /dev/crypto info: id=2, driver=cbc(des3_ede-eip93) (hw accelerated) Cipher BF-CBC, NID=91, /dev/crypto info: id=3, CIOCGSESSION (session open call) failed Cipher CAST5-CBC, NID=108, /dev/crypto info: id=4, CIOCGSESSION (session open call) failed Cipher AES-128-CBC, NID=419, /dev/crypto info: id=11, driver=cbc(aes-eip93) (hw accelerated) Cipher AES-192-CBC, NID=423, /dev/crypto info: id=11, driver=cbc(aes-eip93) (hw accelerated) Cipher AES-256-CBC, NID=427, /dev/crypto info: id=11, driver=cbc(aes-eip93) (hw accelerated) Cipher RC4, NID=5, /dev/crypto info: id=12, CIOCGSESSION (session open call) failed Cipher AES-128-CTR, NID=904, /dev/crypto info: id=21, driver=ctr(aes-eip93) (hw accelerated) Cipher AES-192-CTR, NID=905, /dev/crypto info: id=21, driver=ctr(aes-eip93) (hw accelerated) Cipher AES-256-CTR, NID=906, /dev/crypto info: id=21, driver=ctr(aes-eip93) (hw accelerated) Cipher AES-128-ECB, NID=418, /dev/crypto info: id=23, driver=ecb(aes-eip93) (hw accelerated) Cipher AES-192-ECB, NID=422, /dev/crypto info: id=23, driver=ecb(aes-eip93) (hw accelerated) Cipher AES-256-ECB, NID=426, /dev/crypto info: id=23, driver=ecb(aes-eip93) (hw accelerated) Information about digests supported by the /dev/crypto engine: Digest MD5, NID=4, /dev/crypto info: id=13, driver=md5-generic (software), CIOCCPHASH capable Digest SHA1, NID=64, /dev/crypto info: id=14, driver=sha1-generic (software), CIOCCPHASH capable Digest RIPEMD160, NID=117, /dev/crypto info: id=102, driver=unknown. CIOCGSESSION (session open) failed Digest SHA224, NID=675, /dev/crypto info: id=103, driver=sha224-generic (software), CIOCCPHASH capable Digest SHA256, NID=672, /dev/crypto info: id=104, driver=sha256-generic (software), CIOCCPHASH capable Digest SHA384, NID=673, /dev/crypto info: id=105, driver=sha384-generic (software), CIOCCPHASH capable Digest SHA512, NID=674, /dev/crypto info: id=106, driver=sha512-generic (software), CIOCCPHASH capable
Hier das Snippet für /etc/ssl/openssl.cnf :
[default] openssl_conf=openssl_def [openssl_def] # this is the main library configuration section engines=engine_section [engine_section] # this is the engine configuration section, where the engines are listed devcrypto=devcrypto_section [devcrypto_section] # this is the section where the devcrypto engine commands are used CIPHERS=ALL DIGESTS=NONE
Außerdem muss man die Files /etc/strongswan.d/charon/aes.conf & /etc/strongswan.d/charon/sha* entfernen um das OpenSSL Plugin zu forcen.
IPSec Performance :
MSS 1398 (max MTU, 1438)
- - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-300.02 sec 6.61 GBytes 189 Mbits/sec 13342 sender [ 5] 0.00-300.00 sec 6.60 GBytes 189 Mbits/sec receiver => ~17000 packets/sec
MSS 536 (eq. MTU 576)
- - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.02 sec 160 MBytes 44.8 Mbits/sec 178 sender [ 5] 0.00-30.00 sec 157 MBytes 44.0 Mbits/sec receiver => ~10000 packets/sec
MSS 90 (eq. MTU 130)
- - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.02 sec 46.0 MBytes 12.9 Mbits/sec 2625 sender [ 5] 0.00-30.00 sec 43.1 MBytes 12.1 Mbits/sec receiver => ~12200 packets/sec
Testgerät Gegenseite : Fortigate 100D (via Innonet FTTH)
IPSec Parameter :
Auth : Shared PSK
Phase 1 : AES128-SHA256 DH14
Phase 2 : AES128-SHA256 (ohne PFS)
Strongswan forced auf OpenSSL Plugin
Routed VPN via xfrm Interface
Vielleicht als Alternative zu OpenVPN brauchbar, und ab der Version 2.6/3 von OpenVPN auch für Data Channel Offload verwendbar.