Ubuntu 16.04 を実行しています。ufw をインストールして有効にしています。isc-dhcp-server もインストールしています。UDP ポート 67 を開いていないのに、DHCP クライアントはサーバーから DHCP リースを取得できるようです。なぜでしょうか? ufw が作成する IPTABLES を確認したところ、DHCP クライアント用に UDP ポート 68 は開いていますが、UDP ポート 67 は開いていません (私の理解では)。また、ufw が IPTABLES を設定してブロードキャスト トラフィックを受け入れるようには見えません。ufw はブロードキャスト トラフィックを許可するのでしょうか、それともブロックするのでしょうか?
IPTABLES には、UDP ポート 67 トラフィックに対して何らかの特別な例外がありますか?
DHCP クライアントは、最初に UDP ポート 67 のブロードキャストから応答が得られなかった場合、UDP ポート 68 のブロードキャストにフォールバックしますか? そうであれば、DHCP 要求がサーバーに送られていると考えるのが妥当でしょう。なぜなら、その場合、送信 DHCP クライアント要求を許可する UFW ルールによって、受信 DHCP クライアント要求が許可されるからです。
の状態ufw status verboseは
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
答え1
新しい DHCP サーバーのテストを始める前に、ファイアウォールの適切なポートを開くにはあまりにも下手だったので、まだ動作しないはずだと気づくまでに少し時間がかかりました。サーバーのファイアウォールでポート 67 を開いたことがなかったのです。
...
答えは簡単で、DHCPは確かに特別だということです。見知らぬ人が引用した言葉を引用すると、
isc.org の Mark Andrews 氏によると:
「DHCP はパケット フィルターを使用し、これらはファイアウォールの前の IP スタックに結合されます。」
--https://www.centos.org/forums/viewtopic.php?t=8728
これは、DHCP サーバーが raw ソケットを使用するためだとよく言われます。この言い回しは非常に紛らわしいと思います。DHCP サーバーに関する一部の公式 ISC ドキュメントでは、「raw ソケット」を広い意味で使用しています。これは、DHCP サーバーがさまざまなプラットフォームで実行され、さまざまなインターフェイスを使用する必要があるためです。Linux では、raw ソケットと呼ばれるタイプが複数あります。 Linux iptables の影響を受けるものもあれば、影響を受けないものもある。
Linux の TCP/IP スタックは、PF_INET+SOCK_RAW でパケットを送信するときに、いくつかの制限を課すと確信しています。私の漠然とした記憶では、Linux 上の DHCP は必ずしもそのタイプのソケットで動作するとは限らず、代わりに「パケット ソケット」を使用する必要があるかもしれません。パケット ソケットはより低いレベルで動作します。パケット ソケットは iptables の影響を受けないと確信しています。
PF_PACKET ソケットは TCP/IP スタックをバイパスします。
PF_INET/SOCK_RAW ソケットは引き続き TCP/IP スタックを通過します。
--https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html
この引用はパケットの受信という文脈で書かれています。予想どおり、これはパケットの送信にも当てはまるという証拠もあります。
iptables は、PF_INET+SOCK_RAW での送信を含む TCP/IP スタックに適用される制限の 1 つであるようです。
ユーザー空間に IP データグラムがあり、それを send() システム コールを使用して socket(PF_INET, SOCK_RAW, IPPROTO_RAW) で作成された raw ソケット経由で送信する場合、このパケットは netfilter チェーンを通過しますか?
...
良いニュースのようです:
ipt_hook: happy cracking. ipt_hook: happy cracking. ipt_hook: happy cracking. ipt_tcpmss_target: bad length (10 bytes)したがって、パケットは iptables を通過することになります。
https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html
受信方向の証拠:
生のソケットを使用すると、NAT後のパケットが得られるため、IPアドレスはプライベート範囲（私の例では10.xxx）に戻ります。これは常識かもしれませんが、文書化されているものを見つけるのに苦労しました。libpcap/tcpdumpを使用すると、NAT前のパケットが得られます。
[NATはiptablesによって実行されます]
--https://lists.gt.net/iptables/user/62529#62529
ボーナス不満：私は考える最初に引用した「パケット フィルタ」という用語は、長年使われてきたとはいえ、まったくの誤用です。Berkeley Packet Filter は、raw ソケットにフィルタをインストールするために使用するメカニズムです。たとえば、DHCP ポートでのみパケットを受信するようにするなどです。ISC は、「Linux Packet Filter」を raw ソケットの一種であるかのように言及することがあると思います。そうではありません。BPF は、実際には通常の UDP または TCP ソケットで使用できます。