centos7使用iptables将报文从tun转发给eth0失败
我参考了几篇博客，想研究一下tun做代理的原理，但是卡在无法将报文从tun转发给eth这个点上
我在阿里云上弄了2台centos7的服务器，然后一台做转发用的代理服务器，一台做客户端
客户端用tun拦截ip包再通过eth转发给代理服务器，之后服务器端从eth读取ip包，写入tun，然后正常流程是tun发现ip包的目的地址不是本机，通过报文转发和nat转化把ip包交给eth发到外网，外网的服务器响应的ip包再经过nat和转发从eth到tun，我再从tun读取转发过来的ip包发给客户端。但是我在tun转发给eth这步失败了
我参考别人的文章，开启了报文转发
echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf
sysctl -p
以及nat转换
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
给客户端的tun赋予ip
sudo ifconfig tun0 192.168.0.11 netmask 255.255.255.0
给服务端的tun赋予ip
sudo ifconfig tun0 192.168.0.10 netmask 255.255.255.0
我尝试用客户端去ping 14.215.177.38 //百度的ip
我打印了服务端从eth获取的客户端发来的ip包
src：192.168.0.11
des：14.215.177.38
这没问题，
然后我把这个ip包写入tun，再从tun读取响应的ip包，打印ip
src：192.168.0.10
des：192.168.0.11
这里就不对了，src的地址应该是14.215.177.38，但是实际上是代理服务器的tun的ip地址，这说明这个包没发送到外网，
ip包交给tun后目标地址被更改成本机tun的地址，然后代理服务器自己响应的了这次的ping请求。
我想知道为什么服务端把ip包交给tun后为什么没发给eth到外网，而是目的地址被改为tun的地址发给本机了。
是我的iptables规则写的有问题吗，还是有哪里没配置导致这种奇怪的现象。
这是我参考的文章
https://www.cnblogs.com/blumia/p/Make-a-simple-udp-tunnel-program.html
你这里看是通过代理上网，本质其实是通过建立隧道来中转数据，我这里举得例子是通过建立gre来通信，本质也是一样的。
如上图，假设服务器B要通过A出去访问百度，那么怎么办呢，首先是在AB之间建立一个虚拟的隧道，仿佛他们之间就连了一根网线，然后B访问百度时将数据通过网线传给A，A在根据路由从A的eth0接口出去并作源NAT，这样就实现了B通过A访问百度，那么实际该怎么做呢：
一、AB之间建立隧道
在B上输入如下三条目命令：
ip tunnel add gre0 mode gre local 2.2.2.2 remote 1.1.1.1 ttl 255
ip link set gre0 up
ip addr add 192.168.1.2/24 dev gre0
在A上输入如下三条命令：
ip tunnel add gre0 mode gre local 1.1.1.1 remote 2.2.2.2 ttl 255
ip link set gre0 up
ip addr add 192.168.1.1/24 dev gre0
这时候在AB上就都建立起了隧道，通过ip a命令可以看到A B上含有gre接口并都还有IP地址，可在两边互ping gre0的接口IP地址检测隧道是否互通，如果不通后面肯定是都不通的。
二、写路由
默认在B上默认路由肯定是从eth0出去的，这时候比如你想通过隧道去A那就得写静态路由，把你想去A得IP加路由通过gre隧道送到A上去，如果时大量数据走隧道就要通过其它方式了，这里先来个简单得我们写个静态路由：
ip route add 14.215.177.38/32 via 192.168.1.1
写完这条路由后你在B上ping 14.215.177.38就到A上去了，这个可以通过抓包来确认，你可以抓eth0或者gre0接口都行，还有一个就是你ping得时候最好带源，
ping -I 192.168.1.2 14.215.177.38
三、在A上写防火墙规则及回程路由
iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
这样应该就ok了。
还有木有懂这方面的大佬啊，可以提供服务器
