我正在尝试重新路由用户的所有连接，使其仅通过 openvpn 隧道进行。该隧道使用 net30。
这是我的上题（经过多次战斗之后）：
#!/bin/bash
rt_table="mtunnel"
# make sure that rt table exits, e.g.
# echo 200 mtunnel >> /etc/iproute2/rt_tables
# stop blocking vpnuser, start marking it as 3
ip rule add fwmark 3 lookup "$rt_table"
iptables -t mangle -A OUTPUT -m owner --uid-owner vpnuser -j MARK --set-mark 3
iptables -D OUTPUT -m owner --uid-owner vpnuser -j REJECT
# not sure about these ones.. should this be in nat ? or is it useless
iptables -t mangle -A OUTPUT -j CONNMARK --save-mark
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
# fix outgoing packets
#iptables -t nat -A POSTROUTING -o $1 -j SNAT --to-source $4
iptables -t nat -A POSTROUTING -o $1 -j MASQUERADE
# route outgoing table through vpn
ip route add default via $5 dev $1 table "$rt_table"
如果我尝试以普通用户身份托管一个 netcat 服务器，然后从远程服务器（通过 VPN）进入该服务器，一切都会按预期工作。
然而，当我使用 托管它时vpnuser，第一次使用 netcat 时什么也没有发生（最终超时），然后第二次每次都正常工作。
这是一个 tcpdump（在主机上）
1st netcat (servers ack s dont get to remote host)
13:07:58.250372 IP [remote machine].40090 > [host machine].11234: Flags [S], seq 3704021254, win 65535, options [mss 1357,nop,nop,sackOK,nop,wscale 11], length 0
13:07:58.250404 IP [host machine].11234 > [remote machine].40090: Flags [S.], seq 2290570915, ack 3704021255, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:07:59.263714 IP [host machine].11234 > [remote machine].40090: Flags [S.], seq 2290570915, ack 3704021255, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:07:59.281659 IP [remote machine].40090 > [host machine].11234: Flags [S], seq 3704021254, win 65535, options [mss 1357,nop,nop,sackOK,nop,wscale 11], length 0
13:07:59.281680 IP [host machine].11234 > [remote machine].40090: Flags [S.], seq 2290570915, ack 3704021255, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
13:08:01.311713 IP [host machine].11234 > [remote machine].40090: Flags [S.], seq 2290570915, ack 3704021255, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
2nd netcat - normal
13:08:15.020556 IP [remote machine].42796 > [host machine].11234: Flags [S], seq 1509258173, win 65535, options [mss 1357,nop,nop,sackOK,nop,wscale 11], length 0
13:08:15.020584 IP [host machine].11234 > [remote machine].42796: Flags [S.], seq 252963595, ack 1509258174, win 29200, options [mss 1460], length 0
13:08:15.021730 IP [remote machine].42796 > [host machine].11234: Flags [.], ack 1, win 65535, length 0
13:08:16.283094 IP [remote machine].42796 > [host machine].11234: Flags [P.], seq 1:5, ack 1, win 65535, length 4
13:08:16.283117 IP [host machine].11234 > [remote machine].42796: Flags [.], ack 5, win 26000, length 0
13:08:16.501676 IP [remote machine].42796 > [host machine].11234: Flags [P.], seq 1:5, ack 1, win 65535, length 4
13:08:16.501696 IP [host machine].11234 > [remote machine].42796: Flags [.], ack 5, win 26000, length 0
13:08:16.941699 IP [remote machine].42796 > [host machine].11234: Flags [P.], seq 1:5, ack 1, win 65535, length 4
13:08:16.941728 IP [host machine].11234 > [remote machine].42796: Flags [.], ack 5, win 26000, length 0
13:08:17.562913 IP [remote machine].42796 > [host machine].11234: Flags [F.], seq 5, ack 1, win 65535, length 0
13:08:17.562948 IP [host machine].11234 > [remote machine].42796: Flags [F.], seq 1, ack 6, win 26000, length 0
13:08:17.841665 IP [remote machine].42796 > [host machine].11234: Flags [FP.], seq 1:5, ack 1, win 65535, length 4
13:08:17.841684 IP [host machine].11234 > [remote machine].42796: Flags [.], ack 6, win 26000, length 0
13:08:20.799730 IP [host machine].11234 > [remote machine].42796: Flags [F.], seq 1, ack 6, win 26000, length 0
13:08:20.800797 IP [remote machine].42796 > [host machine].11234: Flags [.], ack 2, win 64732, length 0
正如您在第一个示例中看到的那样，由于某种原因，第一个数据包（与服务器的连接）的选项被复制到 ack options [mss 1460,nop,nop,sackOK,nop,wscale 7]，但不知何故它并没有到达远程主机（也许它被检测为欺骗？）
在第二个示例中，这些选项不存在-但它有效。
这里有什么我遗漏或者误解了吗？
我想补充一点，对于通过vpnusercurl 等方式进行的传出连接，每次都会通过 vpn 正确地重新路由
一些额外的事情：
root@localhost:~# sysctl -a | grep tun0
net.ipv4.conf.tun0.accept_local = 0 <<<<<<<<<< ?
net.ipv4.conf.tun0.accept_redirects = 1
net.ipv4.conf.tun0.accept_source_route = 1
net.ipv4.conf.tun0.arp_accept = 0
net.ipv4.conf.tun0.arp_announce = 0
net.ipv4.conf.tun0.arp_filter = 0
net.ipv4.conf.tun0.arp_ignore = 0
net.ipv4.conf.tun0.arp_notify = 0
net.ipv4.conf.tun0.bootp_relay = 0
net.ipv4.conf.tun0.disable_policy = 0
net.ipv4.conf.tun0.disable_xfrm = 0
net.ipv4.conf.tun0.drop_gratuitous_arp = 0
net.ipv4.conf.tun0.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.tun0.force_igmp_version = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.tun0.igmpv2_unsolicited_report_interval = 10000
net.ipv4.conf.tun0.igmpv3_unsolicited_report_interval = 1000
net.ipv4.conf.tun0.ignore_routes_with_linkdown = 0
net.ipv4.conf.tun0.log_martians = 0
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv4.conf.tun0.medium_id = 0
net.ipv4.conf.tun0.promote_secondaries = 0
net.ipv4.conf.tun0.proxy_arp = 0
net.ipv4.conf.tun0.proxy_arp_pvlan = 0
net.ipv4.conf.tun0.route_localnet = 0
net.ipv4.conf.tun0.rp_filter = 0 <<<<
net.ipv4.conf.tun0.secure_redirects = 1
net.ipv4.conf.tun0.send_redirects = 1
net.ipv4.conf.tun0.shared_media = 1
net.ipv4.conf.tun0.src_valid_mark = 0
net.ipv4.conf.tun0.tag = 0
net.ipv4.neigh.tun0.anycast_delay = 100
net.ipv4.neigh.tun0.app_solicit = 0
net.ipv4.neigh.tun0.base_reachable_time_ms = 30000
net.ipv4.neigh.tun0.delay_first_probe_time = 5
net.ipv4.neigh.tun0.gc_stale_time = 60
net.ipv4.neigh.tun0.locktime = 100
net.ipv4.neigh.tun0.mcast_resolicit = 0
net.ipv4.neigh.tun0.mcast_solicit = 3
net.ipv4.neigh.tun0.proxy_delay = 80
net.ipv4.neigh.tun0.proxy_qlen = 64
net.ipv4.neigh.tun0.retrans_time_ms = 1000
net.ipv4.neigh.tun0.ucast_solicit = 3
net.ipv4.neigh.tun0.unres_qlen = 31
net.ipv4.neigh.tun0.unres_qlen_bytes = 65536
这出现在第二次连接后的消息中
Sep 25 01:44:18 localhost kernel: [ 3847.337166] TCP: request_sock_TCP: Possible SYN flooding on port 11234. Sending cookies. Check SNMP counters.
Sep 25 13:08:15 localhost kernel: [44884.232925] TCP: request_sock_TCP: Possible SYN flooding on port 11234. Sending cookies. Check SNMP counters.
Sep 25 13:49:36 localhost kernel: [47365.429055] nr_pdflush_threads exported in /proc is scheduled for removal
Sep 25 14:33:09 localhost kernel: [49979.194689] TCP: request_sock_TCP: Possible SYN flooding on port 11234. Sending cookies. Check SNMP counters.
编辑：发现回复实际上是通过 eth0 发出的，这很糟糕......
[Interface:tun0:] 14:48:10.224760 IP [remote].41098 > [host].11234: Flags [S], seq 2900018492, win 65535, options [mss 1357,nop,nop,sackOK,nop,wscale 11], length 0
[Interface:eth0:] 14:48:10.224778 IP [host].11234 > [remote].41098: Flags [S.], seq 767657810, ack 2900018493, win 29200, options [mss 1460], length 0
[Interface:tun0:] 14:48:10.225865 IP [remote].41098 > [host].11234: Flags [.], ack 767657811, win 65535, length 0
[Interface:tun0:] 14:48:11.794831 IP [remote].41098 > [host].11234: Flags [P.], seq 0:6, ack 1, win 65535, length 6
[Interface:tun0:] 14:48:11.794845 IP [host].11234 > [remote].41098: Flags [.], ack 6, win 26000, length 0
[Interface:tun0:] 14:48:12.021239 IP [remote].41098 > [host].11234: Flags [P.], seq 0:6, ack 1, win 65535, length 6
[Interface:tun0:] 14:48:12.021249 IP [host].11234 > [remote].41098: Flags [.], ack 6, win 26000, length 0
[Interface:tun0:] 14:48:12.451336 IP [remote].41098 > [host].11234: Flags [P.], seq 0:6, ack 1, win 65535, length 6
[Interface:tun0:] 14:48:12.451347 IP [host].11234 > [remote].41098: Flags [.], ack 6, win 26000, length 0
[Interface:tun0:] 14:48:12.605771 IP [remote].41098 > [host].11234: Flags [F.], seq 6, ack 1, win 65535, length 0
[Interface:tun0:] 14:48:12.605807 IP [host].11234 > [remote].41098: Flags [F.], seq 1, ack 7, win 26000, length 0
[Interface:eth0:] 14:48:13.361272 IP [host].11234 > [remote].41098: Flags [.], ack 8, win 26000, length 0
[Interface:tun0:] 14:48:13.361263 IP [remote].41098 > [host].11234: Flags [FP.], seq 0:6, ack 1, win 65535, length 6
[Interface:eth0:] 14:48:15.807721 IP [host].11234 > [remote].41098: Flags [F.], seq 1, ack 8, win 26000, length 0
[Interface:tun0:] 14:48:15.809015 IP [remote].41098 > [host].11234: Flags [.], ack 2, win 64732, length 0