Linux 라우터 : 핑이 다시 라우팅되지 않습니다

14

라우터로 설정하려고하는 데비안 상자와 클라이언트로 사용하는 우분투 상자가 있습니다.

내 문제는 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를 변경했습니다).

데비안 라우터에서 나는 이것을 본다 :

# 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입니다. 그래서 내가 이해하는 것은 핑 패킷이 우분투 상자 (10.1.1.12)에서 라우터 (10.1.1.1)로, 거기에서 다음 라우터 (192.168.1.1)로 그리고 원격 서버 (XXXX)에 도달한다는 것입니다 ). 그런 다음 데비안 라우터로 돌아 왔지만 우분투 상자에는 결코 도달하지 않습니다.

내가 무엇을 놓치고 있습니까?

데비안 라우터 설정은 다음과 같습니다.

# 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

우분투 상자는 다음과 같습니다.

# 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를 수행했으며 이것을 봅니다.

# 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

따라서 모든 패킷이오고가는 것처럼 보이는 경우 핑이 100 % 패킷 손실을보고하는 이유는 무엇입니까?

debian  router  local-area-network  ping 
— 엘 바르 토
소스
iptables 구성은 어떻게 생겼습니까? 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는 커널 레벨 필터링 외부에서 작동하므로 커널이 어떤 이유로 든 응답을 삭제하는 경우 'ubuntu box'의 tcpdump는 최소한 상자에 표시해야합니다. 또 다른 참고로, 당신은 매우 유용한 방법으로 많은 유용한 정보를 제공했습니다.
— Patrick
감사합니다, @Patrick. 우분투 상자에서 tcpdump를했는데 패킷이 다시 오는 것처럼 보이지만 핑은 여전히 ​​100 % 패킷 손실을 보여줍니다.
— El Barto

답변:

9

의견에 대한 귀하의 질문에서 :

원격 서버에서 요청과 응답을 볼 수 있습니다. 그러나 데비안 라우터에서는 아무것도 보이지 않습니다 ... 인터페이스에는 없습니다! 내 생각에 우분투 상자는 IP 10.1.1.12로 요청을 보내야 192.168.1.1에서 라우터와 직접 통신하므로 다시 라우팅 할 수 없습니다. 그런데 왜 ??

우분투 서버에서 :

# 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

나는 여전히 더 큰 문제에 끓고 있습니다 (원래 스니퍼 추적은 우분투 : eth1에 대한 핑 응답을 보여 주지만 OS에서 핑을 허용하지 않습니다). Ubuntu : eth1에서 Ping을 수행하고 Debian : eth2에서 동시에 캡처하여 Ubuntu가 데비안을 통해 모든 트래픽을 다시 보내도록 강제 한 후 NAT에서 발생하는 상황을 보여줄 수 있습니까?

