外から見るとポートは閉じているように見えますが、最終的にはアプリケーションやルーターの方を探すことになります。何かを変更する前に、nftablesによって実際に読み込まれているルールを確認してください。ファイル/etc/nftables.confはアクティブな状態と異なる場合があり、ローカルファイアウォールだけではネットワーク経路全体を説明できません。
この方法は、ルールセットを読み取り、入力トラフィックを処理するチェーンを特定し、SSHセッションを失うことなく変更をテストすることを可能にします。リモートで作業する場合は、もう一つの接続を開いておいてください。
最初に読み込まれたファイアウォールを確認してください
次のコマンドは何も変更しません。カーネル内で現在存在するテーブル、チェーン、ルール、およびカウンタを表示します：
sudo nft list ruleset出力が長い場合は、最初にテーブルをリストし、その後関心のあるものをターゲットにします：
sudo nft list tables
sudo nft list table inet filterinetファミリーは、IPv4およびIPv6ルールを含むことができます。テーブルは、ip、ip6、bridge、またはnetdevに属することもあります。問題が解決されると仮定して、IPv6ルールをIPv4ルールで置き換えないでください。
フィルタリングテーブル内では、特にtype filter hook inputを持つ基本チェーンを探します。これが、機械に向けられたトラフィックを受信するものです。その行policy dropは、acceptルールに合致しないパケットが拒否されることを意味します。
特定のルールを後で削除する必要がある場合に便利なルールIDを表示するには、-aを追加します：
sudo nft -a list chain inet filter inputinput、forward、outputを混同しないでください。SSH接続を受信するサーバーは通常inputを使用します。他のホストにトラフィックをルーティングするマシンは、forward内でパケットをブロックする可能性があります。インターネットに出るアプリケーションはoutputを通過します。
ポートとルールの順序を確認してください
チェーン内のルールは順番に評価されます。拒否ルールがポート許可の前に置かれている場合、それが勝ちます。プロトコル、ポート、および接続状態を確認してください：
sudo nft list chain inet filter input
sudo ss -lntupSSHの場合、期待されるルールは通常tcp dport 22 acceptに似ています。デーモンが他の場所でリッスンしている場合、ポートは異なる可能性があります。ss -lntupの出力は、プログラムが期待されるポートとアドレスで実際にリッスンしているかどうかを確認できます。開いたファイアウォールは、停止しているサービスを利用可能にすることはありません。
ルールct state established,related acceptやループバックインターフェースiif lo acceptにも注目してください。これらは、すでに確立された接続の応答やローカルなやりとりを壊すのを防ぎます。ルールセットにカウンタが含まれている場合、接続テストの前後でそれらを比較して、どのルールがトラフィックを見ているかを確認します。
拒否はマシン外で発生することがあります：クラウドセキュリティグループ、ルーター、NATリダイレクト、VLAN、企業ファイアウォールまたは127.0.0.1にのみ関連するサービスです。別の端末からnc -vz サーバーのアドレス 22またはSSHクライアントを使用してポートをテストします。サーバー上で、nftablesに触れる前にssでリッスン状態を確認してください。
実際にブロックしているルールを特定する
チェーンはjumpやgotoを使用して他のチェーンを呼び出すことがあります。したがって、ポートの許可は最初に表示されるチェーンには必ずしも見えません。チェーンの呼び出し、命名されたセット、およびロギングプレフィックスが付いているルールを再確認してください。counter dropまたはrejectタイプのルールがポートよりも前にある場合、それがしばしば結果を説明します。
nft monitor traceを使用して特定のパケットを追跡できますが、このコマンドはアクティブなマシンで大量のデータを生成します。診断の短いウィンドウのために予約し、一時的なルール内でアドレスまたはポートによってトラフィックをフィルタリングしてください。次に、nft -a list rulesetで表示されたハンドルを使用してこのルールを削除します。
広範なトレースまたはロギングルールを公開サーバーに残さないでください。ログを埋めるか、診断にノイズを加える可能性があります。最初の確認では、チェーンのカウンタと別の端末からのテストで十分なことが多いです。
アクティブなルールセットと永続的なファイルは異なる場合があります
nft list rulesetはアクティブな状態を読み取ります。どのサービスがルールを読み込んだか、再起動時にどのファイルが使用されるかは言いません。DebianやUbuntuでは、通常/etc/nftables.confとサービスの状態を確認してください：
sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conffirewalld、UFW、Docker、またはホスティングツールを使用しているディストリビューションでは、複数のコンポーネントがルールを書き込むことがあります。別のサービスが既に管理している場合、/etc/nftables.confにチュートリアルで見たルールセットをコピーしないでください。まずマシンによって宣言されたマネージャーを特定し、再読み込み後にルールを再確認してください。
コマンドラインから追加されたルールは、次の再起動またはサービスの再読み込みで消えることがよくあります。逆に、永続的なファイルを変更しても、それが読み込まれない限り何も変わりません。ポートが開いていると結論付ける前に、両方の側面を確認する理由はまさにこれです。
ルールを適用する前にバックアップを取り、テストしてください
書き込みの前に現在の状態を保持します。バックアップファイルは管理者のみが読み取れるように保ちます：
sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null次に、一時ファイルで変更を準備します。nft -cは、ルールを読み込まずに構文を確認します：
sudo nft -c -f /etc/nftables.confこの確認は、新しいルールセットがあなたを入れさせることを証明するものではありません。もう一つのSSHセッションを接続したままにしておき、最初のセッションでファイルを適用し、別のターミナルから新しい接続を試みます。アクセスを失った場合、バックアップセッションが復元を可能にします：
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# 分断や誤ったルールの場合：
sudo nft -f /root/nftables-before-change.nftflush rulesetを遠隔サーバーで単独で実行しないでください。置き換えファイルを確認する前に、現在のすべてのルールを削除します。完全で確認されたファイルを読み込んだ後、すぐにアクティブなルールセットを確認してください。
変更後の確認
sudo nft list rulesetを再実行し、期待されるテーブルとチェーンがまだ存在するかを確認します。- 実際に使われているポートで、別のマシンからサービスをテストします。
- ポートが引き続きアクセス不可の場合、
sudo ss -lntupを確認します。 - 拒否されたパケットがログに記録されている場合、
sudo journalctl -k -bでカーネルログを確認します。 - 再起動後、nftablesサービスがディストリビューションの永続的なファイルを正しく再読み込みしているかを確認します。
簡単なケースの場合、LinuxのUFWに関する記事がより適しています。ファイアウォールを変更する前にサービスの可用性を診断する必要がある場合、ssでオープンポートを確認することも行ってください。ドキュメントnft(8)は、ファミリー、チェーン、および-cオプションの詳細を説明しています。
