Domanda:
Raspbmc che filtra le connessioni dalla LAN esterna
Thomas
2013-02-20 19:42:31 UTC
view on stackexchange narkive permalink

Ho un problema di connessione a Raspbmc tramite il mio firewall NAT ... La mia configurazione è così:

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

Ho inoltrato le porte e posso confermare tramite tcpdump che i pacchetti SYN stanno arrivando al Pi. Tuttavia lo spazio utente non li riceve mai! L'ho confermato utilizzando 3 diverse applicazioni (pyroTorrent, interfaccia web XBMC e nc ), e tutte non danno risposta al pacchetto mostrato in tcpdump .

Funziona bene dalla LAN e posso farlo funzionare aggiungendo quanto segue alla configurazione di iptables del mio router, ma è davvero brutto e vorrei farlo funzionare senza ricorrere a tale manipolazione:

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

Ho controllato e il rp_filter è impostato a 0 per tutte le interfacce sul Pi. Inoltre, iptables è vuoto e ha il criterio predefinito ACCETTA per tutto. Mi sono perso qualcosa di specifico su Raspbmc / Raspbian?

Grazie in anticipo per qualsiasi aiuto / suggerimenti :)

Thomas

Ecco il relativo output di iptables-save sul router:

  # Generato da iptables-save v1.4.8 mercoledì 20 febbraio 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 # Completato mercoledì 20 febbraio 14:20:23 2013 # Generato da iptables -salva v1.4.8 il mercoledì 20 febbraio 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 --destinazione 192.168.1.3:5555-A POSTROUTING -o eth0 -j MASQUERADECOMMIT # Completato mercoledì 20 febbraio 14:20:23 2013
# Generato da iptables-save v1.4.8 mercoledì 20 febbraio 14:20:23 2013 * filtro: INPUT DROP [3875: 330500]: FORWARD DROP [0: 0]: OUTPUT ACCEPT [6557: 589075] -A INPUT -s 127.0.0.1/32 -i lo -j ACCEPT-A INPUT -m state --state RELATED, ESTABLISHED -j ACCEPT-A INPUT -i eth1 -m state --state NEW -j ACCEPT-A INPUT -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  

Ed ecco il tcpdump che non mostra alcuna risposta dalla WAN, ma transazione riuscita dalla LAN:

  pi @ raspbmc: ~ / pyrotorrent $ netstat -alpn | grep python (Non tutti i processi possono essere identificati, non- le informazioni sul processo di proprietà non verranno mostrate, dovresti essere root per vederle tutte.) tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN 7917 / pythonpi @ raspbmc: ~ / pyrotorrent $ sudo tcpdump -vv 'port 5555 'tcpdump: in ascolto su eth0, tipo di collegamento EN10MB (Ethernet), dimensione di acquisizione 65535 byte14: 36: 56.038955 IP (tos 0x0, ttl 112, id 22881, offset 0, flag [DF], proto TCP (6), lunghezza 52 ) 1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x038d (corretto), seq 83867849, win 8192, opzioni [mss 1340, nop, wscale 8, nop, nop, sackOK], lunghezza 014: 36: 56.286900 IP (tos 0x0, ttl 112, id 22895, offset 0, flag [DF], proto TCP (6), lunghezza 52) 1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x4dba (corretto), seq 534844751, win 8192, opzioni [mss 1340, nop, wscale 8, nop, nop, sackOK], lunghezza 014: 36: 59.044256 IP (tos 0x0, ttl 112, id 22922, offset 0, flag [DF ], proto TCP (6), lunghezza 52) 1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x038d (corretto), seq 83867849, win 8192, opzioni [mss 1340, nop, wscale 8, nop, nop, sackOK], lunghezza 014: 36: 59.278972 IP (tos 0x0, ttl 112, id 22923, offset 0, flag [DF], proto TCP (6), lunghezza 52)
