原本架构是网关都落在了核心交换机上，内网服务器网段是192.168.100.0/24 ，大概有70多台设备，北京办公网和天津IDC之间是通过两台centos server 做的IP tunnel 隧道，也就是内部服务器网段到天津10.0.0.0/16
的路由是 server BJ---CSW --- centos BJ --tunnel ---centos TJ --- server TJ ；然后我就开始出方案，方案是
这样的（简写）：
    1. 先配置防火墙，策略先放行
    2.配置防火墙路由，原来在核心交换机上路由指向 centos的，在防火墙上也写上一条指向centos，原来在核心交换机上路由指向外网的，防火墙上写上一条路由指向核心交换机，也即是一条默认指向交换机
    3.交换机上写上一条指向100网段路由指向防火墙（因为只针对100服务器网段做调整）
    4.将网关签到防火墙上，关闭核心交换机上100网段的svi

    我们来分析一下，这样割接之后，数据的流动，例如服务器网段要上公网，
    去包分析：首先将数据包扔向了防火墙，然后防火墙走默认路由扔向了核心交换机，核心交换机走默认路由扔向了互联网（nat步骤在此处省略）；
    回包分析 ：首先互联网将包回到交换机上（nat步骤在此处省略），交换机查看到100网段的路由发现扔向防火墙，防火墙查看100网段与自己直连，直接扔向了对应的服务器
   
    整个过程有问题吗 ，没有问题。
   
    确实上网是没有问题的。这个我割接完之后也测试了，但是博客们看看我上图所化牵涉到一个IPtunnel 隧道，对的，就在过这个隧道时有问题的，博客们看到这，能否停止继续往看下去，想想问题会出现在什么地方？

    好，我们现在来呈现问题的所在，我之前说到过，这个DMZ区域有多台设备，都是服务器网段100，正常情况下北京与天津server数据交互的流程是这样的：
    去包分析：server（100段）---网关100.254（FW）--- centos BJ --- IP TUNNEL --- centos TJ --- server （10.0.0.1）
    回包分析：server（10.0.0.1） --- centos TJ --- IPTUNNEL --- centos BJ --- server （100）   

 
    大家看到这能看出问题的所在吗，好像来回路径不一致吧，会影响数据通信吗，针对ICMP好像没有问题
但是针对于TCP的流量就有大问题了；

    试想 telnet 数据包会怎么流过, 首先要进行tcp的三次握手吧:
    第一次，100网段server--- 10.0.0.1 第一次握手，经过防火墙 tcp syn （没有问题）
    第二次，10.0.0.1 ---  100 网段server 第二次握手，不经过防火墙 （没有问题）
    第三次，100网段server --- 10.0.0.1 第三次握手，经过防火墙 （有问题）
 
    问题就出现在第三次握手上面了，大家知道数据包要经过防火墙，tcp要有完整的链接，像这种，第一次，第三次握手经过防火墙，第二次握手不经过防火墙，对于防火墙来说是不完整的tcp链接，那么像这样的数据包第三次握手就会被防火墙干掉，所以问题就出现了；

三. 总结结论
   1.当我们在学习的时候，我们可能会清楚的记得，防火墙对于不完整链接是无法通过的，但是遇到实际问题时可能就会忽略这个问题，还需要更多的经验总结
   2.分析问题还是要全面，对于数据包的封装解封装要清楚的知道，数据包的来回路径要考虑清楚，来回路径不一致时候会产生问题。