Open mmmiii33 opened 7 years ago
只简单给思路
1、服务端需要路由表,不然它怎么知道如何访问10.88.16.33? 加类似路由表 ip route add 10.88.16.0/24 dev mv0 via 10.37.21.2
2、客户端防火墙,需要允许 mv0 口进来的包,并且 forward 到 lan 口允许。即,在你zone minivtun in accept 之外,还需要个 rule forward from minivtun to lan
程序提供了一个 "-v" 选项,用于向特定的客户端IP做路由,可以参考一下。 例如,服务器IP是 10.37.21.1,客户端IP是 10.37.21.2,服务器希望通过 10.37.21.2 访问其下面的网段 10.100.0.0/16,服务器端可以这么执行:
minivtun -l ....... -n mv0 -a 10.37.21.1/24 ... -v 10.100.0.0/16=10.37.21.2
route add -net 10.100.0.0/16 mv0 # 这里的'mv0'跟写成'gw 10.37.21.2'等价
感谢给的思路,从2个思路上来看问题应该都不存在,不知还有没有其他的思路。 1、路由的问题应该不存在,两端都有写到对端的路由,服务端防火墙是这样设置的 。 zone minivtun input output forward accept rule forward from any to any 2、客户端是台Centos,应该不存在防火墙规则的问题,连iptables也都没有装,仅仅做路由上的转发。
@rssnsj 感谢rssnsj的解答,添加"-v"选项后服务端能够正常和客户端通信了!
minivtun -l 0.0.0.0:6000 -a 10.37.21.1/24 -e hillstone -n tun0 -v 10.88.16.0/24=10.37.21.2
ip route add 10.88.16.0/24 dev tun0
@rssnsj 十分感谢!不知道有没有兴趣添加一个"-tcp"选项,默认使用udp传输报文,遇到一个问题,网络环境中有防火墙,传输大量文件的时候,防火墙有报UDP Flood攻击,此时传输速度会降低很多,使用TCP传输的话应该可以避免这种问题。 实在没能力自己改代码....
服务端运行在OpenWrt路由器上,两端Minivtun的隧道地址已经能够互相访问,但是在服务端主动去访问客户端内网时不通,客户端能够正常访问服务端的内网。
服务端:
客户端:
自己尝试抓包发现问题应该出现在服务端
1、首先ping 500字节大小的报文
2、tun0口有收到报文,大小508字节
3、抓不到被Minivtun封装后的报文,只抓到一些有规律性的48字节长度的报文,默认应该超过1300的时候才进行分片,没错的话此报文应该是心跳?
有2个想法: 1、被OpenWrt上的防火墙规则给Drop掉了,导致Minivtun没有收到报文。 2、Minivtun收到报文后,没有发出。
服务端的配置:
服务端防火墙配置
客户端的配置: