[Erledigt] Zwei Netzwerke einfach miteinander verbinden.

[PeterPawn]

iptables -t nat -I POSTROUTING 3 -o eth1 -j SNAT --to-source 192.168.0.1:80
iptables -t nat -I POSTROUTING 4 -o eth1 -j SNAT --to-source 192.168.0.1:443

Auch wenn der Urheber dieser Vorschläge mich offenbar ignoriert (vielleicht stehe ich in seiner Ignore-Liste, aber zumindest hat er ja das Masquerading anstelle von "plain routing" aus #7 aufgegriffen in #9), habe ich dennoch einfach mal selbst probiert, was denn wohl passiert, wenn man die vorgeschlagenen Kommandos (die mir sehr "suspekt" erscheinen aus meiner eigenen Erfahrung) ausführen will:

vidar:~ # id
uid=0(root) gid=0(root) groups=0(root)
vidar:~ # iptables -t nat -I POSTROUTING 1 -o eth0 -j SNAT --to-source 192.168.0.1:80
iptables v1.8.11 (legacy): Need TCP, UDP, SCTP or DCCP with port specification
Try `iptables -h' or 'iptables --help' for more information.
vidar:~ #

Man beachte, daß ich dabei durchaus der User root bin, es also auch ohne sudo nicht an mangelnden Rechten scheitert. Auch die eingesetzte Version ist - nach der Website des Projekts: https://www.netfilter.org/projects/iptables/downloads.html - die aktuelle, es scheitert also auch nicht an veralteter Software.

Was mache ich denn dann falsch? Hat vielleicht die man-Page für die SNAT-Extension doch recht und die Angabe von Ports ist an die Angabe eines (diese Ports auch benutzenden) Protokolls gebunden?

vidar:~ # man iptables-extensions | sed -n -e "/SNAT$/,+6p"
   SNAT
       This target is only valid in the nat table, in the POSTROUTING and INPUT chains, and user-defined chains which are only called from those chains.
       It specifies that the source address of the packet should be modified (and all future packets in this connection will also be mangled),
       and rules should cease being examined.  It takes the following options:

       --to-source [ipaddr[-ipaddr]][:port[-port]]
              which  can specify a single new source IP address, an inclusive range of IP addresses.
              Optionally a port range, if the rule also specifies one of the following protocols: tcp, udp, dccp or sctp.
              If no port range is specified, then source ports below 512 will be mapped to other ports below 512: those
              between 512 and 1023 inclusive will be mapped to ports below 1024, and other ports will be mapped to
              1024 or above. Where possible, no port alteration will occur.
vidar:~ #

Aber nehmen wir mal an, die Angabe von -p tcp wurde nur versehentlich vergessen (TCP wäre für das Webinterface des ZTE-Routers ja ausreichend).

Was bewirkt diese Regel denn dann, wenn sie für das Interface eth1 mit der IP-Adresse 192.168.0.133 zur Anwendung kommen sollte und der von eth0 aus zu routende Traffic seinerseits das Ziel 192.168.0.1 adressiert? Es würde die Quell-Adresse im IP-Paket ("source address", das sind 4 Byte ab Offset 12 im IP-Header: https://en.wikipedia.org/wiki/IPv4#Header) durch die angegebene Adresse ersetzt (und meinetwegen auch noch die (Quell-)Portnummer), womit das Paket dann (angenommen es ist unverschlüsselter HTTP-Traffic auf TCP-Port 80 an die IP-Adresse 192.168.0.1) in BEIDEN Adressfeldern im IP-Header identische Angaben enthält und der arme Router würde jetzt - wenn das Paket ihn erreicht und er es verarbeitet, sprich sein SYN-Paket als Antwort senden will - seinerseits versuchen, eine Antwort an seine eigene IP-Adresse auf dem Standard-Port für HTTP zu senden.

Nun ist ein SNAT-Target ja glücklicherweise ein "finales", d.h. die Verarbeitung weiterer Regeln wird abgebrochen (grün markiert in der o.a. man-Page) - die zweite Regel käme so also niemals wirklich zur Ausführung.

Auch die anderen beiden Vorschläge:

iptables -t nat -I POSTROUTING 1 -o eth0 -j SNAT --to-source 192.168.0.1:80
iptables -t nat -I POSTROUTING 2 -o eth0 -j SNAT --to-source 192.168.0.1:443

ergeben - abseits der Syntax-Fehler, egal ob mit oder ohne Protokoll-Angabe bzw. Portnummern - für mich keinen Sinn, auch wenn sie wohl nicht länger "erforderlich" sein sollen:

Teste auch ohne source-NAT für das eth0-Interface auf deinem PI (... d. h. source-NAT nur für das eth1-Interface des PI).

Wenn hier tatsächlich nur HTTP- oder HTTPS-Traffic von und zur 192.168.0.1 "geroutet" werden soll (mit Masquerading, denn auch SNAT ist ja (statisches) Masquerading), dann hätten die auf eth0 ausgegebenen Pakete, die ihren Ursprung beim ZTE-Router haben, ja bereits die Absender-Adresse 192.168.0.1 und eine der beiden (Absender-)Portnummern (80 bei HTTP, 443 bei HTTPS), denn der Router antwortet in aller Regel mit Paketen von demselben Endpunkt (das ist die Kombination aus IP-Adresse und Portnummer), an den auch die Anfragen gerichtet waren (sonst hätte der Client ja auch Probleme, die passende Verbindung für ein Paket zu finden). Für solche Pakete würden die o.a. Regeln also (gesetzt den Fall, sie wären irgendwie syntaktisch richtig eingegeben, was machbar ist, wenn man etwas ergänzt oder wegläßt) ebenfalls gar nichts bewirken, da nur die bereits vorhandenen Angaben mit denselben Daten noch einmal überschrieben würden.

Für alle anderen Datenpakete (if any, auch wenn's hier nicht Teil der Aufgabenstellung war), die aus dem Netz 192.168.0.0/24 über den RasPi an das Netz 192.168.178.0/24 gehen sollen, wären diese Regeln aber absolutes Gift, denn ich kann da keinerlei "Filterbedingungen" sehen, mit denen diese Aktionen auf irgendwelchen bestimmten(!) Traffic beschränkt würden - im Ergebnis wird selbst bei jedem ICMP-Paket, das über den RasPi geroutet werden soll (wenn man sich nicht doch zur zusätzlichen(!) Angabe von -p tcp entscheiden sollte, was es dann zumindest auf TCP-Pakete beschränken würde, aber auch die kriegen dann gnadenlos immer die angegebene Portnummer als Absender aufs Auge gedrückt), die Absender-Adresse ausgetauscht und das wird wohl eher nicht der "gewünschte" Effekt sein.

Bei einem MASQUERADE-Target wird automatisch die IP-Adresse des ausgehenden Interfaces (hier also eth1 auf dem RasPi) als Absender-Adresse im Paket eingetragen (die Suche danach kostet (ein wenig) zusätzliche Zeit und beschränkt den möglichen Durchsatz), womit das Ziel dann auch weiß, wohin es ein Antwort-Paket senden soll. Bei einem SNAT-Target wird aber mit der Angabe von --to-source (eigentlich auch nicht wirklich mißverständlich benannt) nicht angegeben, WOHIN das Paket gesendet werden soll (und ggf. noch an welchen Port), sondern WIE das Datenpaket in den Absender-Angaben ("source address - and optionally port number") manipuliert werden soll, bevor es an den Hardware-Treiber zur Ausgabe geht.

da werde ich das mal, morgen oder übermorgen, mit den anderen Regeln testen.

Es würde mich also (erneut) schwer verwundern, wenn mit den angegebenen Kommandos noch IRGENDETWAS über den RasPi geroutet werden könnte - selbst wenn man die Syntax-Fehler in den Kommandos ausmerzt.

Aber ich wurde ja schon einmal überrascht - zum Event-Log von Deinem Test heute vormittag hätte ich noch die Nachfrage, ob da um 10:12 Uhr schon wieder die "primäre" Verbindung aktiviert wurde. Wenn ja, was genau hast Du denn in der Zeit (knapp 4 Minuten), wo die Ersatzverbindung aktiv war, alles getestet - außer die Support-Daten von der FRITZ!Box gezogen?

Ich habe jetzt leider zu lange für diesen Beitrag gebraucht und mir läuft gerade etwas die Zeit weg - ich sehe mir die bereitgestellten Support-Daten (danke dafür) aber noch an (EDIT: heruntergeladen habe ich sie schon), wenn ich die Zeit dafür habe. Mich interessiert schon sehr, was jetzt mit dem Routing passiert bzw. was genau sich ändert, wenn die Ersatzverbindung aktiviert wird. So weit ich das verfolgt habe, hat das noch niemand untersucht (oder es zumindest noch nicht - hier - beschrieben/erklärt).

 

[BenaresNeu]

Öhm, vielleicht kann ich ja auch mal was dazu beitragen:

Ich hatte mir vor länger Zeit mal einen 1€-vServer zugelegt, weil bei mir in hoffentlich nicht all zu ferner Zukunft ein Glasfaser-Ausbau ansteht und meine öffentlich erreichbare IPv4 wohl dann flachfällt (DS-Lite). Ich wollte versuchen, den vServer mit Wireguard über IPv6 zu verbinden zu meiner Fritzbox verbinden und dann den IPv4-Verkehr darüber zu tunneln. der vServer ha eine fest IPv4 und IPv6. In meine wg0.conf auf dem vServer habe ich damals folgenden Abschnitt hinzugenommen:

...
# port forwarding (added 15.01.2024)
PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.71:80
PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.71:443
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.71:80
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.71:443

# packet masquerading (added 15.01.2024)
PreUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
...

Das hatte ich mir irgendwoher ergoogelt. Das hat zumindest zu der WebStation auf meiner DS funktioniert. Mit http://<vServer-IPv4>) komme ich auf die Demo-Seite der WebStation. Der Tunnel wird definitiv vom vServer über IPv6 aufgebaut.

Edit: Die Wireguard-Kopplung ist übrigens eine Host-Kopplung, keine Netz-Kopplung. Der vServer (wg0) bekommt über den Tunnel die IP 192.168.0.205 (und eine FD58:... IPv6). Vom Server selbst aus, geht alles mögliche (ping ...), aber von extern, über den vServer nur Port 80 und 443.

Vielleicht hilft euch das etwas.

 

[3PO]

@PeterPawn,

schön, daß du dir die Zeit genommen hast um alles so ausführlich zu erklären, leider aber bin ich nicht so tief in networking involviert, daß ich das jetzt alles verstanden hätte.
Vielleicht könntest du ja, der Einfachheit halber, mir kurz das posten, was ich am RPi einstellen soll?
Copy/Paste beherrsche ich nämlich perfekt.

In der Zeit, in der der Fallback aktiv war habe ich einfach nur einen Videostream aus dem Internet auf dem TV laufen lassen und ein paar Seiten im Internet aufgerufen.
Hätte ich denn mehr tun sollen, und falls ja, was?

 

[PeterPawn]

PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.71:80
PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.0.71:443

DAS macht ja auch wieder Sinn (auch wenn es gerade das "Gegenteil" von SNAT ist), denn hier wird eben nur TCP-Traffic (-p tcp), der an den Port 80 gehen soll (--dport 80) und auf der (öffentlichen) IP(v4)-Adresse des vServers am Interface eth0 eingeht (-i eth0), an die angegebene Adresse (und damit über den WireGuard®-Tunnel zur FRITZ!Box) weitergeleitet (die wird natürlich auch ins Paket geschrieben als Ziel-Adresse) - die Angabe der Portnummer in --to-destination wäre hier aber auch unnötig, denn da wird nur Port 80 wieder mit Port 80 ersetzt (oder eben 443 bei HTTPS). Im PostDown werden dann die Regeln wieder entfernt, wenn das Interface deaktiviert wurde.

Das gilt auch für das SNAT (selbst wenn hier ein MASQUERADE-Target verwendet wird, das ist nur ein "Sonderfall" von SNAT für Interfaces mit dynamischen Adressen) - im PreUp wird der Eintrag erzeugt und im PostDown wieder entfernt ... auch wieder, wenn sich der Zustand des wg0-Interfaces ändert.

Hier wird aber ebenfalls nur auf einem Interface SNAT gemacht ... nur die auf wg0 an die FRITZ!Box ausgegebenen Pakete gehen ins POSTROUTING (und sehen damit für die FRITZ!Box so aus, als kämen sie vom entfernten WireGuard®-Peer und nicht von irgendwo direkt aus dem Internet) und nicht die auf eth0 ausgegebenen(!).

---

EDIT: @3PO:
Ich rate einfach mal, daß dabei nur IPv6 verwendet wurde, was von der zusätzlichen IPv4-Route naturgemäß nicht beeinflußt wird. Um zu ermitteln, ob auch IPv4 über die Ersatzverbindung funktioniert (noch längst nicht alle Server haben auch eine IPv6-Konfiguration), müßte man schon einen Dienst im Internet ansprechen, der auch bzw. nur IPv4 benutzt ... entweder indem man vorher einen passenden Domain-Namen ermittelt und den dann benutzt oder indem man ihn gleich direkt mit der IPv4-Adresse anspricht, wenn man nicht mal testweise auf einem Client gleich die ganze IPv6-Unterstützung deaktivieren kann.

EDIT2:
Man kann das natürlich auch ganz simpel mit einem ping-Kommando an eine (externe) IPv4-Adresse testen - es muß nicht unbedingt ein (TCP-basierter) Dienst bzw. Server im Internet sein. Das sollte mit der primären UND mit der Ersatzverbindung funktionieren.

EDIT3:
Ich habe gerade mal nach "IPv4-only"-Servern im Internet gesucht - einer dürfte github.com sein. Den kriegt man also nur über den AFTR, wenn man einen DS-Lite-Anschluß hat (wie Du wohl mit dem bei 1&1) und wenn die FRITZ!Box nicht das DS-Lite-Schema beibehält (solange sie auch auf der Ersatzverbindung einen AFTR-Server angeboten bekommt, was ich irgendwie auch wieder nicht glaube, denn das Kapseln von IPv4-Traffic macht dann ja der ZTE-Router), dann sollte das auch über die Ersatzverbindung klappen, dort die Webseiten aufzurufen. Wenn nicht, gibt es ein Problem mit dem IPv4-Routing, wenn das WAN-Interface der FRITZ!Box vom Edge-Router eine IPv4-Adresse bekommt - mit einem traceroute kann man dann auch versuchen, den Weg der IP-Pakete durch die eigenen Router zu verfolgen.

 

[3PO]

@PeterPawn,

Ich werde kommende Woche, wenn ich wieder bei mir zuhause bin das mal testen, da habe ich dann auch ein paar Rechner mit Linux und einen DSL Anschluß von der Telekom.

Allerdings wäre es sehr hilfreich, wenn du mir deine empfohlenen Settings für den RPi mitteilen könntest.

Vielen Dank im voraus.

 

[PeterPawn]

Wenn ICH das lösen sollte, würde ich ganz anders an die Sache herangehen (ich hatte auch in #7 nur auf den Vorschlag mit der statischen Route in der FRITZ!Box reagiert).

Wenn da ohnehin ein zweites Gateway eingebaut wird (egal ob RasPi oder die kleine Banane), kann man dort auch gleich einen "reverse proxy" installieren und die Web-Oberfläche des ZTE-Routers über diesen ansprechen. Dann braucht es gar keine statische Route auf der FRITZ!Box, denn dann gibt man eben eine Adresse (ggf. mit Portnummer, wenn Port 80 anderweitig benötigt wird) für ebendiesen Proxy im Browser ein (also die IP-Adresse des eth0 vom RasPi).

Welche Software ich dafür nehmen würde, hängt u.a. auch davon ab, was das genau für ein zusätzliches Gateway ist und ob da z.B. ein ausgewachsener Apache-Server überhaupt verwendet werden kann (der wäre meine erste Wahl). Aber es gibt durchaus genug Alternativen (andere mögen z.B. den nginx-Server mehr) - einfach mal mit dem Stichwort "reverse proxy" im Internet suchen.

 

[3PO]

@PeterPawn,

Wenn ich das richtig verstanden habe, brauche für mein Vorhaben das ganze Routing Gedöns garnicht, sondern "nur" einen Reverse-Proxy mit nginx?

Ich habe mal ein wenig gegoogelt und ich denke mal, daß ich das hinbekommen werde.

Das Forwarding muß aber nach wie vor, enabled werden, oder?

 

[PeterPawn]

Eigentlich nicht - wenn auf dem Gateway Daten aus zwei unterschiedlichen Netzwerk-Interfaces verarbeitet werden und die sollen NICHT zwischen diesen Interfaces geroutet werden, dann teilt sich die Verarbeitung in zwei Teilschritte auf.

Die (eingehende) Verbindung zum Proxy-Server wird von diesem als "input" behandelt und der (vom Proxy-Server ausgehende) Verkehr zum ZTE-Router als "output" (bzw. eben umgekehrt bei den Antwort-Paketen). Dabei werden tatsächlich KEINE kompletten IP-Pakete zwischen den Interfaces bewegt (und folglich erfolgt auch kein "forwarding"), sondern es wird jeweils nur die "Nutzlast" der HTTP-Pakete genommen und - je nach Richtung, in die sie gehen sollen - in passende (neue) IP-Pakete gesteckt.

Ich weiß ja nicht genau, warum Du jetzt eine neue Banane anschaffen willst - sollte es sein, weil der RasPi nur ein Ethernet-Interface hat (und nicht nur der Preisunterschied, wobei ja nicht bekannt ist, was für einen RasPi Du da im Moment dran hast - aber vermutlich ist das zweite Ethernet-Interface ja ein USB-Adapter o.ä.) … man kann natürlich auch das Ethernet-Interface mit dem MC888 verbinden und den RasPi (sofern er ein integriertes WLAN-Interface hat) sein eigenes WLAN aufspannen lassen.

Dann muß man sich eben, wenn man etwas vom ZTE-Router will, mit diesem WLAN verbinden … was sicherlich auch kein Problem ist, wenn da nicht permanent(!) irgendetwas ausgelesen werden soll (oder irgendetwas automatisiert werden soll, wobei selbst das ja machbar wäre, z.B. mit Automate: https://llamalab.com/automate/ sogar auf einem Android-Tablet).

Es MUSS also nicht zwangsläufig (zumindest nicht wegen der Schnittstellen) ein neues "Router-Board" sein, wobei die Teile schon echt billig sind in China und ein teuer in D bezogener RasPi mit großem RAM vermutlich auch mir zu schade wäre für diese Aufgaben.

 

[3PO]

Hat jetzt etwas gedauert, da ich anderweitig beschäftigt war....

Ich habe das nun, wie von @PeterPawn vorgeschlagen, mit einem Reverse-Proxy mit nginx gelöst.

Ich weiß jetzt nicht, ob es ein Seiteneffekt von meiner Konfiguration mit IPTables war, aber auf einmal ging mein VPN mit Wireguard nicht mehr.

Ich habe den RPi komplett neu aufgesetzt und und die statische Route in der FB gelöscht.

Genaugenommen ist der Topic ja nun falsch, denn es werden ja keine zwei Netzwerke miteinander verbunden, sondern nur eine Website umgeleitet, aber das ist ja genau das, was ich benötige.

Der Vollständigkeit halber hier noch die Config für nginx:

upstream targetServer {
    server 192.168.0.1:443;
}

server {
    listen 80;
    server_name 192.168.178.133;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    server_name 192.168.178.133;

    ssl_certificate /etc/ssl/certs/myRoot.pem;
    ssl_certificate_key /etc/ssl/private/myRoot.key;


    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass_request_headers on;
        proxy_http_version 1.1;
        proxy_pass https://targetServer;
    }
}

 

[PeterPawn]

Genaugenommen ist der Topic ja nun falsch

Den kann der TO (thread opener) aber jederzeit anpassen, einfach auf Seite 1 gehen.

Andererseits ist der größte Teil des Threads ja immer noch "Netzwerk-Theorie" mit Routing und NAT - da passen dann nach einer (zu einfachen) Änderung die anderen Beiträge nicht mehr. Vielleicht also doch besser so lassen ...

 

[3PO]

Ich weiß ja nicht genau, warum Du jetzt eine neue Banane anschaffen willst - sollte es sein, weil der RasPi nur ein Ethernet-Interface hat (und nicht nur der Preisunterschied, wobei ja nicht bekannt ist, was für einen RasPi Du da im Moment dran hast - aber vermutlich ist das zweite Ethernet-Interface ja ein USB-Adapter o.ä.) … man kann natürlich auch das Ethernet-Interface mit dem MC888 verbinden und den RasPi (sofern er ein integriertes WLAN-Interface hat) sein eigenes WLAN aufspannen lassen.

Es ist ein Raspberry Pi 3.
Das Problem bei dem ist, daß er mit angeschlossenem USB2Ethernet Adapter nicht mehr von USB bootet. Ich habe alle meine Raspberrys auf Booten von USB umgestellt, da ich schon einige SD-Karten hatte, die nach einiger Zeit einfach nicht mehr funktioniert haben. Deshalb habe ich auf SSDs oder NAND-Flash Drives umgestellt.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Dann muß man sich eben, wenn man etwas vom ZTE-Router will, mit diesem WLAN verbinden … was sicherlich auch kein Problem ist, wenn da nicht permanent(!) irgendetwas ausgelesen werden soll (oder irgendetwas automatisiert werden soll, wobei selbst das ja machbar wäre, z.B. mit Automate: https://llamalab.com/automate/ sogar auf einem Android-Tablet).

Sicherlich wäre dad auch eine Lösung, aber wie ich schon weiter vorne geschrieben hatte, liegt der Pi bei mir unterm Dach und da ist die Verbindung via WLAN sehr bescheiden.

 

[PeterPawn]

Ich kann mich weiter vorne nur daran erinnern, daß der MC888 irgendwo zu weit weg sein sollte für WLAN. Muß denn der RasPi auch dort sein? Sicherlich wird es ja eine Kabelverbindung dahin geben, wohl auch mit einem Switch. Läßt sich der nicht anders/günstiger platzieren?

Ich habe beim Nachlesen gerade gesehen, daß da etwas von einem OrangePi (RISC-basiert) und nicht von einem BananaPi (ARM-basiert) stand/steht - geändert (wg. notwendiger Verkleinerung des Bildes nicht mehr zu erkennen) oder doch eine Leseschwäche meinerseits?

 

[3PO]

Der 5G Router steht deshalb unterm Dach, weil dort der 5G Empfang einfach am besten ist.

Ich bin allerdings weg vom Orange Pi und habe mir beim Aliexpress 2 Stück NanoPi R2S Plus bestellt.

R2S Plus

www.friendlyelec.com

 

[PeterPawn]

Das verstehe ich ja ... aber warum steht/liegt der Einplatinen-Rechner mit dem zusätzlichen Gateway auch unter (oder gar auf?) dem Dach? Irgendwie muß es ja ein Kabel dahin geben und da muß auch noch irgendwo ein Switch sein, wenn zwei Geräte mit dem MC888 verbunden werden (wenn es nicht ZWEI Kabel sind) - entweder unterm Dach, wo dann MC888 und RasPi angeschlossen sind oder eben weiter unten, wo dann die FRITZ!Box angeschlossen ist und der RasPi ja ebenfalls ans Kabel könnte. Oder warum funktioniert DAS nicht, welche baulichen Besonderheiten gibt es denn sonst noch? Hat der RasPi so weit oben noch andere Aufgaben?

[OT]
Ich hatte letztens auch in China nachgeschaut (übers Internet natürlich nur) und dabei den NanoPi2 Zero entdeckt. Allerdings wurde es dann mit den ganzen notwendigen Optionen (M.2-WLAN, Case, USB-Netzteil) schon wieder preislich unattraktiver, vor allem dann, wenn noch die ganzen Abgaben dazu kommen.

Die (EUR-)Preise für ein NanoPi R2S Plus-Bundle bei AliExpress sind auch nicht wirklich geringer - rechnet man alles zusammen, kommt man fast auf dieselben wie bei Amazon … mit weniger Risiken und vergleichbaren Lieferzeiten (gut, vielleicht eine Woche früher). Alles nicht mehr so attraktiv - außer die Speicherpreise steigen immer weiter und man will einen "experimentellen" RasPi5 mit viel RAM durch so ein billigeres Teil (mit 1 GB auf dem Board) ersetzen (ein RasPi5 mit 16 GB RAM ist inzwischen bei 150 EUR angekommen).

 

[3PO]

Das verstehe ich ja ... aber warum steht/liegt der Einplatinen-Rechner mit dem zusätzlichen Gateway auch unter (oder gar auf?) dem Dach? Irgendwie muß es ja ein Kabel dahin geben und da muß auch noch irgendwo ein Switch sein, wenn zwei Geräte mit dem MC888 verbunden werden (wenn es nicht ZWEI Kabel sind) - entweder unterm Dach, wo dann MC888 und RasPi angeschlossen sind oder eben weiter unten, wo dann die FRITZ!Box angeschlossen ist und der RasPi ja ebenfalls ans Kabel könnte. Oder warum funktioniert DAS nicht, welche baulichen Besonderheiten gibt es denn sonst noch? Hat der RasPi so weit oben noch andere Aufgaben?

Es geht eine Glasfaserleitung vom Keller bis in die Bühne, damit sind 2 Level 3 Switches von HP miteinander verbunden und es geht noch eine extra Cat.7 Leitung in den Keller.
Mir der Kupferleitung ist der MC888 direkt mit der FB verbunden. Der MC888 hat 2 LAN Ports, der 2te Port ist derzeit mit RPi via USB2Ethernet Adapter verbunden und die Ethernetschnittstelle der RPi ist mit dem Switch verbunden. Der Switch im Keller ist mit der FB verbunden.

 

[PeterPawn]

Ich verstehe es halt immer noch nicht (jedenfalls nicht richtig) - wenn da ein Kupferkabel von der FRITZ!Box zum MC888 geht, dann können darüber doch auch die Daten zwischen RasPi und MC888 gehen, weil das dem MC888 auch egal sein dürfte, wenn die Ersatzverbindung UND der RasPi über denselben Port bei ihm angebunden sind.

Dann noch einen "dummen" 5-Port-GbE-Switch (unten!) an das Kupferkabel, was zur FRITZ!Box geht (kostet max. 20 EUR und dann wäre es schon ein teurer, gibt es ab ca. 7 EUR) und der RasPi und die FRITZ!Box können beide (EDIT: über ein einziges Ethernet-Kabel) mit dem ZTE-Router kommunizieren - Durchsatz dürfte (jenseits von 100 MBit/s bei FE) da auch kein Thema sein. Die FRITZ!Box wird vermutlich einfach auf die Ersatzverbindung umschalten, indem sie ihren Ethernet-Port entsprechend aktiviert bzw. wieder deaktiviert (einfach vorher testen) - damit wäre der zweite Port am Switch ohnehin "down", solange die Ersatzverbindung nicht zugeschaltet werden soll. Am Ende stecken da drei Kabel im Switch - 1x FRITZ!Box, 1x RasPi, 1x Kabel unters Dach.

Und der RasPi könnte an einen Standort (in Kabel-Reichweite zum neuen Switch) wandern, wo er per WLAN erreichbar ist, womit auch der USB-Adapter für den zweiten Port, der das Booten beeinträchtigt, entfernt werden könnte UND der RasPi könnte mit seinem (integrierten) WLAN-Interface sogar wieder an der FRITZ!Box andocken, womit der Zugriff auf den Reverse-Proxy aus dem Netz 192.168.178.0/24 auch wieder funktioniert, was das Verbinden mit einem eigenen WLAN, das vom RasPi aufgespannt wird (wie ich weiter oben mal angedacht hatte), auch wieder überflüssig macht.

Es mag zwar komisch anmuten, wenn ich da so drauf herumreite - aber manchmal sieht man selbst den Wald vor lauter Bäumen nicht, wenn man sich erst mal auf eine Lösung "festgelegt" hat. Aber vielleicht habe ich ja tatsächlich etwas sehr Wichtiges nicht verstanden, siehe erster Absatz … was übersehe ich?

 

[3PO]

AVM sagt, daß nichts(!) zwischem der FB und dem zweiten Gateway hängen darf:



Bild(er) als Vorschaubild(er) (siehe https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ ) eingebunden by stoney