ヘッダー

複数のコンポーネントが独自のネットワークに接続するテスト設定があります。このネットワークのアドレスは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 

編集：2番目

RasPiのインターフェイスには、次のIPがあります。 eth0 = 10.0.101.160 eth1 = 172.25.1.160

平らな：Ping 172.25.1.160が期待どおりに機能します。平均。 ping時間は0.5msです。

Piの送信インターフェイス（10.0.101.160）をpingしても機能します。平均。 ping時間は0.667ミリ秒です。

これは、いくつかのトラフィックが少なくともインターフェイスに行き、再びLANに戻ると仮定できることを意味します。しかし、トラフィックが「WAN」（企業ネットワーク）インターフェイスから出ていない理由はまだ理解されていません。 tcpdump -i eth1を実行すると、会社のネットワークからクライアントをpingするときに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ルールにあることを示しています。以前は有効でしたが、もう有効ではありません。これは元の問題に戻ったことを意味します。