[Erledigt] Zwei Netzwerke einfach miteinander verbinden.

[3PO]

Hallo Zusammen,

Ich habe eine FB 7590 AX mit FW 8.20, da ja die Funktion "Ausfallsicherheit" mitbringt. Ich habe nun einen 5G Router (ZTE MC888) an LAN1 angeschlossen und entsprechend konfiguriert.
Das Ganze funktioniert soweit einwandfrei und sehr zuverlässig. Der 5G Router muß sich aber in einem anderen Netzwerkbereich befinden als die FB, was zur Folge hat, daß er natürlich in meinem LAN nicht erreichbar ist, was ärgerlich ist, da ich dann nicht an das Webinterface komme.

Meine Idee wäre nun, einen Raspberry pi mit 2 Ethernetschittstellen und zwischen den beiden Netzwerken zu "routen". Das "normale" LAN ist beim mir 192.192.168.177.0 und das des 5G Routers 192.168.0.0. Der Router hat 2 LAN Ports.

Es würde auch reichen, wenn die Verbindung nur in eine Richtung gehen würde, da sich in dem Netzwerk des 5G Routers sonst kein weiterer Teilnehmer befindet.

Die Frage ist nun, ob dies, was ich vorhabe, überhaupt so einfach möglich ist und falls ja, welche Einstellungen auf der FB und auf dem Renchner gemacht werden müssen.

 

[tango501]

welche Einstellungen auf der FB und auf dem Renchner gemacht werden müssen

Warum wird da nicht einfach eine zweite Netzwerkkarte in den Rechner eingebaut? Es gibt da aber auch externe Lösungen via USB.

 

[3PO]

Ja, genau so habe ich es ja. Meine Frage bezieht sich auf die Konfiguration.

 

[tango501]

Es gibt dazu ein schönes Erklärvideo "Netzwerke mit Filius – Teil 4: Zwei unterschiedliche Netzwerke miteinander verbinden"

 

[3PO]

Die Ethernetschnittstellen sind wie folgt konfiguriert:

root@RPI:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.133  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 fe80::c3a8:2205:4bd0:4375  prefixlen 64  scopeid 0x20<link>
        inet6 2001:9e8:b023:5f00:6280:958c:61c9:6e8d  prefixlen 64  scopeid 0x0<global>
        inet6 fd6f:c93:c2a9:0:d1da:5e95:305e:c9a4  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:27:ba:13  txqueuelen 1000  (Ethernet)
        RX packets 9000  bytes 1744491 (1.6 MiB)
        RX errors 0  dropped 1116  overruns 0  frame 0
        TX packets 320  bytes 49568 (48.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.133  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::4a3:1337:743c:854a  prefixlen 64  scopeid 0x20<link>
        inet6 2a00:fbc:f325:acd6:5747:fd47:9e14:946f  prefixlen 64  scopeid 0x0<global>
        ether c8:a3:62:53:55:cb  txqueuelen 1000  (Ethernet)
        RX packets 354  bytes 33136 (32.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 541  bytes 60095 (58.6 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 17  bytes 2608 (2.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17  bytes 2608 (2.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
root@RPI:~#

Forwarding ist auch eingestellt:

root@RPI:~# cat /etc/sysctl.conf
net.ipv4.ip_forward=1
root@RPI:~#

Und die Routen sind auch gesetzt:

root@RPI:~# ip route list
default via 192.168.178.1 dev eth0 proto static metric 100
default via 192.168.0.1 dev eth1 proto static metric 101
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.133 metric 101
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.133 metric 100
root@RPI:~#

Leider aber funktioniert es nicht.....

Was habe ich vergessen, oder falsch gemacht?

 

[klp55tsch]

Ich habe eine FB 7590 AX mit FW 8.20, da ja die Funktion "Ausfallsicherheit" mitbringt. Ich habe nun einen 5G Router (ZTE MC888) an LAN1 angeschlossen und entsprechend konfiguriert.
Das Ganze funktioniert soweit einwandfrei und sehr zuverlässig. Der 5G Router muß sich aber in einem anderen Netzwerkbereich befinden als die FB, was zur Folge hat, daß er natürlich in meinem LAN nicht erreichbar ist, was ärgerlich ist, da ich dann nicht an das Webinterface komme.

Du könntest in deinem Router (FB 7590) eine statische Route in das Subnetz 192.168.0.0/24 mit der IP-Adresse 192.168.178.133 (... dein PI an der FB) als gateway, konfigurieren.
Wie sind z. Zt. auf deinem PI, die Ausgaben von:

sudo arping -c 3 -I eth0 -s 192.168.178.133 192.168.0.133
/usr/sbin/sysctl net.ipv4.conf.eth0.arp_filter net.ipv4.conf.eth1.arp_filter

?

 

[PeterPawn]

Solange der ZTE-Router nicht ebenfalls weiß, daß er Traffic für das Netz 192.168.178.0/24 an den RasPi schicken soll/muß (wenn tatsächlich nur geroutet wird), kommt da eher kein Antwort-Paket vom (ZTE-)Router zurück. Da es vermutlich auch nicht möglich sein wird, dem ZTE-Router weitere lokale Routen beizubringen (zumindest ist das nicht bei sehr vielen Mobilfunk-Routern problemlos möglich), wäre die beste Lösung hier Masquerading auf dem RasPi (solange sich das auf IPv4 beschränkt) - dann sehen die Pakete für den ZTE-Router so aus, als kämen sie von der IP-Adresse des RasPi (192.168.0.133) und dahin gehen dann auch die Antworten, die der RasPi wieder (nach dem Austausch der IP-Adressen im Paket) an den ursprünglichen Absender ausliefern kann.

EDIT: Allerdings könnte in der 7590 tatsächlich eine statische Route über den RasPi erforderlich sein - aber nur, wenn auch andere Geräte als der PC (den man für den Zugriff auf den ZTE-Router nutzen will) ebenfalls auf den ZTE-Router MÜSSEN … gibt es keine solchen Clients, stellt man besser nur auf dem PC eine lokale Route über den RasPi ein; das verhindert, daß unerwüschte Zugriffe auf den ZTE-Router (von weiteren Clients) erfolgen können (notfalls mit zusätzlicher Firewall auf dem RasPi noch weiter konfigurierbar).

 

[3PO]

root@RPI:~# arping -c 3 -I eth0 -s 192.168.178.133 192.168.0.133
ARPING 192.168.0.133 from 192.168.178.133 eth0
Sent 3 probes (3 broadcast(s))
Received 0 response(s)
root@RPI:~#

root@RPI:~# /usr/sbin/sysctl net.ipv4.conf.eth0.arp_filter net.ipv4.conf.eth1.arp_filter
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth1.arp_filter = 0
root@RPI:~#

Das mit der statischen Route hatte ich auch schon versucht, leider aber ohne Erfolg.

Eigentlich muß ich garnicht auf das gesamte Netzwerk des ZTE zugreifen können, mit reicht es völlig, wenn ich aus meinem LAN das Webinterface des ZTE erreichen kann. Es ist auch nicht notwendig von dem Netzwerk des ZTE auf mein LAN zuzugreifen.
Anders gesagt, ich muss nur die 192.168.0.1 aus meinem 192.168.177.0 erreichen können.

 

[klp55tsch]

Das mit der statischen Route hatte ich auch schon versucht, leider aber ohne Erfolg.

Anders gesagt, ich muss nur die 192.168.0.1 aus meinem 192.168.177.0 erreichen können.

Dann versuch mal zusätzlich zur statischen Route in der FB, mit:

sudo iptables -t nat -I POSTROUTING 1 -o eth0 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o eth1 -j MASQUERADE

auf deinem PI und dann auf dem PI mit:

sudo tcpdump -c 300 -vvveni eth1 icmp and dst host 192.168.0.1

Jetzt mach von einem Gerät an der FB (im Subnetz 192.168.178.0/24) einen Ping auf die IP-Adresse 192.168.0.1 und schau nach, ob Du beim tcpdump auf dem PI eine Ausgabe bekommst.
BTW: Du meinst 192.168.178.0 und nicht 192.168.177.0, oder?

 

[3PO]

Ja, es ist 192.168.178.0.

Leider aber gibt tcpdump nichts zurück und der Client, der pingt, sagt, dass es den Host nicht gibt.

 

[klp55tsch]

... der Client, der pingt, sagt, dass es den Host nicht gibt.

Hat der Client in seiner default route, die FB (mit der IP 192.168.178.1) als gateway?
Wenn ja, evtl. hast Du die statische Route in deiner FB nicht richtig konfiguriert. Hast Du evtl. (zusätzliche) Firewall-Regeln in deinem PI konfiguriert?

iptables -nvx -L
iptables -nvx -L -t nat
nft list ruleset

?

 

[3PO]

Der Client ist ein Android Tablet.

Ich wüsste nicht, daß ich irgendwelche Regeln konfiguriert hätte....

root@RPI:~# iptables -nvx -L
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
root@RPI:~#

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
root@RPI:~#

root@RPI:~# nft list ruleset
root@RPI:~#

 

[3PO]

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

 

[PeterPawn]

Wofür soll das Masquerading bei der Ausgabe(!) auf eth0 gut sein? Solange es keinen Verbindungsaufbau AUS 192.168.0.0/24 NACH 192.168.178.0/24 geben soll, wird das nicht benötigt.

Ja, es wird hier vermutlich sogar dazu führen, daß das Ganze nicht funktioniert (braucht man es wirklich, muß man etwas kompliziertere iptables-Regeln verwenden), wenn abschließend (-I POSTROUTING) bei allen auf eth0 ausgegebenen Paketen die Absender-Adresse des RasPi (auf eth0) eingetragen wird, da dann der ursprüngliche Absender das (auf dem Rückweg bereits zuvor schon anhand des "connection trackings" geänderte) Paket nicht der von ihm eigentlich gestarteten "Verbindung" (auch nicht bei "verbindungslosen" Protokollen wie UDP oder ICMP) zuordnen kann, wenn der Absender (im Antwort-Paket) nicht paßt.
EDIT 14.12.2025:
Das zuletzt "Vermutete" ist natürlich Kohl meinerseits (oder meinetwegen auch Unsinn, wenn man den zweiten Teil (ab: "connection tracking" geändert) nicht gnädigerweise ignoriert), denn wenn der netfilter-Code die Verbindung erst einmal in der Mangel hat (nicht so ganz ohne Witz nennt sich das ja "mangling"), dann werden auch die Antworten (für diese konkrete Verbindung, zwischen genau den zwei Endpunkten, die beim Verbindungsaufbau beteiligt waren) ohne weitere Konsultationen irgendwelcher Regeln (es sei denn, man konfiguriert es absichtlich anders, was ebenso möglich ist) genauso wieder durch die Mangel gedreht - das Handling der mangle-Table erfolgt vor den nat-Tables (PRE or POST).
ENDE EDIT

Außerdem würde ich noch prüfen, ob nf_conntrack auch geladen wurde (modprobe oder gleich conntrack, wenn die Tools installiert sein sollten: https://conntrack-tools.netfilter.org/manual.html#conntrack) - ohne funktioniert der Rückweg auch nicht.

 

[3PO]

nf_conntrack war nicht geladen und conntrack gibt es bei mir nicht.
Brauche ich denn die beiden Module?

Da ich ja nun schon schon so einiges "verbastelt" habe, werde ich wohl mal das System komplett neu installieren.
Allerdings ist mir noch nicht wirklich klar, was ich denn nun genau brauche. Wie schon gesagt, es geht mir nur um die Erreichbarkeit des Webinterfaces des ZTE aus dem "Heimnetz". In dem Netzwerk des ZTE befindet sich kein anderer Teilnehmer und es ist auch keiner geplant. Der ZTE soll nur das Fallback-Gateway für die FB sein.

 

[klp55tsch]

Der Client ist ein Android Tablet.

Mach mal von deinem Android Tablet einen TCP-Portscan auf den lauschenden TCP-Port 80 oder 443 des ZTE (IP-Adresse 192.168.0.1). Mit tcpdump kannst Du auf deinem PI, an den Interfaces eth0 bzw. eth1 schauen/sniffen, ob der TCP-Portscan dort erkennbar ist bzw. sich bemerkbar macht.

 

[3PO]

Leider tut sich da auf beiden Interfaces nichts:

root@RPI:~# tcpdump -c 300 -vvveni eth1 icmp and dst host 192.168.0.1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@RPI:~# tcpdump -c 300 -vvveni eth0 icmp and dst host 192.168.0.1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Aber wie schon gesagt, ich bin mir da garnicht so sicher, ob ich das System schon "verbastelt" habe.

Ich werde es einfach mal neu aufsetzen und ganz von vorne anfangen.

Vielen Dank übrigens, für eure Geduld.

 

[klp55tsch]

Leider tut sich da auf beiden Interfaces nichts:

Kein Wunder, mit diesem Filter (icmp) für tcpdump. Du solltest den richtigen Filter, für TCP-Verbindungen benutzen.
Welches Tool und wie, hast Du auf deinem Android Tablet für den TCP-Portscan zum ZTE, benutzt?

 

[3PO]

Mit "Ping-Tools"



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

 

[klp55tsch]

Dann starte vor dem Portscan mit dem Tablet, auf deinem PI:

tcpdump -c 300 -vvveni eth0 host 192.168.0.1

und mach danach den TCP-Portscan vom Tablet.