☰

uidなしのiptablesパケット

tag-icon • tag-icon debian networking iptables vpn
uidなしのiptablesパケット

VPNを介して自分のコンピュータの特定のユーザーからすべてのトラフィックをルーティングしようとしています。ユーザーのパケットにタグを付けるには、「-mowner --uid-owner」を使用してiptablesルールを作成し、そのパケットのルーティングテーブルを使用してこれを実行しました。すべてがリダイレクトされるようにするには、「-m Owner ! --uid-owner 0-99999 -j DROP」を使用して、すべての「匿名」ネットワークパケットを破棄します。

ほとんどの場合、うまく機能しますが、ユーザーから来るのは明らかであるにもかかわらず、一部のSSL接続ではこれらの現象がほとんど発生しないことが観察されました。私が「wget」をしているという意味だhttps://google.comGoogle IPに送信されたパケットがuidなしで送信されたため、削除されたことをログで確認しました。

私が理解しているのは、カーネルが時々何らかの理由で要求を「キュー」に入れてから、パケットのuidを設定せずに非同期で処理できることです。この場合、このパケットの実際のソースを追跡することは可能ですか？ VPNを介してすべての「匿名」パケットを転送することはできません。他のユーザーにもこのようなことが起こると思うからです。

ありがとうございます。

ベストアンサー1

一部のパケットは、実際にはどのユーザーにも属さず、カーネルにのみ属します。

  • パケットルーティング
  • 外部イベントに応答してカーネルによって生成されたパケット。たとえば、icmp echo-r​​equest を受信すると、カーネルは icmp echo-r​​eply で応答します。
  • おそらく、すべてのiptableに対して-j REJECTパケットがあります。
  • ...

これで、あなたが話しているパケットについて：所有者がいるパケットと所有者がいないパケットでテストした結果、ACK通信終了のネゴシエーションが終了し、FIN接続が突然切断されたときにRST最終パケットに含まれるように見えます。私の考えでは、どちらの場合もカーネルがユーザーに属する接続を切り離すので、考慮をやめたようです。しかし、これが常に起こるわけではありませんACK（PSHと最終データと混在するとき？）。

アップデート：回答"Iptables：発信トラフィックをconntrackと所有者と一致させます。奇妙な削除に適しています。"この問題に関する詳細情報を提供してください。

これらのパケットを失いたくない場合でも、意思決定にMARKを使用したい場合は、引き続きMARKを使用できます。ネットフィルターCONNMARK最後のパケットは、所有者がいなくても同じ接続の一部であるためです。たとえば、リンクの例で適用したルールでテストします。

#!/bin/sh

iptables -t mangle -N connmark_test
iptables -t mangle -N connmark_log
iptables -t mangle -A connmark_test -j CONNMARK --restore-mark
iptables -t mangle -A connmark_test -m mark ! --mark 0 -j RETURN
iptables -t mangle -A connmark_test -m mark --mark 0 -m owner --uid-owner 0-99999 -p tcp -j MARK --set-mark 1
iptables -t mangle -A connmark_test -m mark --mark 0 -m owner --uid-owner 0-99999        -j MARK --set-mark 2
iptables -t mangle -A connmark_test -m mark --mark 0                              -p tcp -j MARK --set-mark 3
iptables -t mangle -A connmark_test -m mark --mark 0                                     -j MARK --set-mark 4
iptables -t mangle -A connmark_test -j CONNMARK --save-mark
iptables -t mangle -A connmark_log -m owner --uid-owner 0-99999 -j LOG --log-prefix "with_owner "
iptables -t mangle -A connmark_log -m owner ! --uid-owner 0-99999 -j LOG --log-prefix "  NO_owner "
iptables -t mangle -A POSTROUTING -j connmark_test
iptables -t mangle -A POSTROUTING -m mark ! --mark 0 -j connmark_log

curl -s -L https://google.com/ >/dev/null（2つの接続設定）所有者が一致すると、最終接続のACKまたはRSTは通常失敗しますが、次の理由でまだconnmarkがあることがわかりますMARK=0x1。

[14668.179780] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=53193 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK PSH URGP=0 MARK=0x1 
[14668.181740] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53194 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK FIN URGP=0 MARK=0x1 
[14668.181914]   NO_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53195 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK URGP=0 MARK=0x1 
[14668.182667] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=58460 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=520 RES=0x00 ACK PSH URGP=0 MARK=0x1 
[14668.184588] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=58461 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=520 RES=0x00 ACK RST URGP=0 MARK=0x1 
[14668.201316]   NO_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=20784 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x1

最後の注意：ユーザーの活動が他のユーザーのパケットをトリガーできることを忘れないでください。たとえば、ローカルDNSサーバーにDNS要求が行われると、ローカルDNSサーバーは実行中のユーザーが所有するパケットを使用してDNS要求を行います。 DNSサーバー

おすすめ記事