Router Linux: il ping non ritorna indietro

14

Ho un box Debian che sto cercando di configurare come router e un box Ubuntu che sto usando come client.

Il mio problema è che quando il client Ubuntu tenta di eseguire il ping di un server su Internet, tutti i pacchetti vengono persi (anche se, come puoi vedere di seguito, sembrano andare sul server e tornare indietro senza problemi).

Lo sto facendo nella Ubuntu Box:

# ping -I eth1 my.remote-server.com
PING my.remote-server.com (X.X.X.X) from 10.1.1.12 eth1: 56(84) bytes of data.
^C
--- my.remote-server.com ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12094ms

(Ho cambiato il nome e l'IP del server remoto per la privacy).

Dal router Debian vedo questo:

# tcpdump -i eth1 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 7, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 8, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 8, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 9, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 9, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 10, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 10, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 305, seq 11, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 305, seq 11, length 64
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel

# tcpdump -i eth2 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 213, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 213, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 214, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 214, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 215, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 215, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 216, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 216, length 64
IP 192.168.1.10 > X.X.X.X: ICMP echo request, id 360, seq 217, length 64
IP X.X.X.X > 192.168.1.10: ICMP echo reply, id 360, seq 217, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

E sul server remoto vedo questo:

# tcpdump -i eth0 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 1, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 1, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 2, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 2, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 3, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 3, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 4, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 4, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 5, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 5, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 6, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 6, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 7, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 7, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 8, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 8, length 64
IP Y.Y.Y.Y > X.X.X.X: ICMP echo request, id 360, seq 9, length 64
IP X.X.X.X > Y.Y.Y.Y: ICMP echo reply, id 360, seq 9, length 64

18 packets captured
228 packets received by filter
92 packets dropped by kernel

Qui "XXXX" è l'IP del mio server remoto e "YYYY" è l'IP pubblico della mia rete locale. Quindi, quello che capisco è che i pacchetti ping stanno uscendo dalla scatola di Ubuntu (10.1.1.12), al router (10.1.1.1), da lì al router successivo (192.168.1.1) e raggiungendo il server remoto (XXXX ). Quindi tornano fino al router Debian, ma non raggiungono mai la casella Ubuntu.

Cosa mi sto perdendo?

Ecco la configurazione del router Debian:

# ifconfig
eth1      Link encap:Ethernet  HWaddr 94:0c:6d:82:0d:98  
          inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::960c:6dff:fe82:d98/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:105761 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48944 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:40298768 (38.4 MiB)  TX bytes:44831595 (42.7 MiB)
          Interrupt:19 Base address:0x6000 

eth2      Link encap:Ethernet  HWaddr 6c:f0:49:a4:47:38  
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::6ef0:49ff:fea4:4738/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38335992 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37097705 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:4260680226 (3.9 GiB)  TX bytes:3759806551 (3.5 GiB)
          Interrupt:27 

eth3      Link encap:Ethernet  HWaddr 94:0c:6d:82:c8:72  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:20 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3408 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3408 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:358445 (350.0 KiB)  TX bytes:358445 (350.0 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2767779 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1569477 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:3609469393 (3.3 GiB)  TX bytes:96113978 (91.6 MiB)


# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
127.0.0.1       0.0.0.0         255.255.255.255 UH    0      0        0 lo
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth2
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth2

# arp -n 
# Note: Here I have changed all the different MACs except the ones corresponding to the Ubuntu box (on 10.1.1.12 and 192.168.1.12)
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.118            ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.72             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.94             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.102            ether   NN:NN:NN:NN:NN:NN   C                     eth2
10.1.1.12                ether   00:1e:67:15:2b:f0   C                     eth1
192.168.1.86             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.2              ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.61             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.64             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.116            ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.91             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.52             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.93             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.87             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.92             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.100            ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.40             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.53             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.1              ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.83             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.89             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.12             ether   00:1e:67:15:2b:f1   C                     eth2
192.168.1.77             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.66             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.90             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.65             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.41             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.78             ether   NN:NN:NN:NN:NN:NN   C                     eth2
192.168.1.123            ether   NN:NN:NN:NN:NN:NN   C                     eth2


# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   

# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.1.1.0/24         !10.1.1.0/24         
MASQUERADE  all  -- !10.1.1.0/24          10.1.1.0/24         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ed ecco la scatola di Ubuntu:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1e:67:15:2b:f1  
          inet addr:192.168.1.12  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:67ff:fe15:2bf1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28785139 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19050735 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:32068182803 (32.0 GB)  TX bytes:6061333280 (6.0 GB)
          Interrupt:16 Memory:b1a00000-b1a20000 

eth1      Link encap:Ethernet  HWaddr 00:1e:67:15:2b:f0  
          inet addr:10.1.1.12  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:67ff:fe15:2bf0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:285086 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12719 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:30817249 (30.8 MB)  TX bytes:2153228 (2.1 MB)
          Interrupt:16 Memory:b1900000-b1920000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:86048 errors:0 dropped:0 overruns:0 frame:0
          TX packets:86048 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11426538 (11.4 MB)  TX bytes:11426538 (11.4 MB)

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
0.0.0.0         10.1.1.1        0.0.0.0         UG    100    0        0 eth1
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.8.0.0        192.168.1.10    255.255.255.0   UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0

# arp -n
# Note: Here I have changed all the different MACs except the ones corresponding to the Debian box (on 10.1.1.1 and 192.168.1.10)
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.70             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.90             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.97             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.103            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.13             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.120                    (incomplete)                              eth0
192.168.1.111            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.118            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.51             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.102                    (incomplete)                              eth0
192.168.1.64             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.52             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.74                     (incomplete)                              eth0
192.168.1.94             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.121            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.72             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.87             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.91             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.71             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.78             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.83             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.88                     (incomplete)                              eth0
192.168.1.82             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.98             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.100            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.93             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.73             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.11             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.85                     (incomplete)                              eth0
192.168.1.112            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.89             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.65             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.81             ether   NN:NN:NN:NN:NN:NN   C                     eth0
10.1.1.1                 ether   94:0c:6d:82:0d:98   C                     eth1
192.168.1.53             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.116            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.61             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.10             ether   6c:f0:49:a4:47:38   C                     eth0
192.168.1.86                     (incomplete)                              eth0
192.168.1.119            ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.66             ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.1              ether   NN:NN:NN:NN:NN:NN   C                     eth0
192.168.1.1              ether   NN:NN:NN:NN:NN:NN   C                     eth1
192.168.1.92             ether   NN:NN:NN:NN:NN:NN   C                     eth0

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Modifica: seguendo il suggerimento di Patrick, ho fatto un tcpdump con la casella Ubuntu e vedo questo:

# tcpdump -i eth1 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 1, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 1, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 2, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 2, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 3, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 3, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 4, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 4, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 5, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 5, length 64
IP 10.1.1.12 > X.X.X.X: ICMP echo request, id 21967, seq 6, length 64
IP X.X.X.X > 10.1.1.12: ICMP echo reply, id 21967, seq 6, length 64
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Quindi la domanda è: se tutti i pacchetti sembrano andare e venire, perché il ping segnala una perdita di pacchetti del 100%?

— El Barto
fonte

come appare la tua configurazione di iptables? Stai bloccando i pacchetti ICMP?

— Zypher,

No non sono. Ho appena aggiunto l'output di iptables -L -nper il router Debian. È vuoto.

— El Barto,

Lo sono, ma non lo fanno ?:MASQUERADE all -- 10.1.1.0/24 !10.1.1.0/24 MASQUERADE all -- !10.1.1.0/24 10.1.1.0/24

— El Barto,

1

Che dire di un tcpdump dalla 'scatola di Ubuntu'? Il tcpdump da "router debian" mostra chiaramente i pacchetti di risposta inviati. Tcpdump opera al di fuori del filtro a livello di kernel, quindi se il kernel sta abbandonando le risposte per qualsiasi motivo, tcpdump su 'ubuntu box' dovrebbe almeno mostrarle mentre arrivano alla casella. In un'altra nota, hai fornito molte informazioni utili in un modo molto chiaro, bello avere qui.

— Patrick,

Grazie, @Patrick. Ho fatto un tcpdump sulla scatola di Ubuntu e i pacchetti sembrano tornare, ma il ping mostra ancora una perdita di pacchetti del 100%.

— El Barto,

9

Dalla tua domanda nei commenti:

Sul server remoto vedo richieste e risposte. Ma sul router Debian non vedo nulla ... su nessuna delle interfacce! La mia ipotesi è che ora, la casella Ubuntu sta parlando direttamente al router su 192.168.1.1 PENSANDO l'invio di richieste con IP 10.1.1.12, quindi non può tornare indietro. Ma perché??

Dal server Ubuntu:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0 <---
0.0.0.0         10.1.1.1        0.0.0.0         UG    100    0        0 eth1

Nel momento in cui hai acquisito questa tabella di routing, hai un valore predefinito di metrica inferiore eth0indicando il tuo router su 192.168.1.1 (ovvero non la macchina debian). Viene sempre seguito sempre un valore predefinito di metrica inferiore, il che significa che Ubuntu vuole inviare tutto il traffico non connesso direttamente a 192.168.1.1.

Quando sono disponibili tempi di inattività, rimuovere tale impostazione predefinita con

route del default gw 192.168.1.1 dev eth0

Sto ancora cuocendo a fuoco lento sul problema più grande (le tracce dello sniffer originale mostrano le risposte ping su Ubuntu: eth1, ma nessun ping accettato dal sistema operativo). Potresti per favore eseguire il ping da Ubuntu: eth1 e contemporaneamente catturare su Debian: eth2 per dimostrare cosa sta succedendo con NAT dopo aver forzato Ubuntu a inviare nuovamente tutto il traffico attraverso Debian?

— Mike Pennington
fonte

Grazie, la tua risposta sulla metrica è stata utile. Al momento non riesco a rimuovere il percorso predefinito attraverso 192.168.1.1, ma lo controllerò più avanti. Attualmente il tcpdump su Debian: eth2 non mostra nulla, (penso) perché i pacchetti vengono inviati direttamente a 192.168.1.1. Ma quello che è successo prima è sul mio post originale. Controlla dove dice "Dal router Debian vedo questo".

— El Barto,

È difficile dire del problema originale ... il mio suggerimento: rimetti in riga tutto dopo aver rimosso il valore predefinito ... esegui tutte le acquisizioni dello sniffer in una volta. Inoltre, se possibile ottieni informazioni su indirizzo mac src / dest oltre agli IP src / dest ... il mondo perfetto è usare tshark(WireShark in modalità testo) e puoi specificare quali campi vuoi catturare ... vedi il mio domanda qui per un esempio. Infine, puoi eseguire il ping di altre destinazioni su Internet quando si verifica il problema?

— Mike Pennington,

Grazie Mike. Verificherò senza l'itinerario predefinito tra un paio d'ore quando le persone lasceranno l'ufficio. Per quanto riguarda le altre destinazioni, è divertente. Ho appena provato a eseguire il ping di google.com e sto ottenendo lo stesso risultato che avevo precedentemente eseguito il ping del mio server remoto: posso vedere i pacchetti ICMP andare e venire attraverso le interfacce appropriate ma pingmostra ancora la perdita dei pacchetti al 100%. Immagino che questa differenza tra Google e il mio server remoto abbia a che fare con la cache dei percorsi. Ho ragione?

— El Barto,

Non posso ancora dire il motivo degli errori di ping ... Non ho abbastanza prove. Questo è un problema insolito ... alcuni suggerimenti per aiutare a diagnosticare. Usa ping -v <destination>per vedere se ottieni più diagnostica per il motivo per cui i ping non funzionano ... Per favore, cammina anche i tuoi ping, iniziando con localhost, quindi Ubuntu Ethernet IP Addr, quindi il predefinito GW, un hop dopo, e così via fino a trovare dove si trovano iniziare a fallire. Inoltre, per favore non specificare l'interfaccia quando lo fai ...

— Mike Pennington,

Vado a controllare tra un paio d'ore. Attualmente se eseguo il ping senza specificare un'interfaccia, verrà instradato attraverso il gateway predefinito che è 192.168.1.1.

— El Barto,

8

Hai verificato se il filtro per il percorso inverso è abilitato nella casella Ubuntu?

È un'impostazione sysctl ( net.ipv4.conf.all.rp_filter), filtrerà i pacchetti in entrata se l'indirizzo sorgente arriva nell'interfaccia "errata" (cioè non l'interfaccia a cui il kernel lo instraderebbe)

Potresti anche provare net.ipv4.conf.all.log_martians=1a provare a vedere cosa sta succedendo.

— Jeroen van Bemmel
fonte

1

Questo commento mi ha portato nella giusta direzione, ma ho dovuto disabilitarlo per l'interfaccia specifica, come:sysctl net.ipv4.conf.eth1.rp_filter=0

— Konrad

2

La chiave per farlo funzionare è creare tabelle di routing separate per le diverse interfacce e dire allo stack di rete di usare queste tabelle di routing invece di quella predefinita.

Nel tuo caso questo dovrebbe far ping -I eth2 8.8.8.8funzionare:

# register the 'foo' table name and give it id 1
echo '1 foo' >> /etc/iproute2/rt_tables

# setup routing table 'foo'
ip route add 192.168.1.0/24 dev eth2 src 192.168.1.10 table foo
ip route add default via 192.168.1.1 table foo

# use routing table 'foo' for address 192.168.1.10
ip rule add from 192.168.1.10 table foo

Ulteriori informazioni sul routing per più uplink sono disponibili nel LARTC HOWTO: http://lartc.org/howto/lartc.rpdb.multiple-links.html

— konrad
fonte

-1

Se il tuo iptables è completamente vuoto (a parte l'istruzione masquerade), probabilmente dovrai aggiungere una catena FORWARDING per consentire il traffico attraverso la casella. Prova a partire da una configurazione di lavoro nota-

http://wiki.debian.org/DebianFirewall#Using_iptables_for_IPv4_traffic

Ciò include anche la conferma che sei impostato per l'inoltro in sysctl e simili.

— rnxrx
fonte

La catena FORWARD ha la sua politica impostata su ACCEPT, va bene. Tcpdump mostra anche che i pacchetti vengono correttamente inoltrati (entrambe le direzioni).

— Patrick,

Forse mi manca qualcosa, ma il tuo percorso predefinito dalla casella Ubuntu è tramite un router separato, non la casella Debian. Nella casella Ubuntu si specifica che si desidera che i pacchetti provengano dal 10.1.1.12 ma il percorso predefinito è 192.168.1.1. Se vuoi che il router Debian traduca questo traffico, allora l'host Ubuntu deve instradare il suo traffico in uscita tramite quel dispositivo, non il router. Prova ad aggiungere un percorso al tuo server remoto tramite la casella Debian e vedi come funziona.

— rnxrx,

Il fatto è che il box Debian è attualmente dietro un altro router. Quindi il percorso che i pacchetti dovrebbero seguire è dalla casella Ubuntu, alla casella Debian, attraverso l'altro router al server remoto su Internet (e viceversa). Da quello che vedo su tcpdump sembra che pingfunzioni , ma ad un certo punto manca qualcosa perché riporta i pacchetti persi.

— El Barto,

-1

Devi configurare NAT.

In una configurazione tipica, una rete locale utilizza una delle sottoreti dell'indirizzo IP "privato" designate. Un router su quella rete ha un indirizzo privato in quello spazio degli indirizzi. Il router è inoltre connesso a Internet con un indirizzo "pubblico" assegnato da un fornitore di servizi Internet. Man mano che il traffico passa dalla rete locale a Internet, l'indirizzo di origine in ciascun pacchetto viene tradotto al volo da un indirizzo privato a un indirizzo pubblico. Il router tiene traccia dei dati di base su ciascuna connessione attiva (in particolare l'indirizzo e la porta di destinazione). Quando una risposta ritorna al router, utilizza i dati di tracciamento della connessione memorizzati durante la fase di uscita per determinare l'indirizzo privato sulla rete interna a cui inoltrare la risposta.

— Jerry
fonte

NAT è già configurato. Si noti che i pacchetti sia in tcpdump sul router, sia in tcpdump sul server remoto mostrano entrambi che i pacchetti sono stati SNATed al nuovo indirizzo. I tcpdumps mostrano anche che i pacchetti di ritorno vengono ripristinati correttamente.

— Patrick,