Маршрутизатор Linux: ping не маршрутизирует обратно

14

У меня есть окно Debian, которое я пытаюсь настроить в качестве маршрутизатора, и окно Ubuntu, которое я использую в качестве клиента.

Моя проблема в том, что когда клиент Ubuntu пытается пропинговать сервер в Интернете, все пакеты теряются (хотя, как вы можете видеть ниже, они, похоже, отправляются на сервер и возвращаются без проблем).

Я делаю это в 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

(Я изменил имя и IP удаленного сервера для конфиденциальности).

С маршрутизатора Debian я вижу это:

# 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

И на удаленном сервере я вижу это:

# 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

Здесь «XXXX» - это IP-адрес моего удаленного сервера, а «YYYY» - это публичный IP-адрес моей локальной сети. Итак, я понимаю, что пакеты ping выходят из коробки Ubuntu (10.1.1.12), к маршрутизатору (10.1.1.1), оттуда к следующему маршрутизатору (192.168.1.1) и достигают удаленного сервера (XXXX). ). Затем они возвращаются обратно к маршрутизатору Debian, но никогда не возвращаются обратно в коробку Ubuntu.

Что мне не хватает?

Вот настройка маршрутизатора 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

И вот коробка 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

Редактировать: Следуя совету Патрика, я сделал tcpdump с коробкой Ubuntu и вижу это:

# 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

Таким образом, вопрос заключается в следующем: если кажется, что все пакеты приходят и уходят, почему ping сообщает о 100% потере пакетов?

— Эль Барто
источник

как выглядит ваш конфиг iptables? Вы блокируете пакеты ICMP?

— Zypher

Нет я не. Я только что добавил вывод iptables -L -nдля маршрутизатора Debian. Пусто.

— Эль Барто

MASQUERADE all -- 10.1.1.0/24 !10.1.1.0/24 MASQUERADE all -- !10.1.1.0/24 10.1.1.0/24

— Эль Барто

1

А как насчет tcpdump из 'Ubuntu Box'? Tcpdump из 'debian router' ясно показывает отправляемые ответные пакеты. Tcpdump работает за пределами фильтрации на уровне ядра, поэтому, если ядро по какой-либо причине отбрасывает ответы, tcpdump в 'ubuntu box' должен по крайней мере показать, что они попадают в коробку. С другой стороны, вы предоставили много полезной информации в очень ясной форме, приятно иметь ее здесь.

— Патрик

Спасибо, Патрик. Я сделал tcpdump на коробке Ubuntu, и пакеты, кажется, возвращаются, но ping все еще показывает 100% -ую потерю пакетов.

— Эль Барто

9

Из вашего вопроса в комментариях:

На удаленном сервере я вижу запросы и ответы. Но на маршрутизаторе Debian я ничего не вижу ... ни на одном из интерфейсов! Я предполагаю, что теперь окно Ubuntu общается напрямую с маршрутизатором на 192.168.1.1 через отправку запросов с IP 10.1.1.12, поэтому он не может маршрутизировать обратно. Но почему??

С сервера 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

В то время, когда вы захватили эту таблицу маршрутизации, у вас будет более низкий показатель по умолчанию, eth0поскольку вы указываете на свой маршрутизатор на 192.168.1.1 (т.е. не на машину debian). Сначала следуют значения по умолчанию с более низкой метрикой, что означает, что Ubuntu хочет отправлять весь несвязанный трафик напрямую в 192.168.1.1.

Если у вас есть время простоя, удалите это значение по умолчанию

route del default gw 192.168.1.1 dev eth0

Я все еще пытаюсь решить более серьезную проблему (оригинальные следы сниффера показывают ответы пингов на Ubuntu: eth1, но ОС не принимает пингов). Не могли бы вы пинговать из Ubuntu: eth1 и одновременно записывать в Debian: eth2, чтобы продемонстрировать, что происходит с NAT после того, как вы заставили Ubuntu снова отправлять весь трафик через Debian?

— Майк Пеннингтон
источник

Спасибо, ваш ответ о метрике был полезен. Прямо сейчас я не могу удалить маршрут по умолчанию через 192.168.1.1, но я проверю это позже. В настоящее время tcpdump в Debian: eth2 ничего не показывает, (я думаю), потому что пакеты отправляются напрямую в 192.168.1.1. Но то, что произошло раньше, находится на моем первоначальном посте. Проверьте, где написано: «С маршрутизатора Debian я вижу это».

— Эль Барто

Трудно сказать об исходной проблеме ... мое предложение: перебазировать все после того, как вы удалите значение по умолчанию ... сделать все ваши перехватчики снимают сразу. Кроме того, если возможно, получите информацию о MAC-адресе src / dest в дополнение к IP-адресам src / dest ... идеальный мир - использовать tshark(wireshark в текстовом режиме), и вы можете указать, какие поля вы хотите захватить ... см. Мой вопрос здесь для примера. Наконец, можете ли вы пинговать другие пункты назначения в Интернете, когда возникает проблема?

— Майк Пеннингтон