— 마이크 페닝 턴
소스
감사합니다. 측정 항목에 대한 답변이 도움이되었습니다. 지금은 192.168.1.1을 통해 기본 경로를 제거 할 수 없지만 나중에 확인하겠습니다. 패킷이 192.168.1.1로 직접 전송되기 때문에 현재 데비안 : eth2의 tcpdump는 아무것도 표시하지 않습니다. 그러나 이전에 일어난 일은 내 원래 게시물에 있습니다. "데비안 라우터에서 이것을 볼 수 있습니다"라고 표시되어 있는지 확인하십시오.
— El Barto 2016 년
원래 문제에 대해 말하기는 어렵습니다 ... 내 제안 : 기본값을 제거한 후 모든 것을 리베이스 라인하십시오 ... 한 번에 모든 스니퍼 캡처를 수행하십시오. 또한 가능한 경우 src / dest IP 외에도 src / dest mac-address 정보를 얻을 수 있습니다 ... 완벽한 세상은 tshark(텍스트 모드의 wireshark )를 사용 하고 캡처하려는 필드를 지정할 수 있습니다 ... 내 참조 예를 들어 여기 에 질문하십시오 . 마지막으로, 문제가 발생했을 때 인터넷에서 다른 대상을 핑할 수 있습니까?
— Mike Pennington 2016 년
고마워, 마이크 사람들이 퇴근 할 때 몇 시간 안에 기본 경로없이 확인하겠습니다. 다른 목적지에 관해서는 재미있다. 방금 google.com을 핑하려고 시도했는데 이전에 원격 서버를 핑한 것과 동일한 결과를 얻었습니다. ICMP 패킷이 적절한 인터페이스를 통해오고 있지만 ping여전히 100 % 패킷 손실을 볼 수 있습니다. Google과 원격 서버 의이 차이점은 경로 캐시와 관련이 있다고 생각합니다. 내가 맞아?
— El Barto 2016 년
아직 핑 실패의 이유에 대해 말할 수 없습니다 ... 충분한 증거가 없습니다. 이것은 비정상적인 문제입니다 ... 진단에 도움이되는 몇 가지 제안입니다. 사용은 ping -v <destination>당신이 핑이 실패하는 이유에 대한 자세한 진단을받을 경우에도 다음 우분투 이더넷 IP ADDR, 디폴트 GW는 한 홉 후, 등등 당신이 찾을 때까지, 로컬 호스트로 시작하여 ping을 수행하세요 ... 볼 수 있습니다 어디 실패하기 시작합니다. 또한 그렇게 할 때 인터페이스를 지정하지 마십시오.
— Mike Pennington
몇 시간 후에 확인하겠습니다. 현재 인터페이스를 지정하지 않고 핑 (ping)하면 기본 게이트웨이 인 192.168.1.1을 통해 라우팅됩니다.
— El Barto 2016 년
8

우분투 상자에서 역방향 경로 필터링 이 활성화되어 있는지 확인 했습니까 ?

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는 또한 패킷이 올바르게 전달되고 있음을 보여줍니다 (양방향).
— Patrick
어쩌면 내가 놓친 것이 있지만 우분투 상자의 기본 경로는 데비안 상자가 아닌 별도의 라우터를 사용하는 것입니다. Ubuntu 상자에서 패킷을 10.1.1.12에서 소스로 지정하지만 기본 경로는 192.168.1.1을 통해 지정합니다. 데비안 라우터가이 트래픽을 변환하게하려면 우분투 호스트는 라우터가 아닌 해당 장치를 통해 아웃 바운드 트래픽을 라우팅해야합니다. 데비안 상자를 통해 원격 서버에 경로를 추가하고 어떻게 작동하는지 확인하십시오.
— rnxrx 2016 년
문제는 데비안 박스가 현재 다른 라우터 뒤에 있다는 것입니다. 따라서 패킷이 따라야 할 경로는 우분투 상자에서 데비안 상자로, 다른 라우터를 통해 인터넷의 원격 서버로 (그리고 다시) 경로입니다. 내가 tcpdump에서 본 것에서 이것은 작동하는 것처럼 보이지만 어느 시점 ping에서 패킷이 손실 된 것으로보고 하기 때문에 누락 된 것이 있습니다.
— El Barto
-1

NAT를 구성해야합니다.

일반적인 구성에서 로컬 네트워크는 지정된 "개인"IP 주소 서브넷 중 하나를 사용합니다. 해당 네트워크의 라우터는 해당 주소 공간에 개인 주소가 있습니다. 라우터는 인터넷 서비스 제공 업체가 할당 한 "공용"주소로 인터넷에 연결되어 있습니다. 트래픽이 로컬 네트워크에서 인터넷으로 전달 될 때 각 패킷의 소스 주소는 개인 주소에서 공개 주소로 즉시 변환됩니다. 라우터는 각 활성 연결 (특히 대상 주소 및 포트)에 대한 기본 데이터를 추적합니다. 응답이 라우터로 돌아 오면 아웃 바운드 단계에서 저장 한 연결 추적 데이터를 사용하여 응답을 전달할 내부 네트워크의 개인 주소를 결정합니다.

— 작은 권총
소스
NAT가 이미 구성되어 있습니다. 라우터의 tcpdump와 원격 서버의 tcpdump 모두에있는 패킷은 새 주소로 SNAT 된 패킷을 보여줍니다. tcpdump는 리턴 패킷이 올바르게 복원되고 있음을 보여줍니다.
— Patrick
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.