เราเตอร์ Linux: ping ไม่ได้เปลี่ยนเส้นทาง

14

ฉันมีกล่อง Debian ที่ฉันพยายามตั้งค่าเป็นเราเตอร์และกล่อง Ubuntu ที่ฉันใช้เป็นลูกค้า

ปัญหาของฉันคือเมื่อไคลเอนต์ Ubuntu พยายามที่จะ ping เซิร์ฟเวอร์บนอินเทอร์เน็ตแพ็คเก็ตทั้งหมดจะหายไป (แม้ว่าตามที่คุณเห็นด้านล่างพวกเขาดูเหมือนจะไปที่เซิร์ฟเวอร์และกลับมาโดยไม่มีปัญหา)

ฉันกำลังทำสิ่งนี้ในกล่อง 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 ) จากนั้นพวกเขากลับมาถึงเราเตอร์เดเบียน แต่พวกเขาไม่เคยไปถึงกล่อง 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

แก้ไข: ทำตามคำแนะนำของ Patrick ฉันทำ 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 config ของคุณเป็นอย่างไร คุณปิดกั้นแพ็คเก็ต ICMP หรือไม่

— Zypher

ไม่ฉันไม่ใช่. ฉันเพิ่งเพิ่มเอาท์พุทของiptables -L -nสำหรับเราเตอร์เดเบียน มันว่างเปล่า.

— El Barto

ฉันเป็นคน แต่ไม่ได้ทำอย่างนั้นเหรอ?: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 จาก 'กล่องอูบุนตู'? tcpdump จาก 'เราเตอร์เดเบียน' จะแสดงแพ็กเก็ตตอบที่ถูกส่งอย่างชัดเจน Tcpdump ทำงานนอกการกรองระดับเคอร์เนลดังนั้นหากเคอร์เนลปล่อยคำตอบไม่ว่าด้วยเหตุผลใดก็ตาม tcpdump บน 'กล่องอูบุนตู' อย่างน้อยก็ควรแสดงให้พวกมันทำในกล่อง ในบันทึกอื่นคุณได้ให้ข้อมูลที่เป็นประโยชน์มากมายอย่างชัดเจนดีที่ได้มาที่นี่

— แพทริค

ขอบคุณ @ แพทริค ฉันทำ tcpdump บนกล่อง Ubuntu และแพ็คเก็ตดูเหมือนจะกลับมา แต่ ping ยังคงแสดงแพ็กเก็ตที่สูญหาย 100%

— El Barto

9

จากคำถามของคุณในความคิดเห็น:

บนเซิร์ฟเวอร์ระยะไกลฉันเห็นคำขอและคำตอบ แต่ในเราเตอร์เดเบียนฉันไม่เห็นอะไรเลย ... บนอินเตอร์เฟสใด ๆ ! ฉันเดาว่าตอนนี้กล่อง 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 (นั่นไม่ใช่เครื่องเดเบียน) ค่าเริ่มต้นของตัวชี้วัดที่ต่ำกว่านั้นจะถูกติดตามก่อนเสมอซึ่งหมายความว่า Ubuntu ต้องการส่งทราฟฟิกที่ไม่ได้เชื่อมต่อทั้งหมดไปยัง 192.168.1.1 โดยตรง

เมื่อคุณมีเวลาหยุดทำงานโปรดลบค่าเริ่มต้นนั้นด้วย

route del default gw 192.168.1.1 dev eth0

ฉันยังคงเดือดร้อนกับปัญหาที่ใหญ่กว่า (ร่องรอยการดมกลิ่นดั้งเดิมแสดงคำตอบ ping บน Ubuntu: eth1 แต่ไม่มีระบบส่ง Ping ที่ยอมรับได้) โปรด ping จาก Ubuntu: eth1 และจับบน Debian: eth2 พร้อมกันเพื่อแสดงให้เห็นว่าเกิดอะไรขึ้นกับ NAT หลังจากที่คุณบังคับให้ Ubuntu ส่งปริมาณการรับส่งข้อมูลทั้งหมดผ่าน Debian อีกครั้งหรือไม่

— ไมค์เพนนิงตัน
แหล่งที่มา

ขอบคุณคำตอบของคุณเกี่ยวกับตัวชี้วัดนั้นมีประโยชน์ ตอนนี้ฉันไม่สามารถลบเส้นทางเริ่มต้นผ่าน 192.168.1.1 แต่ฉันจะตรวจสอบในภายหลัง ปัจจุบัน tcpdump บน Debian: eth2 ไม่แสดงอะไรเลย (ฉันคิดว่า) เพราะแพ็กเก็ตถูกส่งโดยตรงไปที่ 192.168.1.1 แต่สิ่งที่เกิดขึ้นก่อนหน้านี้อยู่ในโพสต์ต้นฉบับของฉัน ตรวจสอบว่ามีข้อความว่า "จาก Debian Router ฉันเห็นสิ่งนี้"

— El Barto

เป็นการยากที่จะพูดเกี่ยวกับปัญหาดั้งเดิม ... คำแนะนำของฉัน: ทำการใส่ใหม่ทุกอย่างหลังจากคุณลบค่าเริ่มต้น ... ทำการดักจับการดมกลิ่นของคุณทั้งหมดในครั้งเดียว นอกจากนี้ถ้าเป็นไปได้รับข้อมูลที่อยู่ mac src / dest นอกเหนือจาก src / dest IPs ... โลกที่สมบูรณ์แบบคือการใช้tshark(wireshark ในโหมดข้อความ) และคุณสามารถระบุช่องที่คุณต้องการจับ ... ดูของฉัน คำถามที่นี่เพื่อเป็นตัวอย่าง ในที่สุดคุณสามารถ ping จุดหมายปลายทางอื่น ๆ บนอินเทอร์เน็ตเมื่อเกิดปัญหาหรือไม่

— Mike Pennington

ขอบคุณไมค์ ฉันจะตรวจสอบโดยไม่มีเส้นทางเริ่มต้นภายในไม่กี่ชั่วโมงเมื่อผู้คนออกจากสำนักงาน เกี่ยวกับจุดหมายปลายทางอื่น ๆ มันตลก ฉันเพิ่งพยายาม ping google.com และฉันก็ได้รับผลลัพธ์เช่นเดียวกับที่ฉันเคยส่ง Ping เซิร์ฟเวอร์ระยะไกลของฉัน: ฉันสามารถเห็นแพ็คเก็ต ICMP ที่กำลังมาถึงและผ่านส่วนต่อประสานที่เหมาะสม แต่pingยังคงแสดงว่าแพ็กเก็ตสูญหาย 100% ฉันคาดเดาความแตกต่างระหว่าง Google และเซิร์ฟเวอร์ระยะไกลของฉันเกี่ยวกับเส้นทางแคช ฉันถูกไหม?

— El Barto

ฉันไม่สามารถพูดเกี่ยวกับสาเหตุของการล้มเหลวในการปิงได้ ... ฉันยังไม่มีหลักฐานเพียงพอ นี่เป็นปัญหาที่ผิดปกติ ... คำแนะนำเล็กน้อยเพื่อช่วยในการวินิจฉัย ใช้ping -v <destination>เพื่อดูว่าคุณได้รับการวินิจฉัยมากขึ้นหรือไม่ว่าเหตุใดการ pings จึงล้มเหลว ... นอกจากนี้โปรดเดิน pings ของคุณเริ่มต้นด้วย localhost จากนั้น eubuntu ethernet ip addr จากนั้น gw ที่เป็นค่าเริ่มต้นหนึ่ง hop หลังจากนั้นเป็นต้น เริ่มล้มเหลว นอกจากนี้โปรดอย่าระบุอินเทอร์เฟซเมื่อคุณดำเนินการ ...

— Mike Pennington

ฉันจะตรวจสอบในสองสามชั่วโมง ขณะนี้ถ้าฉัน ping โดยไม่ระบุอินเทอร์เฟซมันจะกำหนดเส้นทางผ่านเกตเวย์เริ่มต้นซึ่งคือ 192.168.1.1

— El Barto

8

คุณตรวจสอบไหม เปิดใช้งานการกรองเส้นทางย้อนกลับในกล่อง Ubuntu หรือไม่

มันคือการตั้งค่า sysctl (net.ipv4.conf.all.rp_filter ) มันจะกรองแพ็กเก็ตขาเข้าหากที่อยู่แหล่งที่มาเข้ามาในอินเตอร์เฟส "ผิด" (เช่นไม่ใช่อินเตอร์เฟสที่เคอร์เนลกำหนดเส้นทาง)

คุณสามารถลองnet.ipv4.conf.all.log_martians=1ดูว่าเกิดอะไรขึ้น

— Jeroen van Bemmel
แหล่งที่มา

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 ของคุณว่างเปล่าอย่างสมบูรณ์ (นอกเหนือจากคำสั่ง masquerade) คุณอาจต้องเพิ่มเครือข่าย FORWARDING chain เพื่ออนุญาตการรับส่งข้อมูลผ่านช่อง ลองเริ่มจากการกำหนดค่าการทำงานที่รู้จัก

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

ซึ่งรวมถึงการยืนยันว่าคุณตั้งค่าให้ส่งต่อใน sysctl และอื่น ๆ

— rnxrx
แหล่งที่มา

ห่วงโซ่ไปข้างหน้ามีนโยบายที่กำหนดเป็นที่ยอมรับก็ดี tcpdump ยังแสดงแพ็กเก็ตที่ถูกส่งต่ออย่างเหมาะสม (ทั้งสองทิศทาง)

— Patrick

บางทีฉันอาจจะพลาดบางอย่าง แต่เส้นทางเริ่มต้นของคุณจากกล่อง Ubuntu นั้นผ่านเราเตอร์แยกต่างหากไม่ใช่กล่องเดเบียน บนกล่อง 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 ยังแสดงแพ็กเก็ตส่งคืนที่ถูกกู้คืนอย่างเหมาะสม

— Patrick