[Erledigt] Zwei Netzwerke einfach miteinander verbinden.

Toggle sidebar Toggle sidebar
Upgrade 3CX to v18 and get it hosted free!
Dann kommt folgende Ausgabe:

Code: 
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:45:34.634417 04:b4:fe:93:a2:27 > b8:27:eb:27:ba:13, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 52313, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.90.34088 > 192.168.0.1.80: Flags [S], cksum 0xd780 (correct), seq 1821322868, win 65535, options [mss 1460,sackOK,TS val 3463925212 ecr 0,nop,wscale 10], length 0
18:45:34.836420 04:b4:fe:93:a2:27 > b8:27:eb:27:ba:13, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 53104, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.90.34896 > 192.168.0.1.443: Flags [S], cksum 0x23e9 (correct), seq 3918421936, win 65535, options [mss 1460,sackOK,TS val 3463925413 ecr 0,nop,wscale 10], length 0
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@RPI:~#
 
3PO schrieb:
2 packets captured
2 packets received by filter
Zum Vergrößern anklicken....
D. h. die statische Route in der FB ist OK bzw. funktioniert.
Schau mal jetzt mit tcpdump in deinem PI, ob beim Portscan mit dem Tablet, diese TCP-Pakete auch am eth1-Interface gesehen werden können:
Code: 
tcpdump -c 300 -vvveni eth1 host 192.168.0.1
 
Da kommt leider nichts:

Code: 
root@RPI:~# tcpdump -c 300 -vvveni eth1 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:~#
 
Wie ist auf deinem PI, jetzt die Ausgabe von:
Code: 
ip r g 192.168.0.1
?

EDIT:

... und:
Code: 
/usr/sbin/sysctl net.ipv4.ip_forward
?
 
Code: 
root@RPI:~# ip r g 192.168.0.1
192.168.0.1 dev eth1 src 192.168.0.133 uid 0
    cache
root@RPI:~#
Code: 
root@RPI:~# /usr/sbin/sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
root@RPI:~#
 
3PO schrieb:
Code: 
root@RPI:~# /usr/sbin/sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
root@RPI:~#
Zum Vergrößern anklicken....
Eintrag in der sysctl.conf reicht nicht, du musst auch dafür sorgen, dass dieser Eintrag wirksam wird.
Versuch mal mit:
Code: 
sysctl net.ipv4.ip_forward=1
, als root und danach erneut testen.
 
Jetzt kommt etwas:

Code: 
root@RPI:~# sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
root@RPI:~# tcpdump -c 300 -vvveni eth1 host 192.168.0.1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:07:22.185566 c8:a3:62:53:55:cb > 10:3c:59:43:e4:e4, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 62, id 18600, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.90.53010 > 192.168.0.1.80: Flags [S], cksum 0x6946 (correct), seq 708026733, win 65535, options [mss 1460,sackOK,TS val 3465232763 ecr 0,nop,wscale 10], length 0
19:07:22.374627 c8:a3:62:53:55:cb > 10:3c:59:43:e4:e4, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 62, id 3280, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.90.54298 > 192.168.0.1.443: Flags [S], cksum 0x86d4 (correct), seq 3426736790, win 65535, options [mss 1460,sackOK,TS val 3465232964 ecr 0,nop,wscale 10], length 0
19:07:27.188892 c8:a3:62:53:55:cb > 10:3c:59:43:e4:e4, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.133, length 28
19:07:27.191391 10:3c:59:43:e4:e4 > c8:a3:62:53:55:cb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.133 tell 192.168.0.1, length 46
19:07:27.191460 c8:a3:62:53:55:cb > 10:3c:59:43:e4:e4, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.133 is-at c8:a3:62:53:55:cb, length 28
19:07:27.191401 10:3c:59:43:e4:e4 > c8:a3:62:53:55:cb, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.1 is-at 10:3c:59:43:e4:e4, length 46
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
root@RPI:~#
 
3PO schrieb:
Code: 
root@RPI:~# tcpdump -c 300 -vvveni eth1 host 192.168.0.1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:07:22.185566 c8:a3:62:53:55:cb > 10:3c:59:43:e4:e4, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 62, id 18600, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.90.53010 > 192.168.0.1.80: Flags [S], cksum 0x6946 (correct), seq 708026733, win 65535, options [mss 1460,sackOK,TS val 3465232763 ecr 0,nop,wscale 10], length 0
19:07:22.374627 c8:a3:62:53:55:cb > 10:3c:59:43:e4:e4, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 62, id 3280, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.178.90.54298 > 192.168.0.1.443: Flags [S], cksum 0x86d4 (correct), seq 3426736790, win 65535, options [mss 1460,sackOK,TS val 3465232964 ecr 0,nop,wscale 10], length 0
root@RPI:~#
Zum Vergrößern anklicken....
Die Antwort (syn+ack) bzw. der Rückweg, fehlt noch. Versuch mal auch als root, mit:
Code: 
iptables -t nat -I POSTROUTING 1 -o eth0 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o eth1 -j MASQUERADE
auf deinem PI.
 
