머리말

여러 구성 요소가 자체 네트워크에 연결되는 테스트 설정이 있습니다. 이 네트워크의 주소는 172.25.1.0/24입니다. 전부는 아니지만 대부분의 구성 요소는 여러 표준과 문서에 의해 정의되므로 고정 IP 주소를 갖습니다.

우리 회사의 네트워크는 분명한 이유로 이 기계 네트워크와 분리되어 있지만 다양한 테스트 시나리오의 경우 기계 네트워크 내의 일부 구성 요소는 인터넷과 통신할 수 있어야 합니다.

설정

설정을 위해 USB 이더넷 어댑터(10/100/1000T)를 통해 시스템 네트워크를 RaspberryPi 4(8GiB)에 연결하고 내장 네트워크 어댑터를 WAN 액세스가 가능한 기업 네트워크에 연결했습니다.

아이디어는 Pi가 172.25.1.0/24에서 <anywhere>로의 트래픽을 위장한다는 것입니다.

이 설정은 꽤 오랫동안 작동해 왔지만 최근에는 트래픽 라우팅이 중단되었습니다. 이유는 모르겠습니다.

지적재산권 규칙

이번 주말(지난 주말)까지 작동했던 iptables 규칙을 설정하는 스크립트가 있습니다.

#!/bin/bash

IPTABLES=/sbin/iptables

WANIF='eth0'
LANIF='eth1'

# enable ip forwarding in the kernel
echo 'Enabling Kernel IP forwarding...'
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward

# flush rules and delete chains
echo 'Flushing rules and deleting existing chains...'
$IPTABLES -F
$IPTABLES -X

# enable masquerading to allow LAN internet access
echo 'Enabling IP Masquerading and other rules...'
$IPTABLES -t nat -A POSTROUTING -o $LANIF -j MASQUERADE
$IPTABLES -A FORWARD -i $LANIF -o $WANIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $WANIF -o $LANIF -j ACCEPT

$IPTABLES -t nat -A POSTROUTING -o $WANIF -j MASQUERADE
$IPTABLES -A FORWARD -i $WANIF -o $LANIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $LANIF -o $WANIF -j ACCEPT

$IPTABLES -A INPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

echo 'Done.'

생성된 iptables 규칙은 다음과 같습니다.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate NEW,RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination    

내가 아는 한, 이는 모든 트래픽을 eth1(LAN)에서 eth0(WAN)으로 라우팅해야 합니다. 이는 정확히 이전에 수행했던 작업입니다. 하지만 Google의 DNS에 ping을 시도하면 다음과 같은 결과가 나타납니다.

ping -I eth0 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
1317 packets transmitted, 0 packets received, 100% packet loss

이 문제에 대한 도움을 주시면 대단히 감사하겠습니다. 패킷 전달/마스커레이딩이 없으면 가장 중요한 테스트를 실행할 수 없습니다. 감사해요!

편집하다

요청된 출력에 따르면 ip route:

0.0.0.0/24 via 10.0.101.1 dev eth0 
default via 10.0.101.1 dev eth0 
10.0.101.0/24 dev eth0 proto kernel scope link src 10.0.101.160 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.25.1.0/24 dev eth1 proto kernel scope link src 172.25.1.160 

편집: 두 번째

RasPi의 인터페이스에는 다음 IP가 있습니다. eth0 = 10.0.101.160 eth1 = 172.25.1.160

평평한:Ping 172.25.1.160이 예상대로 작동합니다. 평균. 핑 시간은 0.5ms입니다.

Pi의 발신 인터페이스(10.0.101.160)를 핑해도 작동합니다. 평균. 핑 시간은 0.667밀리초입니다.

이는 일부 트래픽이 최소한 인터페이스로 갔다가 다시 LAN으로 돌아간다고 가정할 수 있음을 의미합니다. 그러나 트래픽이 "WAN"(기업 네트워크) 인터페이스를 벗어나지 않는 이유를 여전히 이해하지 못합니다. tcpdump -i eth1을 실행하면 회사 네트워크에서 클라이언트를 핑할 때 ARP 요청이 이 인터페이스에 도착하는 것을 볼 수 있습니다.

13:12:39.660173 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.25.1.57 tell 172.25.1.3, length 46
2 packets captured
492 packets received by filter
484 packets dropped by kernel

그러나 eth0에서 tcpdump를 호출하면 eth1에서 어떤 메시지도 생성되지 않습니다. 나에게 이는 문제가 iptables 규칙에 있음을 나타냅니다. 이전에는 유효했지만 더 이상 유효하지 않습니다. 이는 원래 문제로 돌아갔다는 것을 의미합니다.