05.05.2023, aktualisiert am 06.05.2023

3395

RasPi als Gateway (WAN per USB Tethering)

Hallo!

Ich habe eine FritzBox 6490 (also für Kabel). Derzeit liegt eine Netzstörung im downstream Bereich vor, weshalb ich per Handy und USB Tethering direkt an der Fritzbox das Kompensieren wollte.
Leider dreht mir die FritzBox dann das Kabel ganz ab, d.h. ich habe keine Telefonie mehr. Daher ist das keine Lösung.
Einfach ein WLAN vom Handy aus aufspannen und damit dann surfen geht nicht, weil ich einige Server im LAN habe, die auch noch erreichbar sein sollen.

Nun ist meine Idee:
Ich nutze einen RasPi, der im LAN hängt, als Gateway. Wenn ich das richtig verstanden habe, erzeugt unter Linux ein Handy mit aktiviertem USB-Tethering dann eine neue Netzwerkkarte, d.h. der RasPi sollte dann ja 2 Netzwerk-Interfaces haben und könnte somit als Router (bzw. Gateway) arbeiten und jeglichen nicht-lokalen Traffic ins Internet weiter reichen.
Den DHCP Dienst verrichtet nicht die FritzBox, sondern eine Synology NAS.
Den DNS Dienst verrichtet AdGuard Home, das auf einem NUC läuft.
Die FritzBox ist aktuell als Gateway in den DHCP Daten (des NAS) eingetragen.
Der NUC ist als einzige DNS Adresse in den DHCP Daten (des NAS) eingetragen.

