Роутер Linux: ping не повертається назад

14

У мене є поле Debian, яке я намагаюся налаштувати як маршрутизатор, і поле Ubuntu, яке я використовую як клієнт.

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

Я роблю це у вікні Ubuntu:

# 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 con поле 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?

— Зіфер

Ні. Я щойно додав вихід 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» повинен хоча б показувати їх, роблячи це у вікні. З іншого приводу, ви дуже чітко надали багато корисної інформації, приємно мати тут.

— Патрік

Дякую, @Patrick. Я зробив tcpdump у вікні Ubuntu, і пакети, здається, повертаються, але ping все ще показує 100% втрати пакету.

— El Barto

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

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

— Майк Пеннінгтон
джерело

Дякуємо, ваша відповідь про показник була корисною. Зараз я не можу видалити маршрут за замовчуванням через 192.168.1.1, але перевіряю це пізніше. В даний час tcpdump на Debian: eth2 нічого не показує (я думаю), тому що пакети надсилаються безпосередньо на 192.168.1.1. Але те, що було раніше, - на моєму первісному пості. Перевірте, де написано "З маршрутизатора Debian я це бачу".

— Ель Барто

Важко сказати про первісну проблему ... моя пропозиція: переставити все заново, після того як ви видалите за замовчуванням ... зробіть усі ваші нюхальні захоплення одразу. Крім того, якщо можливо, отримайте інформацію src / dest mac-адреси на додаток до IP-адрес src / dest ... ідеальним світом є використання tshark(проводка в текстовому режимі), і ви можете вказати, які поля ви хочете записати ... дивіться мій питання тут для прикладу. Нарешті, чи можете ви проголосувати інші напрямки в Інтернеті, коли проблема виникає?

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

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

— El Barto

Я ще не можу сказати про причину невдач пінгу ... У мене недостатньо доказів. Це незвичайна проблема ... кілька пропозицій, які допоможуть поставити діагноз. Скористайтеся, ping -v <destination>щоб побачити, чи отримаєте ви більше діагностики, чому пінг не виходить ... Також, будь ласка, пройдіться вашими пінгами, починаючи з localhost, потім ubuntu ethernet ip addr, потім gw за замовчуванням, один скачок після і так далі, поки не знайдете, де вони почати провалюватися. Також, будь ласка, не вказуйте інтерфейс, коли ви це робите ...

— Майк Пеннінгтон,

Я перевірю через пару годин. В даний час, якщо я ping, не вказуючи інтерфейс, він буде проходити через шлюз за замовчуванням, який становить 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

— конрад
джерело

-1

Якщо ваші iptables повністю порожні (крім заяви маскараду), вам, ймовірно, потрібно додати ланцюг 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повідомляє про втрачені пакети.

— El Barto

-1

Вам потрібно налаштувати NAT.

У типовій конфігурації локальна мережа використовує одну із призначених «приватних» підмереж IP-адреси. Роутер у цій мережі має приватну адресу в цьому адресному просторі. Маршрутизатор також підключений до Інтернету за допомогою "загальнодоступної" адреси, призначеної постачальником послуг Інтернет. Коли трафік переходить від локальної мережі до Інтернету, адреса джерела у кожному пакеті перекладається з ходу з приватної адреси на загальнодоступну адресу. Маршрутизатор відстежує основні дані про кожне активне з'єднання (зокрема, адреса призначення та порт). Коли відповідь повертається до маршрутизатора, він використовує дані відстеження з'єднання, які зберігаються під час вихідної фази, щоб визначити приватну адресу у внутрішній мережі, на яку переслати відповідь.

— Джеррі
джерело

NAT вже налаштований. Зауважте, що пакети і в tcpdump на маршрутизаторі, і в tcpdump на віддаленому сервері показують, що пакети були SNATed на нову адресу. Tcpdumps також показує, що повернення пакетів належним чином відновлено.

— Патрік