発信UDP 68-> 67(DHCPクライアント)をブロックするとどのような結果が発生しますか?

発信UDP 68-> 67(DHCPクライアント)をブロックするとどのような結果が発生しますか?

DHCPを介してIPアドレスを受信するサーバーがあります。これはうまくいくようで、接続は現時点では大丈夫です。ただし、新しいファイルをインストールした後に再起動しなかったため、/etc/sysconfig/iptablesDHCP機能が現在ブロックされている接続に依存している場合は、次回の再起動時にパニックになることがあります。

私のファイアウォールが次のように発信UDP DHCP接続をブロックしていることを確認しました。

[22994.373788] Firewall: *UDP_OUT Blocked* IN= OUT=enup0 SRC=$OUR_IP DST=$DHCP_SERVER_IP LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=53942 DF PROTO=UDP SPT=68 DPT=67 LEN=308 UID=0 GID=0

DHCPリース更新要求などの一部のDHCPクライアントコマンドである可能性がありますか?

この発信要求をブロックするとどうなりますか?これがDHCPサーバーの実装に関連している場合は、RFC文書でそれをブロックしないように要求するのでしょうか?

関連:起動中にネットワークが起動する前または後にファイアウォールルールが初期化されますか/etc/sysconfig/iptablesiptables.service

できるだけブロックしたいです。それ以外の場合は、ここにリクエストする代わりに許可します。

ベストアンサー1

このアクセスをブロックすると、DHCPクライアントが期限切れになるまでIPアドレスリースを更新できなくなります。

リースの有効期限が切れ、クライアントがまだユニキャストを介してDHCPサーバーに接続できない場合、DHCPクライアントは現在のIPアドレスを構成解除し、ブロードキャストを使用して最初からDHCP要求プロセスを開始するため、パケットアドレスは0.0.0.0になります。 :68 - > 255.255.255.255:67。これは一般的なIPアドレス指定規則に違反するため、Linuxでは、DHCPクライアントは通常のiptablesフィルタリング規則によってブロックされない生のソケットを使用する必要があります。そのネットワークセグメントにIPアドレスが非常に不足していない限り、DHCPサーバーはブロードキャスト要求を受信したときにシステムに対して同じIPアドレスを再発行する可能性があります。

したがって、全体的な効果は、システムがまだそのIPアドレスを取得しますが、システムのDHCPリースが期限切れになるたびに短いが完全に不要なIP接続エラーが発生する可能性があることです。

おすすめ記事