Könnte ich jetzt diesen RasPi, der das Handy am USB Port hat, als Gateway in den DHCP Daten eintragen, auf dem RasPi die korrekten Routings eintragen, und dann liefe das?
Falls das der richtige Ansatz ist, wäre ich sehr dankbar, wenn mir Jemand sagt, welchen ROUTE Konfiguration das sein muss (und mit welchem Linux Tool man das macht.

(ich bin Entwickler, kein Netzwerk-Admin - ich bitte daher um Nachsicht, wenn ich einige Begriffe dilletantisch genutzt habe)

Besten Dank im Voraus
Udo

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7028982545

Url: https://administrator.de/en/raspi-als-gateway-wan-per-usb-tethering-7028982545.html

Ausgedruckt am: 22.12.2024 um 02:12 Uhr

22 Kommentare

Neuester Kommentar

dreht mir die FritzBox dann das Kabel ganz ab d.h. ich habe keine Telefonie mehr.

Nein, das ist Unsinn. Sehr wahrscheinlich ist dein Mobilfunknetz Provider NICHT dein Festnetz Telefonieprovider, denn dann ist das Verhalten Normal. Du kannst z.B. nicht auf das Telefonie Festnetz von Vodafone mit einer VoIP Connection z.B. aus dem O2 oder Telekom Netz zugreifen. Das unterbinden die Telfonieprovider generell. Ausnahme ist nur ein reiner SIP Provider wie DUSnet, SIPgate und Co. oder...wenn dein Mobilfunk auch bei Vodafone ist also gleicher Voice Provider.

d.h. der RasPi sollte dann ja 2 Netzwerk-Interfaces haben und könnte somit als Router (bzw. Gateway) arbeiten

Ja, das ist richtig. Guckst du z.B, hier. Ob das ein dedizierte Stick oder ein Smartphone ist dabei egal.

als Gateway in den DHCP Daten eintragen, auf dem RasPi die korrekten Routings eintragen, und dann liefe das?

Ja, das würde es.

welchen ROUTE Konfiguration das sein muss (und mit welchem Linux Tool man das macht.

Dazu benötigt man gar kein Tool! Der RasPi ist in dem Falle ja das "Ersatz" Default Gateway ins Internet. Er bekommt automatisch vom per USB angeschlossenen Smartphone oder Stick eine Default Route ins Internet.
Das Einzige wofür du sorgen musst ist das bei Ausfall der FritzBox alle Clients in deinem Netzwerk nicht mehr die FritzBox IP als Default Gateway bekommen sondern die IP des RasPi "Ersatzrouters".
Fertig ist der Lack!
Das machst du dann am einfachsten über den vorhandenen DHCP Server.

Eine alternative Lösung wäre die Verwendung eines Dual WAN Balancing Routers statt des RasPis der auch entsprechend bei Ausfall des primären Links automatisch umschaltet.
Es gibt halt viele Wege nach Rom und beides führt zum Erfolg.

Hi aqui,

erstmal vielen Dank für die ausführliche Antwort. Das hilft schonmal ungemein, dass ich nicht komplett auf dem Holzweg bin. ;)

Sehr wahrscheinlich ist dein Mobilfunknetz Provider NICHT dein Festnetz Telefonieprovider, denn dann ist das Verhalten Normal.

Nein, ist nicht so. Der Kabelanschluss ist von vodafone und die obilfunkkarte ist eine CallYa von vodafone. Da muss ich dann nochmal bei der Technik nachfragen, warum die Telefonnummern nicht über das eigene Mobilfunknetz registriert werden. Kann evtl. daran liegen, dass ich beim Kabelvertrag eine feste IP habe...

Aber weiß der RasPi denn, wann er etwas in das interne Netz (IP Kreis 192.168.168.0/24) und wann auf das andere (Inter-)netz?

Das Einzige wofür du sorgen musst ist das bei Ausfall der FritzBox alle Clients in deinem Netzwerk nicht mehr die FritzBox IP als Default Gateway bekommen sondern die IP des RasPi "Ersatzrouters". Fertig ist der Lack!
Das machst du dann am einfachsten über den vorhandenen DHCP Server.

Das war der Plan, dass ich im DHCP die interne 192.168.168.xxx vom RasPi als Gateway einzutragen. Muss ich das dann rein theoretisch auch bei der Fritzbox?

Als weiteres Detail: mein DHCP-Dienst auf der Synology hat eine Reihe von IP Reservierungen per MAC, damit bestimmte Rechner immer die gleiche IP bekommen, ich aber trotzdem damit z.B. Nameserver oder eben auch das Gateway zentral setzen kann.

Im Voraus schonmal ein weiteres Dankeschön!

Cheers,
Udo

@BrucklynBoy ich persönlich würde auch auf eine Firewall setzen die DUAL-WAN beherrscht (pfSense/OPNsense/OpenWRT) und nicht sowas basteln mit einem RASPI (gerade da du ja Dienste anbieten musst/willst) wo bei mir noch die Frage aufkommt, hat dein Handy Provider kein CGN oder ähnliches im Einsatz? Alternativ wenn du in Sachen Netzwerk fit bist kannst du auch dir was basteln und dir OpenBGP anschauen.

Aber weiß der RasPi denn, wann er etwas in das interne Netz (IP Kreis 192.168.168.0/24) und wann auf das andere (Inter-)netz?

Das kommt allein auf den Client an! Wenn der den RasPi als Default Gateway angegeben hat, dann rennt alles über den RasPi. Wie eingangst schon gesagt ist am Client entscheidend welches Default Gateway dort gesetzt ist. FB oder oder RasPi.

Muss ich das dann rein theoretisch auch bei der Fritzbox?

Kommt immer drauf an WER der DHCP Server in deinem Netz ist. Es kann ja bekanntlich immer nur einen DHCP Server im Netz geben und DER muss dann das richtige Gateway an die Clients verteilen... ganz einfache Logik!

Da das bei dir das Synology NAS ist, ist diese Frage eigentlich völlig überflüssig. Zumal auch die FB mit DHCP dann nix mehr am Hut hat. Dort muss ja zwangsweise DHCP deaktiviert sein wenn das die Synologay macht, logisch!

Was Kollege @micneu oben anspricht ist sowas wie das hier. Das muss nicht unbedingt eine OPNsense / pfSense Firewall sein sondern kann auch jeder beliebige Router sein der 2 oder mehr WAN Ports hat bzw. supportet wie z.B. ein Mikrotik hAP lite.
Wie schon gesagt...die vielen Wege nach Rom. 😉

Quote from @aqui:

Aber weiß der RasPi denn, wann er etwas in das interne Netz (IP Kreis 192.168.168.0/24) und wann auf das andere (Inter-)netz?

Hmm. Hab ich grad probiert...
Heimnetz ist 192.168.168.0/24
Der RasPi mit einem USB-Tethering Handy hat die 192.168.168.1 (bezogen per MAC Reservierung vom DHCP Dienst)
DHCP ist auf 192.168.168.199 (die Synology mit dem entsprechenden Dienst). In den DHCP Settings ist der RasPi (192.168.168.1) als Gateway eingetragen.
Die FritzBox auf 192.168.168.200 war vorher der Gateway.

Wenn ich mir eine "neue" IP auf einem Laptop hole, steht der RasPi als Gateway in den IP Einstellungen (nicht mehr die FB). Aber trotzdem komme ich nicht ins Internet.
Mit dem Ansatz aus diesem Artikel kommt zumindest der RasPi dann ins Internet, aber der Rest des Heimnetzes nicht.

Ich kan mich per SSH mit dem RasPi (läuft ein Debian drauf) verbinden, daher weiß ich, dass er ins INet kommt.
Auf Dem RasPi existieren 2 interfaces:

Ich habe (nach Anleitung aus dem obigen Artikel) die folgenden Befehle auf dem RasPi ausgeführt:

sudo route del default
sudo route add default gw 192.168.57.17 enx4a5dcc68ce7c

sudo iptables -X
sudo iptables -F
sudo iptables -t nat -X
sudo iptables -t nat -F

sudo iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

sudo iptables -t nat -I POSTROUTING -o enx4a5dcc68ce7c -j MASQUERADE

Ich bin grad etwas ratlos....

Wenn Jemand eine "schnelle Lösung" hat, gerne auch ein "mach den RasPi platt, spiele Folgendes draf, trag Folgendes ein". Der RasPi ist aktuell nur dafür geplant. Einfach das Handy als INet-Gateway nutzen fürs Heimnetz.

Quote from @micneu:

@BrucklynBoy ich persönlich würde auch auf eine Firewall setzen die DUAL-WAN beherrscht (pfSense/OPNsense/OpenWRT) und nicht sowas basteln mit einem RASPI (gerade da du ja Dienste anbieten musst/willst) wo bei mir noch die Frage aufkommt, hat dein Handy Provider kein CGN oder ähnliches im Einsatz? Alternativ wenn du in Sachen Netzwerk fit bist kannst du auch dir was basteln und dir OpenBGP anschauen.

Nicht sicher, was du damit meinst. Der RasPi soll keinerlei Dienste anbieten, außer als INet Gateway zu fungieren.

hat dein Handy Provider kein CGN oder ähnliches im Einsatz

Kabel und der Handy Tarif (CallYa) sind von vodafone, aber mein Vertrauen in die Technik von vodafone schwindet gerade massiv. Von daher... hätte ich lieber einen Ansatz, der sich nicht auf irgend welche Fähigkeiten von vodafone verlassen muss

Aber trotzdem komme ich nicht ins Internet.

Das ist immer so eine unreflektierte "Killeraussage" mit DEM "Internet".

WIE testest du das denn??
Wenn du einen Hostnamen pingst wie z.B. www.heise.de dann ist zumindestens ja auch immer ein DNS Server involviert der diesen Hostnamen ja auflösen muss in eine IP Adresse. Hast du das bedacht??
Besser ist es also immer eine nackte IP Adresse über den RasPi zu pingen wie z.B. 8.8.8.8 um DNS Problematiken erstmal aus dem Wege zu gehen.

Klar sollte natürlich auch sein das du zuvor auf dem RasPi direkt dessen Internet Connectivity über das Tethering Smartphone wasserdicht sicherstellt indem du von dort

eine nackte IP wie 8.8.8.8 pingst
einen Hostnamen wie www.heise.de pingst

Klappt das alles ist zumindestens sicher das der RasPi als Internet Router fehlerlos arbeitet.

Welchen DNS Server der RasPi benutzt bzw. vom Tethering Smartphone übermittelt bekommt kannst du immer mit nslookup www.heise.de oder dig im Handumdrehen selber herausfinden.
Sollte dein RasPi nicht als DNS Proxy ins Internet arbeiten, dann musst du im DHCP Server logischerweise auch außer der Gateway IP auch noch den RasPi DNS Server den LAN Clients mitgeben damit sie Hostnamen auflösen können und nicht wieder ein laienhaftes "Internet geht nicht" kommt.

Ich habe (nach Anleitung aus dem obigen Artikel) die folgenden Befehle auf dem RasPi ausgeführt:

Das ist unnötig und auch kontraproduktiv.
NAT (Masquerading) und Firewalling (iptables) sind auf dem rasPi nicht erforderlich und auch überflüssig weil das immer schon das tethernde Smartphone übernimmt was ja quasi als Firewall NAT Router agiert!
Du betreibst ja mit dem RasPi nichts weiteres als eine simple Router Kaskade wie sie HIER beschrieben ist. Lesen und verstehen...
NAT und Firewalling muss nur gemacht werden wenn direkt ein USB Mobilfunk Stick am RasPi genutzt wird nicht aber ein tetherndes Smartphone was diese Aufgabe übernimmt!

"mach den RasPi platt, spiele Folgendes draf, trag Folgendes ein".

Völlig unnötig wenn man es richtig macht. Koppelst du den RasPi per WLAN, Bluetooth oder USB an das Tethering Smartphone?
Ist doch alles kein Hexenwerk und in 10 Minuten erledigt!

Quote from @aqui:

Aber trotzdem komme ich nicht ins Internet.

Das ist immer so eine unreflektierte "Killeraussage" mit DEM "Internet".

Yep. Stimmt. Ich gelobe Besserung

WIE testest du das denn??

Ich habe den RP nochmal neu aufgesetzt, um jegliche Veränderungen, die von dem iptables-Artikel kamen, wieder entfernt sind. Es ist also ein Debian-basiertes sauberes "Linux pi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64"

Der RP hat jetzt die IP 192.168.168.198 (per Reservierung im DHCP auf der Synology). Der RP ist im LAN. Vom DHCP bekommt der RP als DNS Server die 192.168.168.111 (das ist ein NUC mit AdGuard Home) und als Gateway sich selber (die 192.168.168.198).
Die DHCP Einstellungen auf der Synology (192.168.168.199) sehen so aus:

Wenn du einen Hostnamen pingst wie z.B. www.heise.de dann ist zumindestens ja auch immer ein DNS Server involviert der diesen Hostnamen ja auflösen muss in eine IP Adresse. Hast du das bedacht??
Besser ist es also immer eine nackte IP Adresse über den RasPi zu pingen wie z.B. 8.8.8.8 um DNS Problematiken erstmal aus dem Wege zu gehen.

Verstanden

Klar sollte natürlich auch sein das du zuvor auf dem RasPi direkt dessen Internet Connectivity über das Tethering Smartphone wasserdicht sicherstellt indem du von dort

eine nackte IP wie 8.8.8.8 pingst
einen Hostnamen wie www.heise.de pingst

Das macht er leider nicht

nessi@pi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.168.198 icmp_seq=1 Destination Host Unreachable
From 192.168.168.198 icmp_seq=2 Destination Host Unreachable

Welchen DNS Server der RasPi benutzt bzw. vom Tethering Smartphone übermittelt bekommt kannst du immer mit nslookup www.heise.de oder dig im Handumdrehen selber herausfinden.

Der lookup funktioniert:

nessi@pi:~ $ dig heise.de

; <<>> DiG 9.16.37-Raspbian <<>> heise.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30040
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de.                      IN      A

;; ANSWER SECTION:
heise.de.               7230    IN      A       193.99.144.80

;; Query time: 0 msec
;; SERVER: 192.168.168.111#53(192.168.168.111)
;; WHEN: Mon May 08 13:55:04 BST 2023
;; MSG SIZE  rcvd: 53

Völlig unnötig wenn man es richtig macht. Koppelst du den RasPi per WLAN, Bluetooth oder USB an das Tethering Smartphone?

USB-Tethering

Die Netzwerk Interfaces sehe so aus, wenn das USB Thethering aktiviert ist.

nessi@pi:~ $ ifconfig -a
enx4a5dcc68ce7c: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.57.37  netmask 255.255.255.0  broadcast 192.168.57.255
        inet6 fe80::d2de:f8bb:c51e:dae9  prefixlen 64  scopeid 0x20<link>
        ether 4a:5d:cc:68:ce:7c  txqueuelen 1000  (Ethernet)
        RX packets 7  bytes 1050 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 3534 (3.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.168.198  netmask 255.255.255.0  broadcast 192.168.168.255
        inet6 fe80::8ebe:e20d:47aa:58d  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:b2:18:9f  txqueuelen 1000  (Ethernet)
        RX packets 1347  bytes 114361 (111.6 KiB)
        RX errors 0  dropped 658  overruns 0  frame 0
        TX packets 761  bytes 74291 (72.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 245  bytes 26956 (26.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 245  bytes 26956 (26.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 66:d1:bc:ea:bd:ff  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Und die Routes sehen so aus

nessi@pi:~ $ ip route show
default via 192.168.168.198 dev eth0 proto dhcp metric 100
default via 192.168.57.17 dev enx4a5dcc68ce7c proto dhcp metric 101
192.168.57.0/24 dev enx4a5dcc68ce7c proto kernel scope link src 192.168.57.37 metric 101
192.168.168.0/24 dev eth0 proto kernel scope link src 192.168.168.198 metric 100

Ist doch alles kein Hexenwerk und in 10 Minuten erledigt!

Das wünsche ich mir

Ich hab allerdings keine Ahnung, wo ich mich so dämlich anstelle...
Muss ich dem RP eine statische IP geben, damit er sich nicht selber als Gateway vom DHCP Server bekommt?

Das macht er leider nicht

Zeigt das dein RasPi schon von sich aus KEINEN Internet Zugang hat. Sprich der ist gar nicht mit dem Tethering Smartphone verbunden!

Deshal nochmals die Frage:

WIE verbindest du dich mit dem Tethering Smartphone?? WLAN, Bluetooth, USB ??
Was ist enx4a5dcc68ce7c für ein Adapter auf dem RasPi?

Du kannst ja selber oben sehen das das Interface eth0 und auch das Interface enx4a5dcc68ce7c beide als DHCP Clients arbeiten und sich von den jeweiligen DHCP Servern eine IP ziehen und auch das Default Gateway.
Zwei Default Gateways kann es technisch nicht geben, deshalb kannst du an der Metric oben sehen welches Gateway gewinnt. Sieger ist imemr das mit dem niedrigsten Metric Wert.
In deinem Falle also das eth0 Interface mit dem Gateway: 192.168..168.198. Sprich der RasPi routet also alles was über ihn ins Internet soll an die 192.168.168.198. Und darüber dann vermutlich ins Nirwana wie man am gescheiterten Ping auf die 8.8.8.8 ja unschwer sehen kann.

keine Ahnung, wo ich mich so dämlich anstelle...

Du musst nur mal lesen! Das ip r sagt doch schon alles!

Die Default Route des RasPis MUSS also logischerweise in deinem Setup immer auf die IP Adresse des Tethering Smartphones zeigen, damit alles entsprechend darüber ins Internet geroutet wird. Sehr wahrscheinblich ist das Smartphone nicht die 192.168.168.198 so das es nachvollziehbar ist warum das Routing bzw. die Internet Connectivity in die Hose geht. Versteht auch ein IP Anfänger.

Erst wenn der RasPi selber einen Ping oder Traceroute ins Internet hinbekommt kann er doch auch andere ins Internet routen. Alles andere wäre Magie. Das sagt einem doch schon der gesunde Menschenverstand.
Also nochmals:

Wie ist das Tethering Smartphone angebunden und über welchen Adapter?
Hast du IPv4 Forwarding (Routing) im RasPi global aktiviert?! Das ist wichtig sonst KEIN Routing auf dem RasPi! Guckst du dazu HIER. (Am Ende das Kapitels "VLANs auf RasPi" Entkommentieren der Zeile #net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf)

Nebenbei: Deine Gateway Adressierung ist gelinde gesagt chaotisch. Jeder Laie weiss das man Routern immer statische IPs gibt. Gut, Mac Reservierung ist da noch tolerabel da quasi statisch.
Best Practise ist aber immer das man den Routern IP Adressen ganz am Anfang oder am Ende der Host Adressrange im Netz gibt. Bei einem 24er Prefix also die .1 und/oder die .254
Der Grund ist das es so niemals zu Adresschaos mit DHCP Ranges geben kann, denn eine Handvoll IP Adressen an den Enden spart man immer vom DHCP Pool aus. Eben weil man da statische oder reservierte Infrastruktur IP Adressen hinlegt. Auch weil die .1 und die .254 erheblich einfacher zu identifizieren sind als irgendwas "mittendrin". Einfache Logik.

@BrucklynBoy wenn du so keine guten Netzwerk Kenntnisse hast, warum setzt du dann nicht eine fertige Lösung ein, die das dann für dich übernimmt (gleich eine lösung die für DUAL-WAN fähig ist)?

meine Empfehlung bau dein netz um, so ähnlich würde ich es umsetzen wenn ich das Problem hätte:

 ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─Internet─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─  ─


               ┌─────────────────┐         ┌─────────────────┐
               │Dein Kabel Router│         │   Dein Handy    │
               └─────────┬───────┘         └───────┬─────────┘
                         │                         │
                         │                         │
                         │                         │
┌────────────────────────┴─────────────────────────┴──────────────────────────────┐
│                                                                                 │
│pfSense/OPNsense/OpenWRT                                                         │
│was dir am besten gefällt                                                        │
│am besten 3 x Ethernet                                                           │
│1 x WAN Kabel-Router                                                             │
│1 x USB für dein Handy (bin mir nicht sicher ob das die Sense können             │
│1 x LAN direkt am Switch                                                         │
│1 x Ethernet wenn du dich entscheidest ein ordentlichen LTE/5G Router einzusetzen│
│                                                                                 │
└───────────────────────────────────┬─────────────────────────────────────────────┘
                                    │
                                    │
                                 ┌──┴─┐
                                 │LAN │
                                 └────┘

PS: das Setup kannst du wahrscheinlich auch mit deinem Synology umsetzen (ob man das wirklich will muss jeder für sich entscheiden)

Quote from @aqui:

Das macht er leider nicht

Zeigt das dein RasPi schon von sich aus KEINEN Internet Zugang hat. Sprich der ist gar nicht mit dem Tethering Smartphone verbunden!

Deshal nochmals die Frage:

WIE verbindest du dich mit dem Tethering Smartphone?? WLAN, Bluetooth, USB ??

Hab ich oben geschrieben auf deine Frage. USB

* Was ist enx4a5dcc68ce7c für ein Adapter auf dem RasPi?

Das ist der Adapter, der erscheint, wenn ich das USB Tethering aktiviere.

Genau da liegt meine Unwissenheit. Ich habe keine Ahnung, wie man ROUTEs richtig einstellt.

keine Ahnung, wo ich mich so dämlich anstelle...

Du musst nur mal lesen! Das ip r sagt doch schon alles!

Mir leider nicht so viel wie dir

Heißt also, ich muss eth0 (das ist die 192.168.168.198 die IP von enx4a5dcc68ce7c manuell als Gateway geben?

Wie ist das Tethering Smartphone angebunden und über welchen Adapter?

Handy steckt per USB am RP und sobals das USB Thethering aktiviert ist, erscheint die Netzwerkschnittstelle enx4a5dcc68ce7c

* Hast du IPv4 Forwarding (Routing) im RasPi global aktiviert?! Das ist wichtig sonst KEIN Routing auf dem RasPi! Guckst du dazu HIER. (Am Ende das Kapitels "VLANs auf RasPi" Entkommentieren der Zeile #net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf)

Habe/Hatte ich nicht, führe ich mir jetzt mal genauer zu Gemüte.

Dank dir!

Heißt also, ich muss eth0 (das ist die 192.168.168.198 die IP von enx4a5dcc68ce7c manuell als Gateway geben?

Nein, das wäre doch routingtechnsicher Quatsch und weisst du natürlich auch selber.

Das war ggf. auch leider etwas missverständlich ausgedrückt. Sorry, dafür...
Gemeint war wenn du auf dem RasPi bist muss die einzige Default Route auf das enx4a5dcc68ce7c Interface zeigen. Logisch, denn der RasPi soll ja alles via Tethering Interface enx4a5dcc68ce7c ins Internet routen. "ip r" zeigt dir das. Hilfreich ist auch das Traceroute Kommendo z.B. traceroute 8.8.8.8 was dann den Routing Weg zum Ziel Hop für Hop anzeigt.
Setuptechnisch wäre es ggf. besser du gibst dem RasPi eine feste statische IP Adresse ohne DHCP. DHCP bzw. DHCP mit Reservierung hat ja immer den Nachteil das der DHCP Server dem RasPi immer auch ein Default Gateway mitteilt. Sprch er bekommt darüber dann immer automatisch eine statische Route über das eth0 Interface mitgeteilt.
Das Tethering Interface injiziert, wie du ja siehst, ebenfalls dynamisch eine 2te Default Route.
Routingtechnisch bekommt die Route über das lokale LAN Interface immer die bessere Metrik. "100" in deinem Beispiel. Das Tethering Interface aber prinzipbedingt eine schlechtere (101). Sprich die Route über das Tethering ins Internet ist dann gar nicht aktiv.

Da gibt es 4 Möglichkeiten das zu umgehen:

Default Route via eth0 (LAN) löschen. Ist aber immer nur temporär denn nach dem nächsten DHCP Renewal ist sie wieder da.
Metrik am LAN Interface eth0 permanent schlechter machen. Das geht indem man die Konfig Datei für den DHCP Client anpasst unter /etc/dhcpcd.conf und dort

interface eth0
metric 300
eingibt und rebootet.
Ein "ip r" zeigt dir dann das jetzt die Route über eth0 schlechter ist (300) und die Tethering Route mit dem besseren 101 greift.

oder es temporär mit dem ifmetric Kommando anpasst.

sudo apt install ifmetric installiert das Kommando und...
sudo ifmetric eth0 300 passt es dann bis zum nächsten Reboot an

Setze die eth0 IP statisch und ohne Gateway IP!

Mit der statischen IP Adressierung bekommt dann deine Route übers Tethering immer den Vorrang weil sie dann eben nur die einzige Route ist.

Das löst das Problem hat aber dann leider einen gravierenden Nachteil:
So "lernt" der RasPi niemals mehr dynamisch eine alternative Route über eth0 per DHCP. Sprich, ziehst du dein Smartphone vom USB ab kommt der RasPi nicht mehr ins Internet weil ihm dann die (schlechtere) eth0 Default Route fehlt auf die er sonst automatisch zurückgehen würde.

Wären beide Routen über die Metrikunterschiede aktiv würde als Fallback beim Fehlen des Tetherings sofort die schlechtere eth0 Route wieder greifen. Einfache Logik...

Fazit:
Beste Lösung in deinem Fall ist die eth0 Metrik über die Konfig in etc/dhcpcd.conf anzupassen. Oder, wenn du es erstmal nur temporär testen willst, über das ifmetric Kommando zu setzen.

Genau da liegt meine Unwissenheit. Ich habe keine Ahnung, wie man ROUTEs richtig einstellt.

Das ist kinderleicht und schaffst du als RasPi Profi mit Links im Handumdrehen....

Um grundsätzlich den USB Tethering Anschluss ins Internet zu testen solltest du, wie gesagt, die Default Route über das lokale LAN (eth0 Adapter) erstmal temporär löschen oder so mit der Metrik anpassen wie oben genau beschrieben!
So bleibt dann nur die Route via enx4a5dcc68ce7c Interface ins Internet, also dem Tethering Phone oder diese Route ist über ihre bessere Metrik immer die primäre Route!

Das Löschen geht mit
ip route delete default via 192.168.168.198
Die Anpassung über die bessere Metrik ist oben beschrieben.
Wenn du jetzt im Falle des Löschens der 2ten Route ein "ip r" eingibst sollte es lediglich nur eine Default Route via Tethering geben.
Im Falle der Metrik Anpassung siehst du mit ip a das die Interface Metrik des eth0 Interfaces jetzt 300 ist und damit auch die Default Route (ip r) darüber eine deutlich schlechtere Metrik hat und die Tethering Route mit der 101 aktiv ist und greift.
Dann sollte auch der Ping auf 8.8.8.8 mit beiden Optionen klappen!

Traceroute verifiziert dir dann noch einmal explizit das alles übers Tethering geht.

Habe/Hatte ich nicht,

Oh, man. Aber ohne das scheitert doch dann generell das Routing weil der RasPi das dann gar nicht kann.
Das musst du natürlich zuallererst anpassen! Solche Banalitäten sollte man aber auch als Anfänger wissen. 🧐
Also mit dem nano Texteditor nano /etc/sysctl.conf die sysctl.conf Datei editieren und das Kommentarzeichen "#" vor der Zeile "#net.ipv4.ip_forward=1" entfernen!
Datei mit <ctrl o x> sichern und den RasPi rebooten. Fertisch...danach kann er dann auch dein Internet routen!

Inhaltsverzeichnis

Praxisbeispiel iPhone

Routing Tabelle

Anpassung Metrik (hier temporär mit ifmetric)

Check der Tethering Route mit Traceroute

Fazit

Praxisbeispiel iPhone

USB Tethering auf dem RasPi nach diesem Beispiel aktiviert:
https://www.jiribrejcha.net/2020/02/iphone-usb-tethering-on-wlan-pi/

Routing Tabelle

RasPi bekommt, wie bei dir auch, ein zusätzliches virtuelles Tethering Interface, hier eth1

root@zeropi:/home/# ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4c:36:00:e1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.184/24 brd 192.168.7.255 scope global dynamic noprefixroute eth0
       valid_lft 53015sec preferred_lft 42215sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 66:70:33:b1:ab:73 brd ff:ff:ff:ff:ff:ff
    inet 172.20.10.8/28 brd 172.20.10.15 scope global dynamic noprefixroute eth1
       valid_lft 86331sec preferred_lft 75531sec 

Auch hier hat der RasPi über eth0 (LAN Port im DHCP Client Modus) erwartungsgemäß eine default Route mit besserer Metrik via DHCP vom DHCP Server bekommen (Reihenfolge der Anzeige!) die wir aber nicht möchten, weil wir ja über das Tethering Interface eth1 ins Internet wollen.

root@zeropi:/home/# ip r
default via 192.168.7.254 dev eth0 proto dhcp src 192.168.7.184 metric 202 
default via 172.20.10.1 dev eth1 proto dhcp src 172.20.10.8 metric 205 
172.20.10.0/28 dev eth1 proto dhcp scope link src 172.20.10.8 metric 205 
192.168.7.0/24 dev eth0 proto dhcp scope link src 192.168.7.184 metric 202 

Anpassung Metrik (hier temporär mit ifmetric)

Die eth0 (LAN Port) Metrik wird jetzt mit dem Wert 300 über das ifmetric Kommando absichtlich verschlechtert um das Tethering Interface zu bevorzugen.. (Höherer Wert = schlechtere Metrik)
Nach dieser künstlichen Metrik Verschlechterung des LAN Ports (300) ist jetzt die Tethering Route durch ihre dann bessere Metrik primäre Route ins Internet! Ein Ping ins Internet klappt darüber erwartungsgemäß fehlerlos.
(Für deine Installation solltest du das später permanent über das/eth/dhcpcd.conf Setting in der DHCP Client Konfig Datei machen!)

root@zeropi:/home/# ifmetric eth0 300

root@zeropi:/home/# ip r
default via 172.20.10.1 dev eth1 proto dhcp src 172.20.10.8 metric 205 
default via 192.168.7.254 dev eth0 proto dhcp src 192.168.7.184 metric 300 
172.20.10.0/28 dev eth1 proto dhcp scope link src 172.20.10.8 metric 205 
192.168.7.0/24 dev eth0 proto dhcp scope link src 192.168.7.184 metric 300 

root@zeropi:/home/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=159 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=37.8 ms 

Check der Tethering Route mit Traceroute

Anhand des ersten Routing Hops 172.20.10.1 kannst du genau sehen das der Traffic auch wirklich über das Tethering Interface via iPhone rausgeht!! Die 172.20.10er IP Adresse gehört zum Tethering Interface eth1 des RasPis. (default via 172.20.10.1 dev eth1)

root@zeropi:/home/# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  172.20.10.1  1.627 ms  1.358 ms  1.143 ms
 2  * * *
 8  8.8.8.8  36.087 ms  56.425 ms  55.930 ms 

Vergleichend ein Traceroute über einen FritzBox VDSL Link an dem der RasPi parallel über eth0 (LAN) hängt wenn diese Route greift und das Tethering inaktiv ist. Man achte auf den ersten Hop! (Lokale Fritzbox IP) Auch sind die Laufzeiten erwartungsgemäß besser als im LTE Mobilfunknetz.
Damit funktioniert erwartungsgemäß dann auch das automatische Umschalten des RasPis zurück auf die eth0 Route wenn das Tethering inaktiv ist.

root@zeropi:/home/# traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.7.254  1.190 ms  0.727 ms  1.090 ms
 2  62.125.164.4  7.507 ms  11.290 ms  10.616 ms
 3  * * *
 6  8.8.8.8  8.641 ms  8.426 ms  8.956 ms 

Fazit

Works as designed!! 👍 😉

Vorab: DANKE für all die sehr detailierten und guten Erklärungen. So langsam kommts bei mir an

Ich hab außerdem die Fritzbox (mit dem DHCP Server) auf .254 geschoben (das aktuelle Gateway). Der RP hat nun die .251. Auf dem RP hat die Schnittstelle mit dem USB Tethering den Namen enx4a5dcc68ce7c und die IP 192.168.57.17

Ich dreh die Quotes & Antworten etwas um, damit's Sinn (aus meiner Sicht) macht.

Habe/Hatte ich nicht,

Erledigt. net.ipv4.ip_forward=1 ist die einzige nicht auskommentierte Zeile in /etc/sysctl.conf

Da gibt es 4 Möglichkeiten das zu umgehen:

Default Route via eth0 (LAN) löschen.
Metrik am LAN Interface eth0 permanent schlechter machen. Das geht indem man die Konfig Datei für den DHCP Client anpasst unter /etc/dhcpcd.conf und dort

interface eth0
metric 300
eingibt und rebootet.

oder es temporär mit dem ifmetric Kommando anpasst.

sudo ifmetric eth0 300 passt es dann bis zum nächsten Reboot an

Setze die eth0 IP statisch und ohne Gateway IP!

Ich habe mich für Tor 2 entschieden und habe in /etc/dhcpcd.conf die Zeile interface eth0 aktiviert und drunter (ohne Einrückung) metric 333 hinzugefügt.

# Example static IP configuration:
interface eth0
metric 333
#static ip_address=192.168.0.10/24

Leider sieht nach einem Reboot das Ergenis von ip r immer noch so aus:

default via 192.168.168.254 dev eth0 proto dhcp metric 101
default via 192.168.57.17 dev enx4a5dcc68ce7c proto dhcp metric 102
192.168.57.0/24 dev enx4a5dcc68ce7c proto kernel scope link src 192.168.57.37 metric 102
192.168.168.0/24 dev eth0 proto kernel scope link src 192.168.168.251 metric 101

So bleibt dann nur die Route via enx4a5dcc68ce7c Interface ins Internet, also dem Tethering Phone oder diese Route ist über ihre bessere Metrik immer die primäre Route!

Wenn ich nun testweise die default route von eth0 lösche mit ip route delete default via 192.168.168.254, sieht ip r so aus:

default via 192.168.57.17 dev enx4a5dcc68ce7c proto dhcp metric 102
192.168.57.0/24 dev enx4a5dcc68ce7c proto kernel scope link src 192.168.57.37 metric 102
192.168.168.0/24 dev eth0 proto kernel scope link src 192.168.168.251 metric 101

Allerdings sieht ein traceroute 8.8.8.8 -4 -n immer noch so aus, als ob es über die Fritzbox (192.168.168.254) geht...

nessi@pi:/etc $ traceroute 8.8.8.8 -4 -n
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.57.17  4.049 ms  3.829 ms  3.679 ms
 2  192.168.168.254  73.178 ms  73.041 ms  72.893 ms
 3  192.168.42.129  72.732 ms  72.593 ms  72.453 ms
...
15  8.8.8.8  38.907 ms  38.750 ms  42.444 ms

Wo liegt da mein Fehler? Und warum merkt sich der Pi nicht die eth0 Metric?

Hi!

Quote from @micneu:

@BrucklynBoy wenn du so keine guten Netzwerk Kenntnisse hast, warum setzt du dann nicht eine fertige Lösung ein, die das dann für dich übernimmt (gleich eine lösung die für DUAL-WAN fähig ist)?

Weil bis vor 10 Tagen hier alles perfekt funktioniert hat und ich gerade eine Lösung bauen muss, weil vodafone nicht in der Lage ist, mir ordentlich zu helfen. Einfach nur das Handy an die FB zu klemmen, bringt mir zwar das Internet wieder, aber dann werden die IP-Telefonnummern nicht mehr korrekt registriert (auch wenn es logischweise möglich sein sollte). Deshalb versuche ich gerade, dass ich die Fritzbox mit ca. 1 MBit/s Downstream (und lustigerweise immer noch 50 MBit/s Upstream) wieder ans Netz zu kriegen, dass die Telefonnummern wieder erreichbar sind, mein eigentlicher Datenverkehr aber über die (temporäre) Handy-Verbindung läuft.
Da ich auch LAN-Server hier habe, reicht es mir nicht, das Handy direkt an meinen Laptop zu hängen.
Und da ich hoffe, dass irgendewann die normale Kabel-Leitung wieder voll geht, würde ich dann gerne einfach nur das Handy abstöpseln und das Default Gateway wieder auf die Fritzbox setzen.

Und als Nebeneffekt einfach noch etwas Netzwerkern lernen oder zumindest partiell verstehen.

Ich hab außerdem die Fritzbox (mit dem DHCP Server) auf .254 geschoben

Wieso das denn?? 🤔
Fritzbox mit der .254 ist ja per se erstmal richtig mit den bevorzugten Router Adressen auf .1 und/oder .254 aber sagtest du nicht oben das dein DHCP Server auf deinem Synology NAS rennt?!
Ist das auch der Fall darfst du keinesfalls einen weiteren DHCP Server im lokalen LAN parallel laufen lassen weil es so zu einer DHCP Race Condition und damit zu Adresschaos im Netz kommt.
⚠️ Beim DHCP Server gilt immer das Highlander Prinzip: "Es kann nur einen geben!"
Achte also darauf das wirklich nur ein einziger DHCP Server aktiv rennt in deinem Netz!

Leider sieht nach einem Reboot das Ergenis von ip r immer noch so aus:

Mmhhh...dann hat die Metric Einstellung nicht gegriffen!!
Dir ist hoffentlich klar das du im Gegensatz zum ifmetric Kommando was sofort wirkt, für die Änderung in der DHCP Client Konf Datei den dhcpcd Daemon mit systemctl restart dhcpcd neu starten musst damit der die geänderte Konfig Datei neu einliest!
Hast du das vorher gemacht?? Ohne den Daemon Neustart (oder Reboot) wird die Konfig Datei nicht gelesen und dann natürlich auch die Metrik nicht gesetzt!
Im Zweifel erledigst du das erstmal mit ifmetric um generell die Funktion zu checken!

Allerdings sieht ein traceroute 8.8.8.8 -4 -n immer noch so aus, als ob es über die Fritzbox (192.168.168.254) geht...

Mmmhhh, das ist komisch, denn der erste Routing Hop geht ja richtigerweise an das Smartphone mit seiner IP 192.168.57.17 was ja gewollt und korrekt ist. Der RasPi nutzt also das korrekte Interface was die verbliebene Default Route ihm ja auch vorgibt.
Das Smartphone selber routet dann aber die Daten wieder an die FritzBox, sprich der pöhse Buhmann ist also dein Smartphone und nicht mehr der RasPi. Innerhalb des Smartphones ist also die Default Route via WLAN besser als die via LTE Mobilfunknetz was ja normal ist wenn ein WLAN aktiv ist, da das in der regel die bessere Performance (metrik) hat.
Das Spielchen kommt dir sicher irgendwie bekannt vor, oder??
Kann es sein, das du fälschlicherweise dein Smartphone parallel zum Mobilfunknetz auch noch im WLAN der FritzBox aktiv hast??
Das wäre dann natürlich falsch und würde erklären warum dein Smartphone dies der LTE Mobilfunk Connection vorzieht.
Logischerweise solltest du auf dem Smartphone das WLAN für den Test deaktiviert haben, was einem ja auch der gesunde IT Verstand sagt, denn nur so stellt man sicher das einzig nur die Mobilfunk LTE Verbindung ins Internet genutzt wird. Einmal in Ruhe nachdenken hilft...

Passe also das oben Gesagte alles entsprechend an und checke das nochmals!

Hi!

So. Nochmal durchgeatmet, den Kopf über ein paar Fehler geschüttelt...

Ich hab außerdem die Fritzbox (mit dem DHCP Server) auf .254 geschoben

Der DHCP ist nicht auf der FB. Die Highlander Geschichte kenne ich. Also DHCP gibt's nur einen, der ist (immer noch) auf der Synology (auf .253).

Leider sieht nach einem Reboot das Ergenis von ip r immer noch so aus:

Ja, habe nach der Änderung neu gestartet.

Nach einen systemctl restart dhcpcd hat ers dann. Aber ein Restart macht die neuen Werte dann zunichte.
Kann es sein, dass es daran liegt, dass das USB-Tethering bei einem Neustart vom Pi automatisch am Handy deaktiviert wird und nach dem erneuten Aktivieren des Thetherings ich immer wieder den dhcpcd dienst neu starten muss? Muss ich evtl. auch für das neue Interface ein hotplug aktivieren?

Ich könnte allerdings damit leben, dass ich - wenn der Pi mal neu gestartet wird, ich mich kurz per ssh einlogge und den dhcp Dienst neu starte nach dem Re-Aktivieren vom USB-Tethering.

...
Kann es sein, das du fälschlicherweise dein Smartphone parallel zum Mobilfunknetz auch noch im WLAN der FritzBox aktiv hast??

Ja, wars.

Das wäre dann natürlich falsch und würde erklären warum dein Smartphone dies der LTE Mobilfunk Connection vorzieht.

Logo. Ich hatte zum Testen, weils näher lag, mein anderes Handy mal eben dran gehängt und das WLAN vergessen. Beim eigentlichen Handy (das aktuell noch direkt an der FB hängt), ist WLAN schon deaktiviert. Also def. Userfehler (klatsch vor die Stirn)

So. Jetzt ignoriere ich zunächst mal das immer wieder notwendige systemctl restart dhcpcd und schau, was passiert, wenn ich nun den Pi als Gateway in den DHCP Einstellungen nutze...

(und ich muss mir überlegen, welche deiner vielen Antworten ich als Lösung markiere - vermutlich die vorletzte, die ja alles Wichtige und Richtige enthielt..
Ganz großes Lob für das Wissen und v.a. die Geduld! Mein Dank wird dich ewig verfolgen.

Cheers,
Udo

Und jetzt komm ich aber trotzdem nochmal angerannt... Selbst wenn ich nun den PI als Gateway für alle eingetragen habe, werden die Pakete nicht weiter geleitet.

Gleich nach dem Neustart des Pi:

nessi@pi:~ $ ip r
default via 192.168.42.129 dev enx025b53016238 proto dhcp metric 100
default via 192.168.168.254 dev eth0 proto dhcp metric 101
192.168.42.0/24 dev enx025b53016238 proto kernel scope link src 192.168.42.4 metric 100
192.168.168.0/24 dev eth0 proto kernel scope link src 192.168.168.251 metric 101

Dann sudo systemctl restart dhcpcd eingegeben. Ergebnis:

nessi@pi:~ $ ip r
default via 192.168.42.129 dev enx025b53016238 proto dhcp src 192.168.42.4 metric 203
default via 192.168.168.254 dev eth0 proto dhcp src 192.168.168.251 metric 333
192.168.42.0/24 dev enx025b53016238 proto dhcp scope link src 192.168.42.4 metric 203
192.168.168.0/24 dev eth0 proto dhcp scope link src 192.168.168.251 metric 333

Dann ein traceroute:

nessi@pi:~ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
192.168.42.129 (192.168.42.129)  0.485 ms  0.353 ms  0.260 ms
* * *
 ...
ipservice-092-214-120-014.092.214.pools.vodafone-ip.de (92.214.120.14)  31.683 ms  32.503 ms  30.568 ms
145.254.2.181 (145.254.2.181)  32.245 ms  31.116 ms  31.030 ms
72.14.195.160 (72.14.195.160)  36.776 ms  35.708 ms  35.428 ms
108.170.247.97 (108.170.247.97)  35.343 ms 74.125.244.97 (74.125.244.97)  36.209 ms 108.170.247.113 (108.170.247.113)  29.278 ms
108.170.228.45 (108.170.228.45)  29.024 ms 209.85.247.201 (209.85.247.201)  34.193 ms 142.251.68.125 (142.251.68.125)  33.956 ms
dns.google (8.8.8.8)  36.811 ms  36.488 ms  43.360 ms

Das sieht, wenn ich dich richtig verstanden habe, gut aus. Der Pi geht über seine eigene WAN Verbindung (interface enx025b53016238 via IP 192.168.42.129) raus.

Nach dem, wie ich deine Erklärungen verstanden habe, muss ich "nur" das Default Gateway in den DHCP Einstellungen auf die IP des Pi (192.168.168.251) ändern, damit alle Geräte in meinem Heimnetz den Pi als INternet Gateway nutzen.
Ich habe das im Kleinen versucht, indem ich einem Linux Rechner hier statisch (in der UI, nicht im Terminal) eine IP mit passender Netmask zugewiesen habe und das Gateway auf 192.168.168.251 gesetzt. Aber da läuft das traceroute ins Leere:

nessi@pi:~ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.168.251 3,386 ms 3,138ms  3,011ms
 2  * * *
 ... (so geht's immer weiter)  

Wo liegt mein Fehler? Muss ich dem Pi noch irgend was mitgeben, oder nochwas in den DHCP Einstellungen?

Also DHCP gibt's nur einen, der ist (immer noch) auf der Synology (auf .253).

Alles richtig gemacht! 👍

Das sieht, wenn ich dich richtig verstanden habe, gut aus.

Da hast du Recht! So sollte es sein und sieht gut aus soweit.

muss ich "nur" das Default Gateway in den DHCP Einstellungen auf die IP des Pi (192.168.168.251) ändern, damit alle Geräte in meinem Heimnetz den Pi als INternet Gateway nutzen.

Ich krame mal eine Android Gurke raus und stelle dein Setup mal genau nach. Mit dem iPhone oben klappt das soweit problemlos aber um nicht Äpfel und Birnen...du weisst schon kommt nochmal ein finaler Test mit einer Androiden Gurke....

Wo liegt mein Fehler? Muss ich dem Pi noch irgend was mitgeben

Du hast alles soweit richtig gemacht...ich check das!

So, die Androiden sind deutlich zickiger als ein iPhone wo es wie bei Apple gewohnt "out of the box" funktioniert.
Die blöden Androiden mögen beim USB Tethering in der Tat keine IP Pakete die von anderen IP Netzen kommen als ihr lokales Tethering Netz.

Mit anderen Worten du musst hier dann doch leider NATen am Tethering Port zum Smartphone damit die die anderen Absender IPs vom eth0 Interface (LAN) nicht "merken". Alles wird dann auf die IP des Tethering Interfaces umgesetzt so das das Tethering Phone der Meinung ist alles kommt aus seinem lokalen IP Netz und die Absender IPs nicht mehr "sieht". (Masquerading)

Da der RasPi mit dem aktuellen Bullseye Debian nur noch die moderneren nfttables supportet und auch gleich an Bord hat solltest du auch immer nur diese verwenden um NAT zu machen! (Keine iptables!)
Die hier verwendete Android Gurke (Xiaomi) nutzt interessanterweise eine usb0 Schnittstelle beim Tethering übers USB Kabel. Das ist echt ein gruseliger Zoo mit den üblen Androiden...der eine so der andere so. Ein weiterer Grund mal wieder um von dem Android Geraffel die Finger zu lassen. Aber egal...andere Baustelle...

root@zeropi:/home/# ip a
15: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:e0:4c:36:00:e1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.254/24 brd 192.168.1.255 scope global noprefixroute eth0

16: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 02:67:60:55:06:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.172/24 brd 192.168.42.255 scope global dynamic noprefixroute usb0
       valid_lft 3426sec preferred_lft 2976sec
    inet6 2a01:498:a123:4567:1d48:66f9:c921:abcd/64 scope global mngtmpaddr noprefixroute 

Das Spielchen mit der Interface bzw. Routing Metrik ist natürlich das gleiche wie oben!

Für die IP Adress Translation auf dem Tethering Interface mit nftables brauchst du folgendes:

flush ruleset

table ip nat {
        # Lokales LAN definieren
        define NAT_NETS = {
        192.168.1.0/24
        }
        # NAT fuer lokales LAN auf USB Tethering Port usb0
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                ip saddr $NAT_NETS oif usb0 masquerade
        }
} 

Das kannst du dir z.B. als Textdatei mit dem Namen nftnat.txt anlegen und mit nft --file nftnat.txt laden. Ein nft list ruleset zeigt dir an ob es aktiv ist.

Du musst das natürlich bei dir statt usb0 auf dein Interface enx4a5dcc68ce7c abändern!!
Ebenso das Beispiel IP Netz im lokalen eth0 LAN was unter "NAT_NETS" definiert ist (hier 192.168.1.0/24) musst du auf dein eigenes eth0 LAN IP Netz ändern!
Dieser Parameter bestimmt welche Pakete mit welcher Netzwerk Source IP Adresse am Tethering Port geNATet werden.
Falls du einmal mehrere IP Netze NATen möchtest kannst du dort Komma getrennt auch mehrere IP Netze angeben.

Es ist natürlich lästig das NAT Kommando nach jedem Reboot neu in den RasPi einzugeben und das muss man natürlich auch nicht, denn die NAT Regel kannst du an die bestehende nftables Default Konfig Datei unter /etc/nftables.conf anhängen, was dann so aussieht:

root@zeropi:/home/# cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
                type filter hook input priority 0;
        }
        chain forward {
                type filter hook forward priority 0;
        }
        chain output {
                type filter hook output priority 0;
        }
}
# hier kommt die NAT Regel dran
table ip nat {
        # Lokales LAN definieren
        define NAT_NETS = {
        192.168.1.0/24
        }
        # NAT fuer lokales LAN auf USB Tethering Port
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                ip saddr $NAT_NETS oif usb0 masquerade
        }
} 

Fertisch...
Mit systemctl restart nftables startest du den nftables Daemon neu der dann die Konfig neu einlist. Mit dem oben genannten nft list ruleset kannst du checken ob das Masquerading aktiv ist.
Sollte dein RasPi nftables nicht automatisch aktivieren beim Booten kannst du das mit systemctl enable nftables aktivieren.

Ein tcpdump -i usb0 -n icmp (apt install tcpdump) würde dir dann z.B. die Ping Pakete anzeigen und die IP Adressierung um zu checken das NAT aktiv ist. (<ctrly c> stoppt tcpdump wieder}
Ein nft flush ruleset würde das NAT wieder komplett löschen.
Du kannst auch ein Ping mit der dedizierten eth0 Absender IP senden um das NAT zu checken. Das geht mit ping -I <eth0_ip_addresse> 8.8.8.8 So kannst du sehen ob dein NAT greift. Ist das alles OK, dann routet dein RasPi nun auch deine lokalen IP Pakete aus dem LAN via Tethering! 😉

Einen (leicht lösbaren) Wermutstropfen gibt es aber noch und das ist DNS. ☹️
Wie du siehst pingst du oben ja nackte IPs um DNS erstmal aus dem Wege zu gehen.
Auf deinem RasPi selber wird natürlich auch ping www.heise.de klappen, weil der RasPi ja seinen DNS Server (die Smartphone IP) immer dynamisch über das USB Tethering Kabel bekommt, was du auf dem RasPi selber ja auch mit nslookup und dig selber checken kannst. (Siehe oben)

Anders sieht es aber mit Endgeräten im LAN aus die über den RasPi "Notrouter" geroutet werden, die müssen ja auch einen erreichbaren DNS Server befragen können um Hostnamen wie "www.heise.de" in einen gültige IP auflösen zu können... Das Internet kennt bekanntlich keine Namen sondern rein nur IP Adressen.

Ein nackter RasPi ist ja erstmal kein DNS Server, sprich er antwortet also nicht auf DNS Anfragen die ggf. andere Geräte an ihn richten wenn du dort seine IP als DNS Server einstellst oder per DHCP an diese Endgeräte gibst. Wie kann er auch antworten wenn er kein DNS Server ist?!
Du musst also erstmal etwas anderes als DNS Server nutzen um auch Hostnamen von LAN Endgeräten auflösen zu können. Die FritzBox zu nehmen geht zwar ist aber keine gute Idee, denn wenn die weg ist ist ja damit logischerweise auch der DNS Server weg und die Namensauflösung scheitert. Genau das was du ja verhindern willst!

Es gibt dafür 3 sehr simple Lösungen:

Das Einfachste ist die IP deines Tethering Smartphones als DNS Server oder besser zusätzlichen DNS Server im DHCP zu setzen. Damit fragen die Endgeräte dann das Smartphone was als USB Tethering auch als Caching DNS Server arbeitet und auf DNS Anfragen antwortet.
Alternativ kannst du deinen RasPi auch zum DNS (Caching) Server machen mit dem dnsmasq. Dann antwortet auch dein RasPi auf an ihn gerichtete DNS Anfragen und fragt von sich aus dann wiederum das Tethering Smartphone.

Es gibt Tausende Threads im Internet zur Einrichtung des einfachen dnsmasq DNS Servers wie z.B. hier wenn man danach sucht.

3te Alternative ist dein NAS als lokalen DNS Server laufen zu lassen sofern es eine DNS App supportet wie z.B. QNAP oder Synology. Wäre ideal, weil es ja schon DHCP Server ist. Damit kann man dann lokale Namen auflösen und gibt als Weiterleitungs DNS 2 IP Adressen an. Du ahnst es schon... Einmal deine FritzBox und einmal das Tethering Smartphone. Scheitert die DNS Weiterleitung an die erste IP (Fritz) nimmt das NAS DNS dann automatisch den 2ten DNS (Tethering Phone).

Mit einer dieser 3 Lösungsansätze sollte dein RasPi "Notrouter" dann problemlos laufen. 😉
Diese DNS und Gateway ToDos gelten im Übrigen auch wenn du statt des RasPis einen anderen Router verwendest wie z.B. Mikrotik, GL.inet usw.

OK. Die kurze Antwort, damit zeitnah eine kommt: werde ich genau so versuchen. Danke für den ganzen Aufwand! Das muss ich dann erstmal alles "nachspielen" und gebe Bescheid.

Cheers,
Udo