这里到底发生了什么？我设定了以下规则：
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 127.0.0.0/8
ACCEPT all -- anywhere anywhere owner UID match debian-tor
ACCEPT all -- anywhere anywhere state ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
以及 nat 上的这些：
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
RETURN all -- anywhere anywhere owner UID match debian-tor
REDIRECT udp -- anywhere anywhere udp dpt:domain redir ports 53
RETURN all -- anywhere 127.0.0.0/9
REDIRECT tcp -- anywhere anywhere redir ports 9051
REDIRECT udp -- anywhere anywhere redir ports 9051
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
正如您所看到的，除了 Tor 流量和已经与 Tor 建立的流量（？）之外，所有传出流量都被阻止。为什么我仍然有活动的 Tcp 连接，例如。堆栈交换？
ESTAB 0 0 192.168.1.107:53532 151.101.193.69:https
ESTAB 0 0 192.168.1.107:56648 151.101.1.69:https
ESTAB 0 0 192.168.1.107:59170 198.252.206.25:https
ESTAB 0 0 192.168.1.107:36078 151.101.12.133:https
ESTAB 0 0 192.168.1.107:45418 172.217.19.238:https
ESTAB 0 0 192.168.1.107:35364 172.217.21.106:https
ESTAB 0 0 192.168.1.107:56650 151.101.1.69:https
世界卫生组织 198.252.206.25
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=198.252.206.25?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 198.252.206.0 - 198.252.206.255
CIDR: 198.252.206.0/24
NetName: SE-NET01
NetHandle: NET-198-252-206-0-1
Parent: NET198 (NET-198-0-0-0-0)
NetType: Direct Assignment
OriginAS: AS25791
Organization: Stack Exchange, Inc. (SE-111)
RegDate: 2012-10-17
Updated: 2012-10-17
Comment: http://stackexchange.com
Ref: https://whois.arin.net/rest/net/NET-198-252-206-0-1
OrgName: Stack Exchange, Inc.
OrgId: SE-111
Address: 110 William St.
Address: Floor 28
City: New York
StateProv: NY
PostalCode: 10038
Country: US
RegDate: 2012-09-14
Updated: 2014-09-16
Ref: https://whois.arin.net/rest/org/SE-111
OrgAbuseHandle: SYSAD101-ARIN
OrgAbuseName: Sysadmin Team
OrgAbusePhone: +1-212-232-8280
OrgAbuseEmail: [email protected]
OrgAbuseRef: https://whois.arin.net/rest/poc/SYSAD101-ARIN
OrgTechHandle: SYSAD101-ARIN
OrgTechName: Sysadmin Team
OrgTechPhone: +1-212-232-8280
OrgTechEmail: [email protected]
OrgTechRef: https://whois.arin.net/rest/poc/SYSAD101-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
这里发生了什么？日复一日，我的印象是 iptables 严重损坏。
答案1
在 OUTPUT 末尾添加 -J LOG 规则，以便您知道哪些数据包将遵循其余规则。另外，将 -v 添加到 iptables -L 也会有所帮助，因为您可以看到更多详细信息，包括命中每个规则的数据包数量。
例如：
iptables -A OUTPUT -j LOG --log-prefix "firewall:ACCEPT:" --log-level 6
另外，如果隐私是重中之重，我会这样做……我不相信任何人会为此目的编写完美的规则。相反，我会制作一台单独的机器作为客户端，除了通过 Tor 之外，它无法使用任何互联网连接。这样，即使您的计算机感染了恶意软件，通过明网发送数据包来泄露您的身份，它也将无法连接。如果您按自己的方式操作，那么失败只会通过明网而不是被阻止，正如您已经看到的那样。