Wenn Du wieder dieselbe Interface-Konfiguration einstellen solltest, dann gehe Schritt für Schritt vor.
  • Ping für die IP des ZTE-Routers (auf dem RasPi)
  • nf_conntrack laden
  • die Masquerading-Regel (aus #9) für eth1 einrichten
  • erneutes Ping zum Router, das sollte immer noch funktionieren
  • IPv4-Forwarding setzen (wenn nicht persistent, ansonsten würde Deine sysctl.conf passen, wenn sie beim Start auch berücksichtigt wird)
  • ein einfaches ping vom Tablet (z.B. mit fing)
  • wenn das funktioniert, kannst Du es mit weiteren Aktionen probieren (egal ob Portscan oder Webinterface-Aufruf)
Egal, was ich schreiben wollte - Ihr macht das schon irgendwie … auch wenn ich immer noch nicht verstehe (und offensichtlich will es mir ja auch niemand beantworten), was das Masquerading auf eth0 letztlich soll. Ich halte mich also ab jetzt raus … bis auf einen letzten Hinweis, den ich mir nicht verkneifen kann.

Vermutlich wirst Du ohnehin Probleme bekommen, wenn Du die statische Route in der FRITZ!Box permanent aktiviert läßt und nicht nur bei Bedarf (also beim Zugriff auf das Webinterface des ZTE-Routers) zuschaltest. Unter der Annahme, daß der ZTE-Router auch der FRITZ!Box eine Adresse aus 192.168.0.0/24 zuweist, wenn der Fallback-Modus aktiviert wird - denn dann wird das FRITZ!OS vermutlich seinerseits eine (weitere) "default route" setzen wollen über LAN1 und ich weiß nicht (vermutlich hat man das auch nicht wirklich getestet), was dann im FRITZ!OS passiert. Kommen die "ganz normalen Routing-Regeln" zum Einsatz (auch wenn AVM immer noch einen eigenen WAN-Stack verwendet), schlägt die "spezifischere" statische Route über den RasPi eine "default route" und der Traffic kommt vermutlich nie auf LAN1 raus.

Das solltest Du also auch noch (gut) testen (statische Routen lassen sich per Checkbox oder auch per TR-064 (de-)aktivieren, SetForwardingEntryEnable in https://fritz.support/resources/TR-064_Layer_3_Forwarding.pdf), ansonsten schießt Du Dir selbst ins Knie.

Viel Erfolg …
 
JETZT GEHT'S!!

Vielen Dank, für die Unterstützung und die Geduld!

Allerdings würde es mich noch interessieren, was denn nun genau notwendig war, denn dann würde ich eine Zusammenfassung schreiben.
 
3PO schrieb:
Allerdings würde es mich noch interessieren, was denn nun genau notwendig war, ...
Zum Vergrößern anklicken....
Die statische Route in deiner FB, das Forwarding (d. h. die Router-Funktion) auf deinem PI und das source-NAT (MASQUERADE) auf deinem PI.
Hinweis: Das source-NAT (mit iptables) auf deinem PI ist noch nicht persistent.
 
Da sich #29 und #30 wohl überschnitten haben, würde mich auch noch die Frage interessieren, ob der Fallback-Betrieb weiterhin funktioniert (also auch mit der statischen Route in der FRITZ!Box) - sollte das so sein, würde ich gerne mal aus der Support-Datei die Interface-Konfiguration und die Routing-Table sehen.

Zumindest wäre dann (sollte es tatsächlich noch funktionieren) der RasPi ein weiterer SPoF, wenn die Box dann den Traffic in WAN-Richtung IMMER über ihn sendet, weil die statische Route "gewinnt" (mal abgesehen vom dreifachen NAT - einmal in der FRITZ!Box, einmal auf dem RasPi und noch einmal auf dem ZTE-Router).

Aber vielleicht wirft die FRITZ!Box die statische Route ja auch raus bei der Umschaltung auf den Fallback-Modus - wenn denn jemand diesen "Spezialfall" (statische Route gesetzt, die dasselbe Netzwerksegment adressiert, das der Fallback-Router anbietet) tatsächlich bei der Implementierung berücksichtigt haben sollte. Daher die Bitte, die Support-Daten zu zeigen, wenn es wider Erwarten auch weiterhin funktionieren sollte.
 
@PeterPawn,

Ich kann ja morgen mal den Stecker am WAN Port ziehen und dann berichten.

Was genau meinst du mit "Supportdaten" und wie komme ich die?

Des weiteren könntest du ja eventuell, kurz beschreiben, wie du vorgehen würdest. Die Aufgabenstellung ist ja bekannt.
 
Probiere es erst mal - funktioniert der Fallback-Modus jetzt nicht mehr wie erwartet (ich WEISS es ja auch nicht, ich habe nur versucht, meine Bedenken zu erklären, warum es nicht funktionieren KÖNNTE), dann sehen wir weiter.

Wenn doch - um so besser; allerdings wäre es dann nett, wenn Du die

Supportdaten: https://fritz.com/pages/support-daten-der-fritz-box-erstellen

zeigen könntest (mit und ohne aktiviertem Fallback-Router), wobei da bei weitem nicht alles interessant ist, sondern eben nur die Interface-Konfiguration und die Routing-Table (wie oben geschrieben) - da sind dann i.d.R. auch keine "geheimen" oder persönlichen Infos zu sehen (solange man die Ausgabe von showdsldstat nicht auch noch postet).

EDIT:
Klappt das Routing auch im Fallback-Modus noch, kannst Du ja auch mal den RasPi aus dem Spiel nehmen - geht es dann weiterhin, hast Du KEINEN neuen SPoF in Deinem Netzwerk, was mich noch neugieriger auf den Blick in die Supportdaten machen würde.
 
@3PO:

BTW: Versuch mal auf dem PI, die jetzigen source-NAT-Regeln (MASQUERADE) zu ersetzen, mit:
Code: 
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
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
und testen.
Wenn Du für den Zugriff auf den ZTE nur den Port 443 benutzt, kannst Du die Regeln mit dem Port 80, weglassen.
 
Guten Morgen Zusammen,

Hier hier noch die Supportdaten mit getrennter Verbindung FB <--> ONT.

Auch während der "Ausfallschutz" aktiv ist, funktioniert alles einwandfrei, bzw. ich konnte keine unerwünschte Nebeneffekte feststellen.

1000017459.jpg

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

Anhänge

Zuletzt bearbeitet von einem Moderator:
@klp55tsch,

Ich habe noch einen zweiten Standort mit der selben Konstellation, da werde ich das mal, morgen oder übermorgen, mit den anderen Regeln testen.
 
@3PO:

BTW: Du könntest in deiner FritzBox, statt der statischen Route in das Subnetz 192.168.0.0/24, nur eine statische Route zum Host (ZTE) 192.168.0.1, mit dem PI als gateway (im Subnetz der FB) konfigurieren.

EDIT:

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).
 
@klp55tsch,

Ich denke mal, daß ich das mit der Route, direkt zum Host, so machen werde, denn es geht mir ja nur darum, daß ich das Webinterface des ZTE erreichen kann.
Theoretisch könnte ich das Webinterface auch via WLAN erreichen, das Problem dabei ist nur, daß ich denn ZTE bei mir unterm Dache habe und da die WLAN Verbindung nicht wirklich funktioniert.

Des Weiteren werde ich mir wohl mal beim Aliexpress einen kleinen Orange Pi bestellen und das ganze damit mal versuchen.

1000017462.jpg

Bild(er) als Vorschaubild(er) (siehe https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ ) eingebunden by stoney
 
Zuletzt bearbeitet von einem Moderator:
Um antworten zu können musst du eingeloggt sein.
Kostenlos!
Jetzt holen

Neueste Beiträge

Kategorien

Wissenswertes

Zurzeit aktive Besucher

Gesamt: 490 (Mitglieder: 17, Gäste: 473)

Statistik des Forums

Themen
248,114
Beiträge
2,281,796
Mitglieder
377,336
Neuestes Mitglied
nebl78

3CX jetzt einen Monat kostenlos testen

Die Verbindung, Zusammenarbeit und Kommunikation mit Ihrem Team und Ihren Kunden war noch nie so einfach. Nutzen Sie unsere kostenlose 30-Tage-Testversion und entdecken Sie die richtige Lösung für Ihr Unternehmen.

3CX start your free trial guy
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten