Frage:
Raspbmc filtert Verbindungen von außerhalb des LAN
Thomas
2013-02-20 19:42:31 UTC
view on stackexchange narkive permalink

Ich habe ein Problem mit der Verbindung zu Raspbmc über meine NAT-Firewall ... Mein Setup sieht folgendermaßen aus:

  raspbmc < - LAN - > (eth1) Router (eth0) < - WAN - > work192.168.1.3 192.168.1.2 5.6.7.8 1.2.3.4  

Ich habe die Ports weitergeleitet und kann dies über tcpdump bestätigen dass die SYN-Pakete am Pi ankommen. Der Benutzerraum erhält sie jedoch nie! Ich habe dies mit 3 verschiedenen Anwendungen (pyroTorrent, XBMC-Webschnittstelle und nc ) bestätigt und alle geben keine Antwort auf das in tcpdump gezeigte Paket.

Es funktioniert gut über das LAN, und ich kann es zum Laufen bringen, indem ich Folgendes zur iptables -Konfiguration meines Routers hinzufüge, aber das ist wirklich hässlich und ich möchte, dass es funktioniert, ohne darauf zurückzugreifen solche Manipulation:

  iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 5555 -j MASQUERADE  

Ich habe überprüft und den rp_filter wird für alle Schnittstellen auf dem Pi auf 0 gesetzt. Außerdem ist iptables leer und hat für alles die Standardrichtlinie ACCEPT. Habe ich etwas Spezielles für Raspbmc / Raspbian verpasst?

Vielen Dank im Voraus für Hilfe / Hinweise :)

Thomas

Hier ist die relevante Ausgabe von iptables-save auf dem Router:

  # Erstellt von iptables-save v1.4.8 am Mi Feb 20 14:20:23 2013 * mangle: PREROUTING ACCEPT [6829322: 4371711949 ]: INPUT ACCEPT [11442: 1053089]: FORWARD ACCEPT [6817880: 4370658860]: OUTPUT ACCEPT [7244: 653426]: POSTROUTING ACCEPT [6825030: 4371216486] COMMIT # Abgeschlossen am Mittwoch, 20. Februar, 14:20:23 2013 # -save v1.4.8 am Wed Feb 20 14:20:23 2013 * nat: PREROUTING ACCEPT [2834: 249851]: POSTROUTING ACCEPT [1124: 63804]: OUTPUT ACCEPT [78: 5781] -A PREROUTING -i eth0 -p tcp -m tcp --dport 5555 -j DNAT --to-destination 192.168.1.3:5555-A POSTROUTING -o eth0 -j MASQUERADECOMMIT # Abgeschlossen am Mi Feb 20 14:20:23 2013
# Erstellt von iptables-save v1.4.8 am Wed Feb 20 14:20:23 2013 * Filter: INPUT DROP [3875: 330500]: FORWARD DROP [0: 0]: OUTPUT ACCEPT [6557: 589075] -A INPUT -s 127.0.0.1/32 -i lo -j AKZEPTIEREN-EIN EINGANG -m Zustand - Zustand VERWANDT, EINGESTELLT -j AKZEPTIEREN -EINGANG -i eth1 -m Zustand - Zustand NEU -j AKZEPTIEREN-A EINGANG -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT-A FORWARD -i eth1 -o eth0 -j ACCEPT-A FORWARD -s 1.2.3.4/32 -d 192.168.1.3/32 -i eth0 -o eth1 -p tcp -m tcp --dport 5555 -j ACCEPTCOMMIT  

Und hier ist der tcpdump zeigt keine Antwort vom WAN an, aber erfolgreiche Transaktion vom LAN:

  pi @ raspbmc: ~ / pyrotorrent $ netstat -alpn | grep python (Nicht alle Prozesse konnten identifiziert werden, nicht Eigene Prozessinformationen werden nicht angezeigt, Sie müssten root sein, um alles zu sehen.) tcp 0 0 0.0.0.0:5555 0.0.0.0:* HÖREN 7917 / pythonpi @ raspbmc: ~ / pyrotorrent $ sudo tcpdump -vv 'Port 5555 'tcpdump: Abhören von eth0, Verbindungstyp EN10MB (Ethernet), Erfassungsgröße 65535 Bytes14: 36: 56.038955 IP (tos 0x0, ttl 112, ID 22881, Offset 0, Flags [DF], Proto-TCP (6), Länge 52 ) 1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x038d (korrekt), seq 83867849, win 8192, options [mss 1340, nop, wscale 8, nop, nop, sackOK], Länge 014: 36: 56.286900 IP (tos 0x0, ttl 112, id 22895, Offset 0, Flags [DF], Proto-TCP (6), Länge 52) 1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x4dba (richtig), seq 534844751, win 8192, options [mss 1340, nop, wscale 8, nop, nop, sackOK], länge 014: 36: 59.044256 IP (tos 0x0, ttl 112, id 22922, offset 0, flags [DF ], Proto-TCP (6), Länge 52) 1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x038d (korrekt), Sequenz 83867849, Gewinn 8192, Optionen [mss 1340, nop, wscale 8, nop, nop, sackOK], Länge 014: 36: 59.278972 IP (tos 0x0, ttl 112, ID 22923, Offset 0, Flags [DF], Proto-TCP (6), Länge 52)
