イーサネット経由で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
のすべての組み合わせを試しましたが、喜びはありませんでした。私の限られた理解では、ある種のステートフル転送ルールが必要であるということですが、何を使用できますか?
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ヘルパーはそこに介入しました)。