2022-12-23 Mobilfunk-Backupleitung per TELTONIKA TRB140 an LANCOM-Router

Rack

Neues Gerät
Simple Fallback-Lösung / NPTv6 / ALDI TALK Jahrespaket

Oft wird bei Backupverbindungen an LTE-Sticks gedacht. Wobei man je nach Routermodel auf die Kompatibilität achten muss. IMHO wesentlich besser sind LTE Modems/Gateways mit Ethernet-Anschluss. Sie verhalten sich dem Router gegenüber wie ein Kabel-Modem oder eine FB.

Kommt es nur sehr selten zu Ausfällen, bietet sich ein Tarif an der nicht genutzten Traffic überträgt bzw. nicht verfallen läßt. Nach dem ich verifiziert hatte, das der dahinterstehende Provider O2 Telefónica sowohl ⎇IPv6-fähig ist, als auch ⎇Funkabdeckung an meinem Standort bietet, habe ich mich in einem ersten Versuch für ein ALDI TALK Jahrespaket entschieden. Dieser Prepaid-Tarif wird gelegentlich von Adli angeboten. Der ungenutzte Traffic verfällt dort erst 12 Monate nach Aktivierungsdatum. Man muss zunächst eine Aldi-SIM-Karte erwerben und aktivieren und kann darauf dann das Jahrespaket buchen. Natürlich kann man beides gleichzeitig kaufen. Die Laufzeit des Jahrespakets beginnt erst mit der Aktivierung auf der Webseite. Die Beschreibungen, wie die SIM-Karte aktiviert werden muss, waren nicht immer ganz einheitlich. So entstand kurzzeitig der Eindruck, man müsste die SIM per Smartphone und Aldi-App aktivieren. Aber nein, einfach bei alditalk.de auf "SIM aktivieren". Man kann die SIM gleich im Modem verbauen. Den einzigen wirklichen Kritikpunkt gibt es bei der Verifizierung. Dort wird POSTIDENT unterstützt. Und obwohl man per QR-Code die nötigen Daten in die Postident-App übertragen kann, ist es darin dann nicht möglich sich per elektronischen Personalausweis zu verifizieren. Obwohl die App das natürlich könnte. (Die Option kann doch unmöglich mehr kosten als die Aufwandsentschädigungen der anderen Verfahren?!)

Ich habe mich für ein ⎇TELTONIKA TRB140 LTE-Gateway entschieden. (Hauptgrund war die gute öffentliche Dokumentation im Vergleich zur Konkurrenz.) Es hat neben einem Ethernet- auch einen USB-Anschluss, welcher als Netzwerkkarte erkannt wird. Damit ist es beinahe unmöglich, z.B. nach Aktivierung eines Bridge-Mode zwischen Ethernet und LTE, sich auszusperren.

TELTONIKA TRB140 LTE-Gateway Gehäuse und Mainboard mit SIM-Karte

Es folgt ein Screenshot-Dump der TRB140-Konfiguration:

Wizard:
TRB140 Setup Wizard

Firmwareupdaten:
TRB140 Firmwareupdate

Netzwerkkonfiguration für eine optimale Zusammenarbeit mit einem Router:
TRB140 Interface Configuration 0

NAT, da die Bridge-Modi nicht richtig funktioniert haben. Traffic hörte nach nur wenigen Pakten auf zu fließen. Da der Tarif sowieso keine öffentliche IPv4 bietet war es mir die Debugarbeit nicht wert. (Bezieht sich nur auf IPv4.)
TRB140 Interface Configuration 1

"builtin IPv6-management" soll laut Doku für Präfix-Delegation sorgen. Der LANCOM-Router erhält per Router-Advertisement mehrere /64-Netze. Egal wie dieser Hebel steht. Meiner bisherigen Erfahrung nach ist es aber zuverlässiger wenn die Option auf beiden Interfaces aus ist. ¯\_(ツ)_/¯
TRB140 Interface Configuration 2

TRB140 Interface Configuration 3

TRB140 Interface Configuration 4

TRB140 Interface Configuration 5

TRB140 Interface Configuration 6

TRB140 Interface Configuration 7

TRB140 Interface Configuration 8

TRB140 Interface Configuration 9

TRB140 Interface Configuration 10