1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x4dba (korrekt), seq 534844751, win 8192, options [mss 1340, nop, wscale 8, nop, nop, sackOK], Länge 014: 37 : 05.040700 IP (tos 0x0, ttl 112, id 22942, Offset 0, Flags [DF], Proto-TCP (6), Länge 48) 1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x179c ( richtig), seq 83867849, win 8192, options [mss 1340, nop, nop, sackOK], länge 014: 37: 05.280175 IP (tos 0x0, ttl 112, id 22943, offset 0, flags [DF], proto TCP (6) ), Länge 48) 1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x61c9 (korrekt), seq 534844751, win 8192, options [mss 1340, nop, nop, sackOK], Länge 014: 37 : 12.148221 IP (tos 0x0, ttl 64, id 15015, Offset 0, Flags [DF], Proto-TCP (6), Länge 60) 192.168.1.2.53754 > 192.168.1.3.5555: Flags [S], cksum 0x92c6 ( richtig), seq 4011566171, win 5840, options [mss 1460, sackOK, TS val 16031484 ecr 0, nop, wscale 5], länge 014: 37: 12.148569 IP (tos 0x0, ttl 64, id 0, offset 0, flags [ DF], pro bis TCP (6), Länge 60) 192.168.1.3.5555 > 192.168.1.2.53754: Flags [S.], cksum 0x8384 (falsch -> 0xa57e), seq 1622032073, ack 4011566172, win 14480, options [mss 1460, sackOK, TS val 7482252 ecr 16031484, nop, wscale 6], Länge 014: 37: 12.149062 IP (tos 0x0, ttl 64, id 15016, Offset 0, Flags [DF], Proto-TCP (6), Länge 52) 192.168. 1.2.53754 > 192.168.1.3.5555: Flags [.], Cksum 0x0c23 (korrekt), Sequenz 1, Bestätigung 1, Gewinn 183, Optionen [nop, nop, TS val 16031484 ecr7482252], Länge 014: 37: 12.149450 IP ( tos 0x0, ttl 64, id 15017, Offset 0, Flags [DF], Proto-TCP (6), Länge 161) 192.168.1.2.53754 > 192.168.1.3.5555: Flags [P.], cksum 0x75ee (korrekt), seq 1: 110, ack 1, win 183, options [nop, nop, TS val 16031484 ecr 7482252], Länge 10914: 37: 12.149615 IP (tos 0x0, ttl 64, id 5446, offset 0, flags [DF], proto TCP (6), Länge 52)
192.168.1.3.5555 > 192.168.1.2.53754: Flags [.], Cksum 0x837c (falsch -> 0x0b8a), seq 1, ack 110, win 227, options [nop, nop, TS val 7482252 ecr 16031484], length 014 : 37: 12.574406 IP (tos 0x0, ttl 64, id 15018, Offset 0, Flags [DF], Proto-TCP (6), Länge 52) 192.168.1.2.53754 > 192.168.1.3.5555: Flags [F.], cksum 0x0b8a (korrekt), seq 110, ack 1, win 183, options [nop, nop, TS val 16031527ecr 7482252], Länge 014: 37: 12.604953 IP (tos 0x0, ttl 64, id 5447, offset 0, flags [DF ], Proto-TCP (6), Länge 52) 192.168.1.3.5555 > 192.168.1.2.53754: Flags [.], cksum 0x837c (falsch -> 0x0b30), seq 1, ack 111, win 227, options [nop, nop, TS val 7482298 ecr 16031527], Länge 014: 37: 13.080329 IP (tos 0x0, ttl 64, id 5448, Offset 0, Flags [DF], Proto-TCP (6), Länge 69) 192.168.1.3.5555 > 192.168 .1.2.53754: Flags [P.], cksum 0x838d (falsch -> 0x4b23), seq 1:18, ack 111, win 227, options [nop, nop, TS val 7482345 ec r 16031527], Länge 1714: 37: 13.080861 IP (tos 0x0, ttl 64, id 0, Offset 0, Flags [DF], Proto-TCP (6), Länge 40) 192.168.1.2.53754 > 192.168.1.3.5555: Flags [R], cksum 0xb0f6 (korrekt), seq 4011566282, win 0, Länge 0  
Huumm, ich bin kein Netzwerkspezialist ... aber jede Antwort interessiert mich sehr. Ich kann nur mit der endgültigen Version von Raspbmc bestätigen, dass ich keine Verbindung zu meinem nGinx-Webserver über das Internet herstellen kann. Und das war auf der RC 4 beunruhigend :(
Einer antworten:
#1
+6
Sam Nazarko
2013-02-21 20:23:11 UTC
view on stackexchange narkive permalink

Aufgrund von Personen, die SSH verfügbar machen, ohne das Standardkennwort zu ändern, habe ich einige grundlegende Regeln hinzugefügt, die den Netzwerkzugriff nur auf LAN beschränken. In ein paar Tagen wird es eine Option geben, diese über das XBMC-Einstellungs-Plugin von Raspbmc zu deaktivieren. Im Moment können Sie diesen Thread jedoch als Ratgeber sehen.

http://forum.stmlabs.com /showthread.php?tid=6726

Prost

Ah danke ... Ich habe nur mit "iptables-save" nachgesehen, was leer zurückgegeben wurde, aber jetzt mit "iptables -L" sehe ich die Regeln.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...