내부 eth1 인터페이스에서 외부 ppp0 인터페이스로의 라우팅 문제

내부 eth1 인터페이스에서 외부 ppp0 인터페이스로의 라우팅 문제

ppp 링크를 사용하여 두 개의 LAN을 연결하려고 합니다. 기본 네트워크 토폴로지 다이어그램이 있지만 잘 작동하지 않습니다. 이것은 볼 수 있습니다여기.

Routing Problem
================


172.20.0.0/16                                 192.168.2.0/24
              eth1  +-----------------+ eth0                                                  
  172.20.0.1 |======|      Ubuntu     |======| 192.168.2.231
                    |                 |
                    |      Router     |======| 192.168.254.253    192.168.254.254 |=====> To: 172.30.0.0/16
                    +-----------------+ ppp0

172.20.0.0/16 서브넷의 모든 컴퓨터는 eth0을 통해 인터넷에 액세스할 수 있습니다. 172.20.0.0/16 서브넷의 모든 장치는 172.20.0.1을 게이트웨이로 사용합니다. 172.20.0.0/16 서브넷의 장치에서 172.30.0.0/16 서브넷의 장치를 ping하면 eth1에서 ppp0으로 아무 것도 표시되지 않습니다. 제가 테스트한 방법은 172.20.0.0/16 서브넷( )의 장치에서 핑을 보내고 tcpdump( )를 사용하여 ping -s 10240 172.30.0.9라우터의 세 인터페이스를 모두 확인하는 것이었습니다. tcpdump -vv -x -X -s 1500 -i eth1이 인터페이스 중 어느 것에도 ICMP 패킷이 표시되지 않습니다. 문제는 iptables에 있는 것 같습니다.

Ubuntu 라우터의 구성은 다음과 같습니다.

ip route show
default via 192.168.2.1 dev eth0 
172.20.0.0/16 dev eth1  proto kernel  scope link  src 172.20.0.1 
172.30.0.0/16 dev ppp0  scope link 
172.30.0.0/16 via 192.168.250.254 dev ppp0 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.231 
192.168.250.254 dev ppp0  proto kernel  scope link  src 192.168.250.253


cat /proc/sys/net/ipv4/ip_forward 
1
cat /proc/sys/net/ipv4/conf/ppp0/forwarding 
1
cat /proc/sys/net/ipv4/conf/eth0/forwarding
1
cat /proc/sys/net/ipv4/conf/eth1/forwarding
1


iptables --list-rules
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -j ACCEPT
-A FORWARD -i eth1 -o ppp0 -j ACCEPT
-A FORWARD -i ppp0 -o eth1 -j ACCEPT

iptables -t nat --list-rules
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -d 192.168.250.254/32 -j DNAT --to-destination 172.30.0.1
-A POSTROUTING -o eth1 -j SNAT --to-source 172.20.0.1

iptables 규칙의 다양한 조합과 다양한 라우팅 옵션을 시도했다는 점을 덧붙이고 싶습니다.

답변1

첫째, 필터링 규칙이 다소 중복됩니다. 결코 포기하지 않고 전략이 수용이라면 더 많은 수용 규칙을 추가할 필요가 없습니다. 패킷이 필터링되지 않습니다.

제가 테스트한 방법은 172.20.0.0/16 서브넷의 장치에서 핑을 보내는 것이었습니다( ping -s 10240 172.30.0.9 ).

나는 실제로 네트워크를 통해 거대한 10kByte 핑 청크를 보내려고 시도한 적이 없습니다. 왜 그렇게 하려는지는 모르겠지만 56바이트의 표준 핑 패킷은 연결을 확인하기 위해 완벽하게 작업을 수행해야 하며 아마도 실행되지 않을 것입니다. MTU 조각화 문제로.

그리고 tcpdump( tcpdump -vv -x -X -s 1500 -i eth1 )를 사용하여 라우터의 세 인터페이스를 모두 확인하세요.

물론 확인할 때는 tcpdump -i eth1 ...그냥 확인만 하겠지만 eth1그건 사소한 일이다.

필터링 규칙이 없으므로 iptables에는 문제가 없습니다. 최소한 일부 인터페이스에 일부 입력이 있어야 합니다.

Ping이 전송되는 경로를 확인하셨나요?

규칙 뒤에 숨겨진 아이디어를 이해하지 못합니다.

-A PREROUTING -d 192.168.250.254/32 -j DNAT --to-destination 172.30.0.1

즉, 192.168.250.254로 주소가 지정된 패킷(따라서 ppp0을 통해 나가려는 모든 패킷)은 172.30.0.1로 이동하도록 다시 작성되며 이 역시 ppp0이어야 합니다(불분명!). 나중에 라우팅 단계에서 ppp0 서브넷 172.30.0.0/16으로 전송된 모든 패킷은 192.168.250.254로 라우팅됩니다. 이 규칙은 나에게 파괴적이지는 않더라도 쓸모가 없습니다.

172.30.0.9 또는 172.30.0.0/16으로 패키지를 보낼 때 -j MASQUERADE목적지가 패키지를 라우팅하는 방법을 모르더라도 떠날 때 응답할 위치를 알기를 원할 것입니다.

`iptables -t nat -A POSTROUTING -s 172.20.0.0/16 -i ppp0 -j MASQUERADE`

그러나 이것은 라우터의 인터페이스에서 ping 패킷이 표시되지 않는 문제를 해결하지 못합니다.

나의 첫 번째 시도는 해당 시스템에서 tcpdump를 사용하여 내가 보낸 시스템에서 나가는 ping 패킷을 확인하는 것이었습니다.

`tcpdump -i eth0 'icmp'

또는 ppp0을 초과하는 패키지만

`tcpudmp -i eth0 'net 172.30.0.0/16'

172.20.0.0/16 호스트(라우터 아님)에 eth0이라는 인터페이스가 하나만 있다고 가정합니다.

관련 정보