ifcfg-eth0.200がarpブロードキャストに応答しない
次のようなセットアップで、Centosルーターがすばらしい仕事をしています。 eth0-> IPなし eth0.200-> 192.168.200.1 eth0.201-> 192.168.201.1 ...など eth0.213-> 192.168.213.1 IPv4転送を有効にして、intervlanルーティングを許可します。 eth1-> IPなし eth1.201-> 10.1.29.40 eth0.202-> 10.1.29.48 ...など eth0.213-> 10.1.29.136 iptablesは、10.198.29.138から10.198.29.142の範囲のIPをパブリックIPとして使用して、eth0ネットワークのいずれかがインターネットから何かを探すときにSNATを実行します。すべてがうまく機能します。問題は、eth1にVLANインターフェイス192.168.200.1が必要だということです。ifcfg-eth1.200に移動すると、パケットキャプチャで、多くのクライアントがどのMACアドレスが192.168.200.1に属しているかを尋ねることでARPテーブルを埋めようとしますが、eth1.200は応答しません。ARPブロードキャストに応答する他のeth0.XXXが表示されますが、200は表示されません。iptablesの問題なのでしょうか? 私のiptablesは次のようになります: 編集/ 解像度の概要デイヴィッド・ハウのコメントに感謝 sysctl -w net.ipv4.conf.eth0 / 202.rp_filter = 0コマンドが何をするかという別の問題のトラブルシューティングをしながら、私は自分で実験することができました。 SERVER <==eth0||eth1==> MAC FF:11 || MAC FF:22 IP 1.1.1.1 || IP 3.3.3.1 eth0が3.3.3.1のARP要求を受信した場合、サーバーはデフォルトでそれに応答しません。リバースパスフィルターを無効にした後、サーバーはeth0上のARP要求に「ちょっと、IP 3.3.3.1はMAC FF:11にあります」と応答しますが、実際にはeth1にあります。 次に、MAC FF:11およびIP 3.3.3.1宛てのeth0に次のパケットが到着します。ルーティングテーブルのため、3.3.3.x IPに戻るものはすべてeth1になります。そのため、私のパケットはブラックホールですが、それは別の話です。 …