家里网络设置了旁路由后， OpenVPN 连进来，可以 ping，但是无法正常连接何故？

• 資深大佬 : UnknownSky

  你這 openvpn server 直接掛在 Openwrt 上不得了

• 資深大佬 : UnknownSky

  主路由什麼系統，建 server 也要 iptables NAT 規則。

• 資深大佬 : ztechstack

  openvpn 服务端需要虚拟出一个网络，需要 iptables 指定 source 为改网络的转发到物理网卡上。
  iptables -t nat -A POSTROUTING -s x.x.x.x/x -o eth0 -j MASQURADE

• 資深大佬 : Jirajine

  你这配的乱七八糟，旁路由上开 masquerade 是要搞什么？
  盲猜 hairpin nat 的问题， 把 masquerade 去掉。

• 主 資深大佬 : nozer

  @Jirajine ？ 我感觉线路很清晰啊，哪里乱了。

• 主 資深大佬 : nozer

  @Jirajine 去掉的话无法正常上网了，

• 資深大佬 : huangya

  openvpn client 虚拟网卡拿到的 IP 也是 192.168.2.0/24 网段吗？

• 資深大佬 : huangya

  另外，在 openvpn client 虚拟网卡上抓下 ssh 或者 web 服务至少有没有三次握手的包。

• 主 資深大佬 : nozer

  @huangya vpn client 的虚拟网卡网段是：10.8.0.0/24

• 資深大佬 : huangya

  @nozer
  在 PC1 上添加一条到 10.8.0.0/24 的静态路由.linux 下的命令:
  sudo route add -net 10.8.0.0/24 gw 192.168.2.1

  Windows 用管理员权限打开 cmd:
  route add mask 255.255.255.0 192.168.2.1

• 資深大佬 : huangya

  @huangya
  更正：
  Windows 用管理员权限打开 cmd:
  route add 10.8.0.0 mask 255.255.255.0 192.168.2.1

• 主 資深大佬 : nozer

  @huangya 谢谢我试试看。

• 資深大佬 : jasonyang9

  瞎猜的，
  PC1 的默认网关是 192.168.2.2 旁路由，所以对 10.8.0.0/24 发来的数据包它不知道如何返回就走默认网关；
  旁路由收到后也不知道如何到 10.8.0.0/24，也走它的默认网关，192.168.2.1，且被 iptables 匹配到，做了 MASQ，也就是 SNAT，那么数据包的源地址就被替换为旁路由自己的 192.168.2.2 ；
  而请求数据包的目标地址是 192.168.2.10 （ PC1 ），响应却是从 192.168.2.2 收到，就被丢掉了。。。

• 主 資深大佬 : nozer

  @jasonyang9 我也有这种猜测，但是不知道怎么处理。 @huangya 的办法不错，我试试看应该能解决问题。

  但是如果能够在路由器上解决问题就更好了，那样就不用在 PC 上单独配置。

• 資深大佬 : huangya

  @jasonyang9 yes, I think so. 主可以用 wireshark 检查下 icmp 包和 tcp 包的源地址。所以我提供的方案是 vpn 网段直接走 192.168.2.1

• 主 資深大佬 : nozer

  或许如 @Jirajine 所说，去掉 MASQ 就可以了，但是去掉 MASQ 似乎会导致数据包在 192.168.2.2 上循环导致无法正常上网了。

• 主 資深大佬 : nozer

  @huangya 嗯嗯，我抓包看看。

• 資深大佬 : huangya

  @nozer

  >但是如果能够在路由器上解决问题就更好了，那样就不用在 PC 上单独配置。

  >或许如 @Jirajine 所说，去掉 MASQ 就可以了，但是去掉 MASQ 似乎会导致数据包在 192.168.2.2 上循环导致无法正常上网了。

  可以在 OpenWRT 上用如下命令试试看,这种方法或许也可以,这样就不需要在 PC 上单独配置静态路由了.
  iptables -I nat 1 -s 10.8.0.0/24 -j ACCEPT

• 資深大佬 : Lemeng

  抓包了解走向，走到哪步，哪步出了问题

• 資深大佬 : huangya

  @huangya @nozer
  最近总是打错命令

  >可以在 OpenWRT 上用如下命令试试看,这种方法或许也可以,这样就不需要在 PC 上单独配置静态路由了.
  >iptables -I nat 1 -s 10.8.0.0/24 -j ACCEPT

  ->
  iptables -t nat -I POSTROUTING 1 -s 10.8.0.0/24 -j ACCEPT

• 資深大佬 : Jirajine

  能 ping 通是因为 icmp 自带 redirect，不受 hairpin nat 的影响。
  去掉 masquerade 不能上网说明你配的有问题，检查防火墙和内核 ip 转发开了没。
  旁路由这种方式本来就是 ipv4 下的一种 trick，踩坑是很正常的，配成两级主干串起来才是正统方式。

• 主 資深大佬 : nozer

  @huangya 很感谢。PC 上设置静态路由可以解决问题。 但是路由器上设置 iptables 规则没什么效果。 抓包我也抓了下，但是水平有限研究不出来啥。

• 資深大佬 : huangya

  @nozer
  想了下，OpenWRT 上的这条命令还是有问题，当时脑抽了，改成以下估计就可以了。
  iptables -t nat -I POSTROUTING 1 -d 10.8.0.0/24 -j ACCEPT

• 主 資深大佬 : nozer

  @huangya 真的可以了，问题解决。原因应该是跟前面的猜测一致，但是我想请教下，现在的规则是这样的：
  iptables -t nat -A PREROUTING -p udp –dport 53 -j REDIRECT –to-ports 53
  iptables -t nat -A PREROUTING -p tcp –dport 53 -j REDIRECT –to-ports 53
  iptables -t nat -I POSTROUTING -j MASQUERADE
  iptables -t nat -I POSTROUTING 1 -d 10.8.0.0/24 -j ACCEPT

  就是说，发送到 10.8.0.0/24 的包采用的动作是 ACCEPT，但是这里并没有 return，为何就可以产生效果呢？
  iptables 规则的匹配不是从前到后依次匹配，除非无法匹配，或者 return 才会终止匹配后面的规则。

  这个地方，ACCEPT 后，并没有 return，那不是最后还是会匹配到 MASQUERADE 上去，导致数据包源地址发生改变？

• 資深大佬 : huangya

  不会，ACCEPT 后这个包就在 chain POSTROURING 不会继续跑了，不会到下一条 rule MASQUERADE 中.
  ACCEPT 与 RETURN 的区别可以看:

  https://ipset.netfilter.org/iptables.man.html#:~:text=ACCEPT%20means%20to%20let%20the,the%20previous%20(calling)%20chain.

  >ACCEPT means to let the packet through. DROP means to drop the packet on the floor. RETURN means stop traversing this chain and resume at the next rule in the previous (calling) chain. If the end of a built-in chain is reached or a rule in a built-in chain with target RETURN is matched, the target specified by the chain policy determines the fate of the packet.

  关键点有两个:
  1.RETRUN 是返回到 calling chain.然后继续匹配下一条 rule.
  2.ACCEPT 是直接接受了（在 build-in chain 或者子 chain ），那 build-in chain 和 build-in chain call 的子 chain 中的 rule 都不会匹配了。

  另，调试 iptables 可以用-j LOG 看包是如何跑的。

• 主 資深大佬 : nozer

  @huangya 太感谢了! 搞懂了，谢谢。