1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x4dba (corretto), seq 534844751, win 8192, opzioni [mss 1340, nop, wscale 8, nop, nop, sackOK], lunghezza 014: 37 : 05.040700 IP (tos 0x0, ttl 112, id 22942, offset 0, flag [DF], proto TCP (6), lunghezza 48) 1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x179c ( corretto), seq 83867849, win 8192, opzioni [mss 1340, nop, nop, sackOK], lunghezza 014: 37: 05.280175 IP (tos 0x0, ttl 112, id 22943, offset 0, flag [DF], proto TCP (6 ), lunghezza 48) 1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x61c9 (corretto), seq 534844751, win 8192, opzioni [mss 1340, nop, nop, sackOK], lunghezza 014: 37 : 12.148221 IP (tos 0x0, ttl 64, id 15015, offset 0, flag [DF], proto TCP (6), lunghezza 60) 192.168.1.2.53754 > 192.168.1.3.5555: Flags [S], cksum 0x92c6 ( corretto), seq 4011566171, win 5840, opzioni [mss 1460, sackOK, TS val 16031484 ecr 0, nop, wscale 5], lunghezza 014: 37: 12.148569 IP (tos 0x0, ttl 64, id 0, offset 0, flag [ DF], professionista a TCP (6), lunghezza 60) 192.168.1.3.5555 > 192.168.1.2.53754: Flag [S.], cksum 0x8384 (non corretto -> 0xa57e), seq 1622032073, ack 4011566172, win 14480, opzioni [mss sackOK, TS val 7482252 ecr 16031484, nop, wscale 6], lunghezza 014: 37: 12.149062 IP (tos 0x0, ttl 64, id 15016, offset 0, flag [DF], proto TCP (6), lunghezza 52) 192.168. 1.2.53754 > 192.168.1.3.5555: Flags [.], Cksum 0x0c23 (corretto), seq 1, ack 1, win 183, opzioni [nop, nop, TS val 16031484 ecr7482252], lunghezza 014: 37: 12.149450 IP ( tos 0x0, ttl 64, id 15017, offset 0, flags [DF], proto TCP (6), length 161) 192.168.1.2.53754 > 192.168.1.3.5555: Flags [P.], cksum 0x75ee (corretto), seq 1: 110, ack 1, win 183, opzioni [nop, nop, TS val 16031484 ecr 7482252], lunghezza 10914: 37: 12.149615 IP (tos 0x0, ttl 64, id 5446, offset 0, flag [DF], proto TCP (6), lunghezza 52)
192.168.1.3.5555 > 192.168.1.2.53754: Flag [.], Cksum 0x837c (errato -> 0x0b8a), seq 1, ack 110, win 227, opzioni [nop, nop, TS val 7482252 ecr 16031484] : 37: 12.574406 IP (tos 0x0, ttl 64, id 15018, offset 0, flag [DF], proto TCP (6), lunghezza 52) 192.168.1.2.53754 > 192.168.1.3.5555: Flag [F.], cksum 0x0b8a (corretto), seq 110, ack 1, win 183, opzioni [nop, nop, TS val 16031527ecr 7482252], lunghezza 014: 37: 12.604953 IP (tos 0x0, ttl 64, id 5447, offset 0, flag [DF ], proto TCP (6), lunghezza 52) 192.168.1.3.5555 > 192.168.1.2.53754: Flag [.], cksum 0x837c (errato -> 0x0b30), sequenza 1, ack 111, vittoria 227, opzioni [nop, nop, TS val 7482298 ecr 16031527], lunghezza 014: 37: 13.080329 IP (tos 0x0, ttl 64, id 5448, offset 0, flag [DF], proto TCP (6), lunghezza 69) 192.168.1.3.5555 > 192.168 .1.2.53754: Flag [P.], cksum 0x838d (non corretto -> 0x4b23), seq 1:18, ack 111, win 227, opzioni [nop, nop, TS val 7482345 ec r 16031527], lunghezza 1714: 37: 13.080861 IP (tos 0x0, ttl 64, id 0, offset 0, flag [DF], proto TCP (6), lunghezza 40) 192.168.1.2.53754 > 192.168.1.3.5555: Flag [R], cksum 0xb0f6 (corretto), codice 4011566282, vittoria 0, lunghezza 0  
Huumm, non sono uno specialista di rete ... ma sono molto interessato a qualsiasi risposta. Posso solo confermare che con la versione finale di Raspbmc non sono in grado di connettermi al mio server Web nGinx da Internet. E questo era preoccupante sull'RC 4 :(
Una risposta:
#1
+6
Sam Nazarko
2013-02-21 20:23:11 UTC
view on stackexchange narkive permalink

A causa delle persone che espongono SSH senza modificare la password predefinita, ho aggiunto alcune regole di base che limitano l'accesso alla rete solo alla LAN. Tra un paio di giorni ci sarà un'opzione per disabilitarli dal plug-in delle impostazioni XBMC di Raspbmc, ma per ora puoi vedere questo thread per un consiglio

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

Saluti

Ah grazie ... Ho controllato solo con `iptables-save` che è tornato vuoto, ma ora con` iptables -L` vedo le regole.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...