このエラーが発生する理由
iptablesコマンドを実行し、成功メッセージを期待したものの、代わりに不可解な "No chain/target/match by that name" というエラーが表示されることがあります。このメッセージは、3つの異なる失敗の可能性を指しているため、不親切なことで有名です。これは、チェインが存在しない、ターゲット（REJECTなど）が見当たらない、あるいは特定のマッチモジュール（conntrackなど）がカーネルにロードされていないことを意味します。多くの場合、これは単純な入力ミスや、コンテナ環境におけるカーネルモジュールの不足が原因で発生します。
主な根本原因
- 大文字・小文字の厳密な区別:
iptablesでは、INPUTとinputは完全に別物として扱われます。 - カーネルモジュールの不足:
-m multiportや-j REJECTなどの拡張機能には、有効化されていない可能性のある特定のxtablesモジュールが必要です。 - カスタムチェインの不足: まだ作成していないチェインにルールを追加しようとしています。
- nftablesバックエンド: 最新のディストリビューションでは、コマンドを
nftablesに変換するiptables-nftが使用されています。基盤となるnftablesインフラに機能が欠けている場合、この変換レイヤーが失敗することがあります。 - 制限された環境: DockerコンテナやWSL2では、ネットワークスタックを変更するためのカーネル権限が不足していることがよくあります。
ステップバイステップの解決策
1. 入力ミスと大文字・小文字の確認
Linuxは文字通りに解釈します。組み込みのチェインは大文字で記述する必要があります。小文字を使用しようとすると、システムは存在しないカスタムチェインを探してしまいます。
# これは失敗します
sudo iptables -A input -p tcp --dport 80 -j ACCEPT
# これは動作します
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
2. チェインが存在するか確認する
カスタムチェインにルールを追加する前に、そのチェインを定義する必要があります。sudo iptables -L -nを実行して、アクティブなすべてのチェインのリストを確認してください。カスタムチェイン（例：APP_FIREWALL）がリストにない場合は、-Nフラグを使用して作成します：
sudo iptables -N APP_FIREWALL
3. 不足しているカーネルモジュールをロードする
このエラーは、--limitや--stateなどの高度なマッチを使用するときによく発生します。これらの機能はカーネルモジュールに依存しています。カーネルがこれらをロードしていない場合、コマンドは即座に失敗します。lsmod | grep xt_を使用して、アクティブなモジュールを確認できます。
REJECTターゲットやconntrackを使用しようとしている場合は、以下のモジュールを手動でロードしてみてください：
sudo modprobe ipt_REJECT
sudo modprobe xt_conntrack
sudo modprobe xt_multiport
注意：新しいカーネル（5.x以降）では、-m stateは非推奨です。互換性を確保するために、-m state --state NEWを-m conntrack --ctstate NEWに置き換えてください。
4. nftablesへの移行を管理する
Ubuntu (22.04+) や Debian (11+) の最近のバージョンでは、デフォルトのバックエンドとしてnftablesが使用されています。iptablesコマンドは通常、iptables-nftへのシンボリックリンクです。スクリプトが古いレガシーな動作に依存している場合、変換が失敗することがあります。レガシーバイナリに切り替えることで、これらの「謎の」エラーが解決することがよくあります。
Debianベースのシステムでは、update-alternativesツールを使用して切り替えます：
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
切り替え後、コマンドを再実行してください。動作する場合、お使いの環境とnftバックエンドの間に互換性のギャップがあります。
5. DockerとWSL2向けの修正
Dockerコンテナ内では、コンテナにNET_ADMIN権限がないため、iptablesコマンドが失敗することがよくあります。これは、docker runコマンドに--cap-add=NET_ADMINを追加することで解決できます。WSL2ユーザーの場合、デフォルトのMicrosoftカーネルは機能が削られていることがよくあります。完全なiptablesサポートを得るには、カスタムカーネルをコンパイルするか、wsl --update経由で最新のWSLバージョンにアップデートする必要があるかもしれません。
修正の確認
iptablesでの成功は、通常何も表示されません。ルールが実際に適用されたことを確認するには、-S（ルールをリスト表示）フラグを使用し、特定のポートやターゲットをgrepします：
sudo iptables -S | grep "80"
出力にルールが表示されれば、ファイアウォールはアクティブで機能しています。
ネットワーク安定性のためのプロのヒント
複雑なルールを手動で構築するのは避けましょう。標準的な命名規則を使用し、カーネルヘッダーを最新の状態に保ってください。複雑なIP範囲やCIDRブロックを扱う場合、正確さが不可欠です。私はルールを適用する前に、ToolCraftのSubnet Calculatorを使用してネットワーク計算を再確認しています。これにより、「No chain」エラーに似た、厄介な「invalid argument」エラーを防ぐことができます。
常にiptablesに苦労しているようなら、直接nftablesに移行する時期かもしれません。nftablesはよりクリーンな構文を提供し、問題が発生したときのエラーレポートも大幅に改善されています。