Auf dem TELTONIKA TRB140 kommt OpenWRT zum Einsatz. Aus unbekannten Gründen setzt TELTONIKA das ULA-Prefix fdfd:f171:667b::/48. ULAs dürfen nicht geroutet werden. Dennoch passiert es gelegentlich das genau das versucht wird. Was natürlich scheitert.
tracert
1. LANCOM-Router: Hat eine ULA. Was in diesem Fall wegen NPTv6 ok ist. Siehe weiter unten.
2. TRB140 LTE-Gateway: Hat eine ULA und kommt von dort nicht weiter zum ISP.
3. TRB140 LTE-Gateway: Nach einer Neuverbindung hat es eine richtige Adresse und der Datenverkehr fliest.
Das Verhalten war in meinen Augen zufällig. Häufig funktioniert es direkt nach einem Neustart richtig, später aber nicht mehr. Das ULA-Präfix kann per Weboberfläche nicht direkt abgeschaltet werden. Daher dieser Workaround:
Shell starten

vi /etc/config/network config globals 'globals' option ula_prefix 'fdfd:f171:667b::/48'
Anschließend das Gerät neu starten. (Ungetestet, aber ich gehe mal davon aus das die /etc/config/network neu geschrieben wird, sobald man per Weboberfläche ein Netzwerk-Interface bearbeitet und damit den Workaround wieder entfernt.)
Nach dieser Änderung ist IPv6 stabil.

Optionale SMS-Thematik:
TRB140 Interface Configuration 11

TRB140 Interface Configuration 12
Unterstützt nur STARTTLS nicht SMTPS!

TRB140 Interface Configuration 13

TRB140 Interface Configuration 14


Es folgt ein Screenshot-Dump der LANCOM-Router-Konfiguration:

(Das Ganze geht natürlich auch per Webinterface, aber mir gefällt LANconfig aufgrund der automatischen Config-Sicherungen besser.)

Setup-Assistent:
LANCOM Configuration

LANCOM Configuration 1

LANCOM Configuration 2

LANCOM Configuration 3

LANCOM Configuration 4

LANCOM Configuration 5

LANCOM Configuration 6

LANCOM Configuration 7

LANCOM Configuration 8

LANCOM Configuration 9

LANCOM Configuration 10

Damit ist ein zweiter Internet-Zugang eingerichtet, der aber noch für nichts verwendet wird. Weswegen er z.B. im LANmonitor nicht bei den aktiven WAN-Verbindungen zusehen ist.
Im folgenden wird der zweite Internet-Zugang als Backup-Leitung konfiguriert und es folgen Detailverbesserungen bezüglich IPv6.

LANCOM Configuration 11

PD-Quelle zwingend auf Router-Advertisement stellen, da TRB140 keine Präfix-Delegation per DHCPv6 macht.
LANCOM Configuration 12

Der Setup-Assistent hat die Präfix-Quelle für das INTRANET auf die Backup-Leitung gesetzt. Das sollte man schnell zurück auf die Hauptleitung ändern.
LANCOM Configuration 13
(In diesem Beispiel also INET_ALDI zurück auf INTERNET ändern. Aufgabe der Backup-Tabelle ist es, INTERNET nur im Fehlerfall auf INET_ALDI umzustellen.)

LANCOM Configuration 14

Optional:
LANCOM Configuration 15

Zieht man jetzt den Stecker der Hauptleitung, baut sich nach fünf Sekunden die Backup-Verbindung auf. Es werden zwar zwangsläufig alle laufenden Verbindungen unterbrochen, aber nach einer Neuverbindung geht es weiter. Wird die Hauptleitung wieder verfügbar, geht alles zurück.
LANmonitor

IPv4 ist hier schneller als IPv6, da dort erst das neue Präfix propagiert werden muss. Clients scheinen auch nicht immer gleich umzuschalten, obwohl sie die neuen Daten schon haben. Vermutlich weil die alte Route nicht zurück gezogen werden kann und erst Timeouts erreicht werden müssen. Da ist jedes OS etwas anders. Es empfiehlt sich daher auf ⎇ULAs und ⎇NPTv6 umzustellen, damit der Präfix-Wechsel entfällt. (Zugegeben, auch da muss gewartet werden bis Firewall-States abgelaufen sind.)

NPTv6

IPv6-to-IPv6 Network Prefix Translation erlaubt es z.B. im LAN ein festes Netz bzw. Präfix wie fd00::/64 (mit 192.168 vergleichbar) zu haben, welches dann Richtung Internet in das ISP-Präfix übertragen wird. Entsprechend bleibt das private interne ULA-Präfix immer gleich, selbst wenn sich das ISP-Präfix ändert. Sei es durch eine Zwangstrennung, Modemneustart oder ein Wechsel auf eine Backupleitung.

Von LANCOM gibt es dazu diesen ⎇Eintrag im LCOS Handbuch und diesen ⎇Knowledge Base Artikel. Es sind im Grunde nur diese Schritte:
LANCOM Configuration 16

LANCOM Configuration 17

LANCOM Configuration 18


Siehe auch:
⍈Stolperfalle ULA-Präfix unter Windows
⍈Stolperfalle bei NPTv6

⍈Homepage

#