Спасибо, Майк. Я проверю маршрут без маршрута по умолчанию через пару часов, когда люди покинут офис. Что касается других направлений, это смешно. Я только что попытался пропинговать google.com, и я получаю тот же результат, что и раньше, пинговал свой удаленный сервер: я вижу, как ICMP-пакеты приходят и проходят через соответствующие интерфейсы, но pingвсе еще показывают 100% -ную потерю пакетов. Я предполагаю, что эта разница между Google и моим удаленным сервером связана с кэшем маршрутов. Я прав?

— Эль Барто

Пока не могу сказать о причине неудачных пингов ... У меня недостаточно доказательств. Это необычная проблема ... несколько предложений, чтобы помочь диагностировать. Используйте, ping -v <destination>чтобы узнать, получаете ли вы больше диагностики причин сбоя эхолотов ... Также, пожалуйста, пройдите ваши эхо-запросы, начиная с localhost, затем ubuntu ethernet ip addr, затем gw по умолчанию, один прыжок после и так далее, пока вы не найдете, где они начать терпеть неудачу. Кроме того, пожалуйста, не указывайте интерфейс, когда вы это делаете ...

— Майк Пеннингтон

Я проверю через пару часов. В настоящее время, если я пингую без указания интерфейса, он будет маршрутизироваться через шлюз по умолчанию, который является 192.168.1.1.

— Эль Барто

8

Вы проверили, включена ли фильтрация обратного пути в Ubuntu?

Это параметр sysctl ( net.ipv4.conf.all.rp_filter), он будет фильтровать входящие пакеты, если исходный адрес входит на «неправильный» интерфейс (т. Е. Не на тот интерфейс, на который ядро будет направлять его)

Вы также net.ipv4.conf.all.log_martians=1можете попытаться увидеть, что происходит.

— Йерун ван Беммель
источник

1

Этот комментарий направил меня в правильном направлении, но я должен был отключить его для конкретного интерфейса, например:sysctl net.ipv4.conf.eth1.rp_filter=0

— konrad

2

Ключом к выполнению этой работы является создание отдельных таблиц маршрутизации для различных интерфейсов и указание сетевому стеку использовать эти таблицы маршрутизации вместо таблицы по умолчанию.

В вашем случае это должно заставить ping -I eth2 8.8.8.8работать:

# 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

Дополнительную информацию о маршрутизации для нескольких восходящих каналов можно найти в LARTC HOWTO: http://lartc.org/howto/lartc.rpdb.multiple-links.html.

— Konrad
источник

-1

Если ваш iptables полностью пуст (кроме оператора masquerade), вам, вероятно, потребуется добавить цепочку FORWARDING, чтобы разрешить трафик через блок. Попробуйте начать с известной рабочей конфигурации

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

Это также включает подтверждение того, что вы настроены на пересылку в sysctl и тому подобное.

— rnxrx
источник

Для цепочки FORWARD установлена политика ACCEPT, это нормально. Tcpdump также показывает, что пакеты правильно пересылаются (в обоих направлениях).

— Патрик

Может быть, я что-то упустил, но ваш маршрут по умолчанию из коробки Ubuntu проходит через отдельный маршрутизатор, а не коробку Debian. В поле Ubuntu вы указываете, что хотите получать пакеты от 10.1.1.12, но ваш маршрут по умолчанию - через 192.168.1.1. Если вы хотите, чтобы маршрутизатор Debian транслировал этот трафик, то хост Ubuntu должен маршрутизировать свой исходящий трафик через это устройство, а не через маршрутизатор. Попробуйте добавить маршрут к вашему удаленному серверу через окно Debian и посмотрите, как это работает.

— rnxrx

Дело в том, что коробка Debian в настоящее время находится за другим маршрутизатором. Таким образом, путь, по которому должны следовать пакеты, идет от блока Ubuntu к блоку Debian, через другой маршрутизатор к удаленному серверу в Интернете (и обратно). Судя по тому, что я вижу в tcpdump, это работает, но в какой-то момент чего-то не хватает, потому что pingсообщает о потерянных пакетах.

— Эль Барто

-1

Вам нужно настроить NAT.

В типичной конфигурации локальная сеть использует одну из назначенных «частных» подсетей IP-адресов. Маршрутизатор в этой сети имеет частный адрес в этом адресном пространстве. Маршрутизатор также подключен к Интернету по «общедоступному» адресу, назначенному поставщиком услуг Интернета. Когда трафик проходит из локальной сети в Интернет, адрес источника в каждом пакете на лету преобразуется из частного адреса в публичный адрес. Маршрутизатор отслеживает основные данные о каждом активном соединении (в частности, адрес и порт назначения). Когда ответ возвращается к маршрутизатору, он использует данные отслеживания соединения, которые он сохранил во время исходящей фазы, чтобы определить частный адрес во внутренней сети, на который следует переслать ответ.

— Джерри
источник

NAT уже настроен. Обратите внимание, что пакеты как в tcpdump на маршрутизаторе, так и в tcpdump на удаленном сервере показывают пакеты, которые были SNATed по новому адресу. Tcpdumps также показывает, что возвращаемые пакеты должным образом восстановлены.

— Патрик