记一次老牌防火墙产商SSG系列多Wan口环境下NAT/Zone的排错心得

昨晚跟着朋友一起troubleshooting一个关于混合云组网的事情，还蛮有代表性的，也非常容易被大家忽略的一个问题。这也是近年来很多80/90/00非常容易被忽略的一个细节，SSG系列都耳熟能详的设备了，但就是这样的老牌产商，我们通过实践来学习里面的原理是非常值得的，今天就是这么一个NAT/POLICY/interface mode引发的5个小时的加班故事。

---

传统的防火墙组网一般都是类似这样的：【标准的三层结构做法：服务器集群、内网核心交换、公网边界】

---

参考的图还是非常标准的，怎么评价呢，现在仍然是主流企业选择的一种IT-infrastructure的结构，成熟且经得起推敲。

---

不过也有企业因为内网交换需求不大，选在内网网关复用在防火墙的结构（去除内网核心交换）：

搞过几年RS和Security的同行都懂，若有企业的流量并不大，并且流量多以南北走向为主，同时网内流量交互不大前提，核心交换机完全可以省略。就如以上图所示一样。

只不过咱们国内的商业准则过去特色，所以很多地方都会选择购买交换机，因为确实这是一笔不菲的“预算”，但懂行的人大有人在。

> 只不过近年来，师傅带徒弟。国内的师傅越来越中国特色，所以到如今的网工，多少有些心神浮躁，不注意修炼内功，一味的追求高逼格满配置。缺忽略技术本身价值所在

---

了解我的朋友，都比较清楚云计算这几年的“势头”，那当然，今天的记录也并不是昨晚和朋友一起排了个小错有感而发。这忙碌了五天，不写点文档和分享总觉得自己好像在浪费时光【所以坚持是难能可贵的】

---

这一点真的得多学学教主-秦柯，真的是偶像。

我一直工作在传统企业到云计算、或者在云计算起步的圈子里。因为本身有传统组网的维护和建设经验，加上搞了几年防火墙，多少对传统企业的路子有个七七八八的认知，所以在工作中传统企业如何过渡到云计算，我也算是没有被颠覆，而是做了自己最擅长的事情。

---

划重点，敲黑板了

今天也是一样，客户有阿里云的服务器，最近申请了一条DC到alicloud的专线，想实现alicloud到DC内网的通信，然后把服务一点一点的迁移上云，数据库保存在本地。前端web服务部署在云端。
补充下，后面我会找个时间给大家分享下，整整2017年，我带着混合云组网方案横扫各大产商和客户的最核心的“concept”。

好了，到了描述昨天困住我同事近五个小时的问题了。

拓扑示意图如下：

PS：

我最反感搞技术的讨论问题，不画图不mark相关参数的。^_^

---

问题描述：
1、公有云服务器（172.16.0.50）能Ping通DC侧的物理服务器（10.99.200.100）
2、但反向从物理服务器到达公有云服务器不通

---

问题分析
1、首先解决路由问题，防火墙我troubleshooting时候大不了policy all permit any。【补充下：防火墙的处理机制，我简单梳理了一个助于大家理解的SSG系列，其他防火墙：类似山石、深信服、PA、网康、checkpoint】，除了国外有些区别，国内基本一致。

---

如下图：

---

注意我标红的地方，这也就是我解决问题最核心基础————防火墙对packet的处理机制

---

其实我朋友搞了那么久也是这个原因之一，关于对对NAT和防火墙机制的理解
另外一个原因是对防火墙特有定义的Zone的理解有问题
还有一个主要原因是对SSG系列防火墙接口下面的两个模式的理解不足，截图如下：

圈红的地方很常见，但很容易出问题

---

再回来看下流量和我标注的地方

1）注意看接口，我们把面向专线侧也define 为 untrust了。
2）所以当路由可达时，防火墙会check policy放行情况
3）且此时与服务直连的（trust）接口为NAT模式，另外两个untrust口是路由模式
4）似乎一切都是正常的，但就是不通

---

---

问题分析：

打开policy的日志，review时候，确认DC的服务器（10.99.200.100）去访问阿里云服务器（172.16.0.50）时候，发现服务的地址被翻译成trust的接口地址了

1、类似cisco的PAT的概念。
2、当我把trust的接口的模式修改为route模式后，DC的服务器（10.99.200.100）可以访问阿里云服务器了，但此时无法出去访问公网了
3、反之测试后，能出公网但无法访问云端服务器，好像有点两全不能齐美的概念。

> 4、根本原因在于我标注的Zone的问题上

---

不要慌，我用最通俗的语言解释下这个过程~~~

我们的策略中放行的Trust-Untrust的流量，在SSG（screen os）中，配置SNAT（现在产商普遍的叫法），只需要在接口模式配置得当（内网NAT&外网Route），配置Policy时候，访问Trust-Untrust流量就相当于做了SNAT的动作。所以不需要额外
————网上有部分的说法说是要额外在policy-advance中勾选这个地方，截图如下：

---

PS：这个可能是内网口和外网口都用了route模式，所以我认为这不是解决，而是错误的配置逻辑背后“填坑”的一种设置方式，所以我个人不推荐。【接口模式设计好即可，哪有这么多坑~】

所以流量从DC服务器（10.99.200.100）发起时候，SSG防火墙分别依序check/match了1）路由2）NAT）Policy，到policy这里时候它认为是对外的流量，故它默认帮你匹配到PAT的过程，所以导致无法Ping。我上面截的图是数据从外到内，这里的流程是从内到外。希望读者能正反向理解下，我找个文献介绍这一流程的，如下截图：

---

所以解决很简单，把跟阿里云链接那边防火墙端口的Zone定义修改为Trust，与内网主机所在接口Zone一致，问题解决~~

当SSG检测到你的流量是在一个ZONE的时候，在ZONE（安全域）内的流量，防火墙会认为你属于网内的可信流量，同时防火墙直连阿里云的专线的接口模式为route模式。所以这也就说通了【之前关于接口模式忽略后，导致很多问题的粗心大意】

---

正如开篇我说的，还有很多传统的IT工程师再金融、证券、银行等公司做技术。SSG也在逐渐被替代，但不可忽略的是，技术的迭代更新也好，国产技术的崛起也好。我们做技术的别忽略白皮书，别忽略细节，如果你现在还只是专注配置，很可能过不了多久“你就会发现自己什么都不会~！！”

---

              一个热爱生活的网工努力成长的故事

                                                ——————Allen在路上

QQ:549675970

Wechat：

Johnny_JunJun

QZONE:

http://user.qzone.qq.com/549675970

E-mail：

      [email protected]

      [email protected]

人生格言：越努力、越幸运