別のVLANは独自のDHCPサーバーを使用します。何らかの理由で、キックスタートクライアントがプライマリDHCPサーバーからIPの割り当てを取得し続けたキックスタートネットワークを構築しています。
私が設定した方法は、このルーターにプライマリDHCPサーバーがあることです。
192.168.15.1
そのDHCPサーバーに接続されているのは、IPが192.168.15.2のスイッチです。私のキックスタート(Scientific Linux)サーバーは、2つのポートでそのスイッチに接続されています。
ポート2-キックスタートサーバーがeth0を介して本番ネットワークの残りの部分と通信する場所。そのインターフェース上のサーバーに割り当てられたIPは192.168.15.100(eth0上)です。詳細は次のとおりです。
Interface: eth0
IP: 192.168.15.100
Netmask: 255.255.255.0
Gateway: 192.168.15.1
ポート7-独自のVLAN ID(ポート8とともに)があります。キックスタートサーバーは、IP 172.16.15.100(eth1)でそのポートに接続されています。詳細は次のとおりです。
Interface: eth1
IP: 172.16.15.100
Netmask: 255.255.255.0
Gateway: none
キックスタートサーバーは独自のDHCPサーバーを実行し、それらをeth1を介して割り当てます。ほとんどのキックスタートは、ポート8を介してキックスタートVLANを介して構築されます。キックスタートDHCPサーバーが実稼働ネットワークを介してアドレスを割り当てないようにするために、次のようにルートを設定します。
route add -Host 255.255.255.255 dev eth1
この時点で、クライアントは192.168.15.1DHCPサーバーから割り当てIPを取得し続けました。クライアント要求がそのDHCPに到達するのをブロックする方法を理解する必要があります。ただし、キックスタートサーバーにもKVMホストを構築するため、これらのKVMには、ブリッジを介して192.168.15.1DHCPサーバーからDHCP要求を取得する機能が必要です。この特定の問題の解決が完了すると、ネットワークになります(現在、NAT経由で通信します)。
では、これを解決するために何が行われるでしょうか? iptablesまたはある種のルーティングを介して入力する必要がありますか?
そのインターフェイスでIPtablesを介したリクエストに制限し、172.16.15.xネットワークのDHCPリクエストを許可しようとしました。
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 69 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 69 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 68 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 68 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 67 -j ACCEPT
そして、192.168.15.xネットワークからのeth1での割り当てを拒否します。
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 69 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 69 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 68 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 68 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 67 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 67 -j REJECT
いいえ。 :(
わかりました。デフォルトのVLANのタグを解除しなかったため、デフォルトのVLANからのトラフィックがキックスタートVLANに流れ込みました。
これは修正されました。 DHCP割り当てはこれらのポートでは機能しなくなりましたが、少なくとも私は問題を認識しています。 :)
VLANの問題を解決できてうれしいですが、ebtablesを使用してDHCPトラフィックをフィルタリングできることを知りたいと思うかもしれません。
たとえば、Linuxサーバー上のデバイスtap0によってブリッジされた2つの異なるLANに2つのDHCPサーバーがある場合、それらを分離し、次を実行することでTCP/IPおよびARPトラフィックの流れを維持できます。
modprobe ebtables && modprobe ebtable_filter && modprobe ebt_ip
ebtables -A INPUT --in-interface tap0 \
--protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 \
--protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 \
-j DROP
ebtables -A FORWARD --in-interface tap0 \
--protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 \
-j DROP
ebtables -A FORWARD --in-interface tap0 \
--protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
この例では、帯域幅を無駄にしないように両端でebtablesを実行する必要がありますが、DHCPの問題は1つだけで解決できます。