TC Kernel バージョン 3.16 以降を使用する 1:1 Stateless NAT

1：1ステータス非保存NATトラフィックを試しています。トラフィックはGREトンネルを通過し、VPNを通過します。

私は、GREトンネルからLinuxボックスに入るトラフィックがConntrackに到達しないか、またはiptables -t natに到達しないことを知るのに十分な研究を行いました。 iptales SNAT、DNAT、またはNETMAPはすべて-t natテーブルに存在する必要があります。

iproute2 状態 非保存 nat オプションがありましたが、カーネルバージョン 2.6 から削除されました。削除する前に、次のことができます。ip route add nat 192.168.50.2 via 192.168.60.2

ステートレスnatがiproute2から削除されたとき、Xtables-addonsパッケージにRAWDNATおよびRAWSNATオプションがありました。 Xtablesプラグイン。 Xtables-addonsドキュメントはオプションでRAWDNATとRAWSNATを提供していますが、エラーが発生しますXtables-アドオンはRAWSNAT/RAWDNATを除去します。

今私は交通制御の世界に入ります。交通管理文書は非常にまれであり、従うことは困難です。特に入口処理の場合。

だから私は問題を解決し、今私のeth0でtcで動作する1：1の単純な状態の非保存NATを取得しようとしています。アドレスが192.168.234.5でルーティングが10.40.0.0/16のボックスがあります。私は192.168.234.112から10.40.0.112への双方向のNATを試しています。

10.40.0.112のインバウンドパケットの場合：

tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 10 \
  u32 match ip src 10.40.0.112/32 \
  action nat ingress 10.40.0.112/32 192.168.234.112

アウトバウンドパケットの場合

tc qdisc add dev eth0 root handle 1: htb
tc filter add dev eth1 parent 1: protocol ip prio 10 \
   u32 match ip dst 192.168.234.112/32 \
   action nat egress 192.168.234.112/32 10.40.0.112 

とにかく実際に上記のコマンドが機能するようにすることはできましたが、生涯の間はもう動作させることはできません。 stackoverflow.comでは、Ubuntuのデフォルトのqdisc（pfifo_fast）はクラスがないため、パケットフィルタリングを提供しないという記事を見つけましたが、もはやその記事に従うことはできません。フィルタをサポートしていないqdiscに追加すると、「tc filter add」はエラーメッセージを表示すると思うかもしれませんが、これはトリックを実行しているようです。

これは私が実行しているコマンドです。

まず、入口に取り付けるものがあるように出口qdiscを追加します。

tc qdisc add dev eth0 root handle 1: htb
tc qdisc add dev eth0 ingress

この時点tc qdiscで報告してください

qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 0 direct_packets_stat 9 direct_qlen 1000
qdisc ingress ffff: dev eth0 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

これでアイテムフィルタを追加します。たとえば、次のようになります。

tc filter add dev eth0 parent ffff: protocol ip prio 10 \
   u32 match ip src 10.40.0.112/32 \
   action nat ingress 10.40.0.112/32 192.168.234.112

この時点で 10.40.0.112 で ping を実行すると、192.168.234.112 で応答が出ることが予想されます。しかし、フィルタは決してヒットされません。実際には、パケットにNAT操作が適用されているのを見たことはありませんが、このフィルタルールの統計が上がりました。

次のエクスポートフィルタを追加します。

tc filter add dev eth0 parent 1: protocol ip prio 10 \ 
   u32 match ip dst 192.168.234.112/32 \
   action nat egress 192.168.234.112/32 10.40.0.112

この時点で、tcフィルタは次のようになります。

root@ubusswan1-VirtualBox:/home/ubusswan1# tc filter show dev eth0
filter parent 1: protocol ip pref 10 u32 
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? 
  match c0a8ea70/ffffffff at 16
    action order 1:  nat egress 192.168.234.112/32 10.40.0.112 pass
root@ubusswan1-VirtualBox:/home/ubusswan1# tc filter show dev eth0 root
filter parent ffff: protocol ip pref 10 u32 
filter parent ffff: protocol ip pref 10 u32 fh 800: ht divisor 1 
filter parent ffff: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ??? 
  match 0a280070/ffffffff at 12
    action order 1:  nat ingress 10.40.0.112/32 192.168.234.112 pass 

この1：1 NATが進行するようにTCを十分に理解するのに役立ちますか？動作しないTCフィルタをデバッグするより良い方法はありますか？