Auf das an der UDM-PRO-SE angeschlossenes Modem zugreifen.
Warum wollen wir das?
Das Modem hat nur ein Netzwerk-Interface (wie z.B Vigor 130), es stehen keine normalen LAN-Ports mehr zu Verfügung oder sollen nicht verschwendet werden.
Dennoch wäre ein gelegentlicher Zugriff erwünscht, um sich z.B die (V)DSL-Verbidungsdatenanzuschauen oder Updates durchzuführen.
Und wie geht das genau?
Voraussetzungen:
- Grundkenntnisse auf der Linux Shell
- Modem Konfiguration
- einen (privaten) IP-Bereich der NIRGENDWO intern benutzt wird.
Das Beispiel hier benutzt: 10.99.99.0/28
10.99.99.1/28 -> IP des Modem
10.99.99.2/28 -> IP des der UDM - UDM-PRO-SE getestet mit der 2.5.11, es spricht aber nichts dagegen, dass
es auch auf den andere UMD oder DR funktioniert. Da müssen aber ggf.
Pfade, Netzwerkschnittellen UND Start-Scripte angepasst werden.
Step1: Modem Konfiguration
Am Beispiel eines DrayTek Vigor 130, IP Adresse und Maske setzen und fertig.
Step2:
auf der UDM-PRO-DE ist das "/data“ Verzeichnis der Ort, der soweit bekannt, nicht von Updates überschrieben wird (auf der UDM-PRO ist zur Zeit /mnt/data/)
sofern noch nicht geschehen hier ein „myScripts“ Verzeichnis anlegen (mkdir /data/myScripts) wo dann alles reinkommt.
Dort dann eine accessModem.sh erstellen mit folgenden Inhalt.
#!/bin/bash
####
## accessModem.sh v1.3 for UDM-PRO-SE
##
## Add a subinterface to the WAN Port of the UDM, also add (p)NAT
## rule to access Modem without need for further Modem Config.
##
## Setup:
## copy to /data/myScripts/accessModem.sh (persistant path may differe on NON PRO-SE)
## change Variable INTERFACE, LOCALE_IP, REMOTE_IP or SCRIPTPATH if needed.
##
## INTERFACE: (for UDM-PRO-SE other may difference)
## eth7 -> PORT 8 (special WAN port on the 8 Port switch on the SE)
## eth8 -> PORT 9 (normal WAN Port)
## eth9 -> Port10 (upper SFP Port)
## eth10 -> Port11 (lower SFP Port)
##
## LOCALE_IP: the IP and MASK for the interface on the UDM
## REMOTE_IP: the IP of the Modem
## (reminder, not use any ip network range that use on LAN side)
##
## Use:
## /data/myScripts/acceshssModem.sh start -> Add the Interface and iptable rule
## /data/myScripts/acceshssModem.sh stop -> Remove Interface and iptable rule
##
## Changelog:
## V1.0 -> 2022.10.02 --> Inital
## V1.1 -> 2022.10.17 change iptables static path to "wheris" Variable to cover FW2.x & 3.x
## V1.2 -> 2022.10.20 change to macvlan interface as additional ip get removed by UNFI
## after some time
## V1.3 -> 2023.09.20 change harcoded Script path for logfile to Variable
## replace "whereis iptables..“ to a which call to make it more easy
## credits for both to noexpand (thanks for point it to me)
##
## 2023, by Gierig, free to use
INTERFACE="eth8"
LOCALE_IP="10.99.99.2/28"
REMOTE_IP="10.99.99.1"
SCRIPTPATH="/data/myScripts"
SCRIPTLOG="log.txt"
#### typical no change need below this line ###########
DATE=$(date +%F_%H:%M:%S)
IPT=$(which iptables)
case "$1" in
start)
/sbin/ip link add name ${INTERFACE}.modem link ${INTERFACE} type macvlan
/sbin/ip addr add ${LOCALE_IP} dev ${INTERFACE}.modem
/sbin/ip link set ${INTERFACE}.modem up
$IPT -t nat -I POSTROUTING 1 -o ${INTERFACE}.modem -d ${REMOTE_IP} -j MASQUERADE
echo "$DATE -> accessModem -> Start" >> ${SCRIPTPATH}/${SCRIPTLOG}
;;
stop)
/sbin/ip link set ${INTERFACE}.modem down
/sbin/ip addr del ${LOCALE_IP} dev ${INTERFACE}.modem
/sbin/ip link delete dev ${INTERFACE}.modem
$IPT -t nat -D POSTROUTING -o ${INTERFACE}.modem -d ${REMOTE_IP} -j MASQUERADE
echo "$DATE -> accessModem -> Stop" >> ${SCRIPTPATH}/${SCRIPTLOG}
;;
*)
echo "Usage: $0 {start|stop}" >&2
exit 1
;;
esac
exit 0Angepasst werden muss ggf.:
INTERFACE=„eth8“ -> eth8 ist Port 9 auf der UDM-PRO-SE, eth9 währe der obere SFP Port 10, eth10 der untere SFP Port 11
LOCALE_IP="10.99.99.2/28“ -> Die Ip und Maske die die UDM bekommt
REMOTE_IP=„10.99.99.1“ -> die IP des Modems
Nach dem da Script ausführbar ist (chmod +x accessModem.sh) kann es mit /data/myScripts/accessModem.sh start gestartet werden
oder mit „stop" die einstellungen auch wieder entfernt werden.
Mehr ist nicht nötig um dann über die 10.99.99.1 auf das Modem zuzugreifen.
STEP3: AUTO START
Wer nach einem Boot das script nicht Manuel starten möchte fügt noch eine Start Unit hinzu.
(Hier sind dann auch die Meisten unterschiede zu normalen UDM da läuft das booten von Skripten anders ab)
Dazu im gleichen "/data/myScripts/„ Verzeichnis eine „accessModem.service" anlegen:
###
## accessModem.service
## a Start Unit to handel external Modem Access
## 2022, by Gierig, free to use
[Unit]
Description=Modem External Access
After=network.target
[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/data/myScripts/accessModem.sh start
ExecStop=/data/myScripts/accessModem.sh stop
[Install]
WantedBy=multi-user.targetmit ln -s /data/myScripts/accessModem.service /etc/systemd/system/accessModem.service einen link der datei in system config Verzeichnis anlegen
und mit systemctl enable accessModem die start unit dem System bekannt machen.
EXTARS:
Mit Routen die auf die UDM gehen können interne oder auch externe Ziele erreicht werden. Hier eine route zu meinen 192.168.1.0/24 netz
in dem z.B ein Syslog stehen könnte (man erspart sich irgendwelche Portforwarding regeln) oder die Zweite IP is ein Zeitserver der extern liegt
(offizieller ptb.de Zeitserver) die IP dann auch als NTP quelle im router eintragen und schon hat dieser auch die richtige Uhrzeit...
Anmerkungen:
für die USG gibt es HIER eine schöne Beschreibung.
Firewall Regeln beachten, auf Gruppen / Vlan / Anschluss basierenden Regeln greifen wahrscheinlich nicht
da das "interface" an "Unifi" vorbei eingerichtet ist.
das (p)SNAT mit iptables könnte man sich sparen, die zu Modems degradierten Router (Vigor/Fritz) lassen aber selten eine default route auf dem LAN
Interface zu. Manuelle Routen für die nötigen VLAN währen aber auch möglich, ist aber extra Pflege auf dem Modem (siehe extras)
Mit dem NAT und ohne Routen hat das Modem aber auch nur max zugriff auf die UDM und kann die Geräte dahinter nicht direkt erreichen
Disclaimer:
Alle Anleitungen/Tutorials sind nach bestem Wissen und Gewissen verfasst, gehen immer von den definierten Software/Firmware-Versionen aus und sind auf das englische GUI ausgelegt.
Es gibt keine Garantie auf Erfolg. Im Falle eines Misserfolges hilft aber die Community hier sicherlich weiter.
Keiner der Autoren oder der Betreiber des Forums ist für die aus der Nutzung resultierenden Probleme/Herausforderungen verantwortlich.
Jegliche hier beschriebenen Schritte erfolgen ausnahmslos in eigener Verantwortung des Durchführenden.
Eltern haften für ihre Kinder.
Kommentare 33
Neu erstellte Kommentare unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Neu erstellte Kommentare unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Joscha230381
Guten Tag,
Habe den Zugriff auf das Modem mit einem "UCG-Ultra" hinbekommen.
Nun habe ich mir ein "UCG-Max" besorgt und möchte es hinbekommen, das Modem zu erreichen.
myScripts Ordner ist angelegt und die beiden Dateien, accessModem.sh und accessModem.service befinden sich im Ordner.
Das Ausführungsrecht wurde auch gesetzt.
Bekomme leider folgende Fehlermeldung nach folgendem Befehl:
Befehl: /data/myScripts/accessModem.sh start
Fehlermeldung:
"-bash: /data/myScripts/accessModem.sh: /bin/bash^M: bad interpreter: No such file or directory"
Hat eventuell jemand eine Idee, wie man es zum laufen bekommt, oder wo der Fehler liegt?
Vielen Dank
Joscha230381
Hat sich erledigt!
Es lag am verkehrten Format Zeilenende der accessModem.sh.
Diese stand auf Windows und nicht auf UNIX, wie es sich gehört.
PsychoDad
Danke für die Anleitung, leider klappts bei mir nicht um damit auf ein fs.com SFP+ zuzugreifen, welches im Port 10 steckt. Bekomme die folgende Fehlermeldung beim ausführen:
RTNETLINK answers: Device or resource busy
Cannot find device "eth10.modem"
Cannot find device "eth10.modem"
Irgendeine Idee? Danke
gierig
Nun....Erstmal klären was du mit Port 10 meinst. Gehst du von der Beschriftung aus
dann ist das aber eth9 in the Software (wir It Zottel fangen ja bei 0 an zu zählen, egal was vorne raufgedruckt ist.) Steht so auch im Script Drinnen.
Wenn nicht und das Ding steck steckt in eth10 also Port 11 (der untere)
Ja dann ggf nach nem Boot nochmal Probieren sonst müsste man da mal stück für stück
sich ranhalten wo es genau klemmt...
das zu sind aber auch dinge hilfreich wie FW und welche Kiste überhaupt...
PsychoDad
Da hast du Recht, dass war es schon. Ich habe Port 10 mit eth10 gleichgesetzt OBWOHL ich das im Script gelesen habe. Mea culpa und sorry for the noise. DANKE
gierig
hehe... kein Thema...manchmal muss man mit der Nase drauf gestossen werden..
PsychoDad
So ist es. Auf mein Modul komme ich trotzdem (noch) nicht, dass liegt aber nicht an deinem Script, sondern daran das noch kein Licht ankommt. Ich habe irgendwo gelesen, dass die fs.com ONU Module erst ansprechbar sind, wenn Licht ankommt.
gierig
Halte ich für ein Gerücht aber nun gut ich habe hier auch keins ums widerlegen zu können
mpicco
Hallo,
wie müsste das Skript erweitert werden wenn 2 Internet Anbieter angeschlossen sind? z.B. an Lan Port 8. Sprich 2 Modems im Bridge Mode.
LG
Franz
gierig
Script Kopieren unter anderen Namen abspeichern (sowas wie accessModem2.sh)
Editieren mit anderen IP / Port
Startcript Kopieren (sowas wie accessModem2.service) und auch einflegen.
Oder halt alles Doppelt in eine Datei reinschieben, variabel anpassen oder hardcofieren.
mpicco
Danke... habs schon hingebracht...
Maurer42
Hallo,
ich habe heute von meiner alten USG auf die UXG migriert und dabei leider erst festgestellt dass die gateway.config.json Einstellungen gar nicht mehr gehen.
Jetzt bin ich hier drauf gestoßen auf der Suche nach einer Lösung für das Vigor 165-Problem. Leider scheint es auf der UXG-Lite nicht zu funktionieren:
Das passiert direkt beim 1. command, also bei
Hat vielleicht jemand eine Idee wie man das auf das UXG-Lite adaptieren könnte?
gierig
RTNETLINK answers: Operation not supported
Nachtigall ich hör dir Trapsen. Teilweise werden die Kernel nicht mehr mit
der MACVLAN Funktion ausgeliefert (danke für nichts UI)
mach mal bitte ein
zcat /proc/config.gz | grep -i MACVLANwas kommt da ?
erwartet wird ein
CONFIG_MACVLAN=y
kommt ein
CONFIG_MACVLAN=m
ist die Welt noch zu retten und du benötigst im script ggf nur ein lsmod macvlan
Ohne oder mit „n“ ist doof...
Hier is ne Lösugn, allerdings aktuell nicht für deine Version.
Du müsstest dir also selber einen Kernel Backen, bzw. das Modul
auf auf einen anderen PC
https://github.com/whi-tw/macvlan-unifios/tree/main
Maurer42
...irgendwie hatte ich gedacht nach dem Wechsel von der USG auf UXG-Lite ist alles besser als vorher. Aber irgendwie gehen echt viele Dinge nicht mehr die ich eigentlich brauche. Ziemlich blöd.
Das UXG-Lite kommt übrigens mir der Version
gierig
aber halt mit einem leicht andern Kernel bei dem MACVLAN nicht inkludiert ist.
Die UDM-SE wird bisher noch mit ausgeliefert (bin auf Beta 3.2.x)
So adhoc fällt mit auch nichts ein. Angefangen hatte ich einfach mit ner zweiten IP
die wird aber auch das UNIFI System recht schnell wieder weg konfiguriert.
Maurer42
Also ich benutze das eigentlich nur, um per telnet die aktuellen Daten vom Modem abzuholen und diese in eine Influxdb zu schreiben.
Ich habe jetzt Deine Lösung auf einen Raspberry Pi der eh läuft angewendet:
damit komme ich dann vom Pi per telnet aufs Modem drauf (bzw. mit dem Python Script das die Daten holt und in die Datenbank schreibt). Und wenn ich aufs Webinterface muss kann ich sogar einen ssh tunnel aufmachen (ssh -L 8080:192.168.1.1:80 pi@pi-ipaddrr) und dann per localhost drauf. Ich glaube das ist für mich die deutlich einfacherere Lösung als jetzt irgendwelche Kernel-Module zu besorgen.
Danke Dir trotzdem für die Mühen (und im Endeffekt für die Lösung). Vielleicht hilft es ja auch mal wem anders. Eigentlich braucht man ja gar nicht ständig Zugriff auf das Webinterface von Modem. Ist bei mir ja auch eher ein Sonderfall weil ich den Line Status loggen möchte.
Immerhin eins von 4 Problemen das ich mit der USG -> UXG-Lite-Migration habe gelöst...
gierig
V1.3 update.
Logging war vom Pfad her Hardcodiert und ist in eine variable Gewandert.
der Wheris Aufruf um iptables zu finde wurde mit einem „which“ vereinfacht.
Danke an noexpand für die hinweise...
Janner2000
Moin...
Ich habe alles wie oben beschrieben installiert.
Wenn ich das Script MANUELL starte oder stoppe macht es das was es soll.
So nun habe ich es auch als Dienst wie oben beschrieben gemacht, übersteht auch den Neustart aber es wird nicht ausgeführt. Siehe unten die Ausgabe von "systemctl status accessModem" nach Neustart.
Es handelt sich um eine UDM Pro (keine SE) Firmware: 3.1.15, Network: 7.4.162 ergo die neuste Stable
Was mache ich Falsch?????
root@UDMPRO:~# systemctl status accessModem
● accessModem.service - Modem External Access
Loaded: loaded (/data/myScripts/accessModem.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2023-08-24 20:06:25 CEST; 20h ago
Main PID: 2763 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4725)
Memory: 0B
CPU: 0
CGroup: /system.slice/accessModem.service
Aug 24 20:06:25 UDMPRO systemd[1]: Started Modem External Access.
Aug 24 20:06:25 UDMPRO accessModem.sh[2783]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
gierig
das "Another app is currently holding the xtables lock“
klingt so als wenn da grade just zu dieser Zeit noch ein anderes Script an den Regeln rummacht.
Halt das Unifi System selber.
Ich würde mit einem "sleep 5" oder "sleep 10" anfangen ne Pause einzubauen.
ALSO:
"ExecStartPre=/bin/sleep 30“ vor der "ExecStart=/data/myScripts/accessModem.sh start„
Zeile in der Start UInit einfügen. evt. noch ein "TimeoutStartSec=120“
um das timeout hochzustehen (wobei das eigentlich mit 90 Sekunden lang genug sein sollte)
Janner2000
Joo ich bin HAPPY, alles so richtig wie du mir beschrieben hast... Herzliches Dankeschön für die Arbeit sowie erstklassischem Support.
Anbei meine geänderte accessModem.service:
###
## accessModem.service
## a Start Unit to handel external Modem Access
## 2022, by Gierig, free to use
[Unit]
Description=Modem External Access
TimeoutStartSec=120
After=network.target
[Service]
Type=simple
RemainAfterExit=yes
ExecStartPre=/bin/sleep 30
ExecStart=/data/myScripts/accessModem.sh start
ExecStop=/data/myScripts/accessModem.sh stop
[Install]
WantedBy=multi-user.target
thunderhawk
Funktioniert das auch auf einer UXG-Max?
gierig
Das steht und fällt mit der Verfügbarkeit des MACVLAn Kernel Moduls
zcat /proc/config.gz | grep -I MACVLAN
sollte was liefert wie
CONFIG_MACVLAN=y
dann gehst, wenn das auf N steht oder keine Ausgabe dann wird es nicht gehen.
gierig
Für das GlasfaserModem2 der Telekom funktioniert das natürlich auch.
Das modem hat nur feste einstellungen und damit andere IP:
LOCALE_IP="192.168.100.2/24"
REMOTE_IP=„192.168.100.1"
Damit gehts dann direkt
pyama
Vielen Dank!
Es funktioniert auch mit dem LuLeey SFP Modul, welches viele nutzen. Hier können die Netzwerkeinstellungen angepasst werden.
Es funktioniert auch mit dem Zyxel SFP Modul, welches im Umlauf ist für Anschlüsse der DTAG ("Digitalisierungsbox"). Hier können die Netzwerkeinstellungen aber nicht angepasst werden:
LOCALE_IP="10.10.1.2/28"
REMOTE_IP="10.10.1.1"
gierig
Prinzipiell funktioniert das mit ALLEM
völlig egal ob drytek, Lulley, zyxsel, AVM, adere kram von anderen Herstellern
Airfox90
Hi und danke für das Script.
Ich bin mir sicher du hast es getestet und es funktioniert bei dir, aber ich hatte auf meiner UDMpro ein kleines Problem:
die TCP Pakete aus meinem lokalen Netzwerk, die über das .modem subinterface raus zum DSL Modem gehen wurden nicht ge-nat-ed (also kein src rewrite).
Deshalb funktionierte es auch nicht, da das DSL Modem ohne eingetragene route keine Antwort an eine IP aus meinem lokalen Netzwerk senden kann.
Allerdings erstellt das script ja die MASQUERADE rule für das Hauptinterface und nicht für das subinterface. Das routing der pakete in der UDM erfolgt aber über das subinterface.
Also habe ich dann die MASQUERADE rule auch auf das subinterface gelegt und schon hat's funktioniert
$IPT -t nat -I POSTROUTING 1 -o ${INTERFACE}.modem -d ${REMOTE_IP} -j MASQUERADE
gierig
100% Korrekt. Ich habe es oben Korrigiert.
Bei mit auf der UDM wars schon richtig...
Habe ich wohl vergessen anzupassen im Wiki bei der Umstellung von
zweite IP auf eignes Substanz interface.
Danke für den Hinweis !!!
gierig
So, neues Script ist da.
Statt ne IP einfach auf das WAN interface zu legen wird ein neues Interface mit eigner Mac
angelegt und da die IP draufgelegt. Die wird bisher nicht von UNIFI system überschrieben..
gierig
Ahh das UNFI System scheint von WAN Interface die IP zu entfernen irgendwann nachts.
Möglich das es mit der FW nun anders ist.
Probieren wird es mit einem SUB Interface mit der Hoffnung das das nicht gelöscht wird,.
/sbin/ip addr add ${LOCALE_IP} dev ${INTERFACE} label ${INTERFACE}:modem
wenn das klappt werde ich das Script Oben anpassen...
gierig
Mit der neuen 3.x FW Version hat sich der ORT für IPTABLES geändert.
Habe oben das script angepasst das nun den richtigen Pfad „sucht“ und dann verwendet.
Damit sollte das dann auf 2.x und 3.x laufen.
noexpand
Coole Sache, da wäre ich ja im Leben nicht drauf gekommen!
Leider kommt es für mich zu spät, bin auf Glasfaser umgestiegen.
Obwohl, da gibts ja auch diesen Medienkonverter. Ich werd mal bei Gelegenheit ausprobieren, ob das damit auch geht ...
gierig
sofern der ne IP hat um auf ihn zuzugreifen um irgendwas einzustellen.. JA
Das Telekom GlasfaserModen hat z.B die 192.168.100.1 als feste IP
das GLAS SFP glaube ich ne 10er...Benötigt man aber nur wenn noch die
ONT Kennung bei alten Anschlüssen gesetzt werden muss.
Wenn dein Glas GPON wird dein „MedienKonverter“ auch eher ein „Modem“ sein
wegen der Verschlüsselung) und ne Einstellmöglichkeit haben.
Wenn APON dann wahrscheinlich nicht unwirklich nur ein „dummer“ Konverter.
noexpand
Ganz genau!
Als IPs musste ich nur 192.168.100.1 und 192.168.100.2 eintragen dann funktioniert das ganz ausgezeichnet