web-dev-qa-db-ja.com

NAT）を介してtftpを転送するiptablesルール

イーサネット経由でPCにテザリングされた組み込みLinuxデバイスを持っています。 PCはVPN経由でtftpサーバーにアクセスできます。組み込みデバイスがtftpサーバーにアクセスできるようにiptablesルールを設定しようとしています。

まず、Network Managerを使用してeno1デバイスで接続を確立し、同じ（プライベート）ネットワーク上に組み込みデバイスを構成しました。デバイスのWeb構成ページに正常にアクセスできます。

次に、PCにiptablesルールを追加して、VPNとの間の転送とNATトラフィック）を追加しました。ここで、192.168.11.0/24はローカルイーサネット上のプライベートサブネットであり、リモートtftpサーバーは172.16.0.0/16経由のtun0サブネット上：

-A FORWARD -i eno1 -j ACCEPT
-A FORWARD -o eno1 -j ACCEPT
-A POSTROUTING -s 192.168.11.0/24 -d 172.16.0.0/16 -o tun0 -j MASQUERADE

デバイスはVPN経由でリモートサーバーのhttpにアクセスできるようになりましたが、転送するルールが見つからず、NAT tftpトラフィックを同じサーバーに送信します。次のカーネルモジュールを手動でロードしました（これが必要かどうかはわかりません）：

nf_nat_tftp            16384  0
nf_conntrack_tftp      16384  1 nf_nat_tftp

私は考えられる（そしてインターネットが示唆している）-A FORWARD ... RELATED,ESTABLISHED -j ACCEPTのすべての組み合わせを試しましたが、喜びはありませんでした。私の限られた理解では、ある種のステートフル転送ルールが必要であるということですが、何を使用できますか？

iptablesnattftp
1
Douglas Royds

2016年のLinux 4.7以降、conntrackの自動ヘルパー割り当ては無効になりました デフォルト（カーネルメッセージでこれについて何年もの警告があった後）：

4年前、72110dfaa907で自動ヘルパー割り当てを無効にする新しいsysctlノブを導入しました（「netfilter：nf_ct_helper：自動ヘルパー割り当てを無効にする」）。このノブは、この動作をデフォルトで有効にして、保守的な状態を維持しました。

この手段は、明示的なルールを介してiptablesと接続追跡ヘルパーを構成するための安全な方法を提供するために導入されました。

安全でないバージョンに戻すのは簡単ですが、iptables（nftablesチェーンの優先順位にわずかな違いがありますが、これも実行できます）。これを行う方法は、このブログに記載されています： iptablesと接続追跡ヘルパーの安全な使用 。

そこで、そこにある情報に従って、これはNATを実行しているルーターで行う必要があります。

  • 大きな警告：

    ヘルパーモジュールが存在し、生のテーブルでそれを参照するルールの前に自動ロードできる必要があります。そうしないと、ルールの追加が失敗します。これはiptables-restore正しく動作し、起動時にルールなしでファイアウォールを離れる。

    とにかくNATモジュールの一部（ここではnf_nat_tftp）は自動ロードされません。したがって、OPと同様に、システムの起動時にこのモジュールを明示的にロードすることをお勧めします。

  • これが現在デフォルトであるか、すでに行われていると仮定します。

    # sysctl -w net.netfilter.nf_conntrack_helper=0

  • ここでのセレクターはOPのPOSTROUTINGで使用されるものを模倣するヘルパーの場所の明示的な宣言（TFTPサーバーの正確で一意のIPアドレスを使用する方が良いでしょう）：

    iptables -A PREROUTING -t raw -p udp --dport 69 -s 192.168.11.0/24 -d 172.16.0.0/16 -j CT --helper tftp

    TFTPは複雑なプロトコルであり、サーバーの応答が無関係の送信元ポートから動的/エフェメラルクライアントの送信元ポートに返される可能性があるため、このルールだけで適切なときにヘルパーがアクティブ化され、TFTPデータとポートのマングリングがトリガーされます。この中で TFTPのWikipediaエントリ 。

  • 一般的な確立されたトラフィック、tftpへの関連トラフィック、および初期TFTPクエリを明示的に受け入れます。

    eno1に出入りするものはすべて受け入れているので、これらのルールは現在の構成では役に立ちません。ファイアウォールルールを厳しくすることを選択した場合は、ここにあります。それらを多かれ少なかれタイトにすることを選択できます（インターフェースの追加など）：

    iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED -m helper --helper tftp -s 172.16.0.0/16 -d 192.168.11.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.11.0/24 -d 172.16.0.0/16 -p udp --dport 69 -j ACCEPT

    2番目のルールは、応答がESTABLISHEDを取得する前に、サーバーからクライアントへのTFTP固有の逆接続（したがって逆方向）を許可します。 FORWARDチェーンはNATされていないトラフィックを確認するため、MASQUERADE中に何が起こったかを知る必要はありません（ただし、tftpヘルパーはそこに介入しました）。

1
A.B