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


传统的防火墙组网一般都是类似这样的:【标准的三层结构做法:服务器集群、内网核心交换、公网边界】
记一次老牌防火墙产商SSG系列多Wan口环境下NAT/Zone的排错心得


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


不过也有企业因为内网交换需求不大,选在内网网关复用在防火墙的结构(去除内网核心交换):

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

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

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

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


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


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

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


划重点,敲黑板了

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

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

拓扑示意图如下:
记一次老牌防火墙产商SSG系列多Wan口环境下NAT/Zone的排错心得
PS:

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

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


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


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


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


其实我朋友搞了那么久也是这个原因之一,关于对对NAT和防火墙机制的理解
另外一个原因是对防火墙特有定义的Zone的理解有问题
还有一个主要原因是对SSG系列防火墙接口下面的两个模式的理解不足,截图如下:
记一次老牌防火墙产商SSG系列多Wan口环境下NAT/Zone的排错心得
圈红的地方很常见,但很容易出问题


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

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

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中勾选这个地方,截图如下:
记一次老牌防火墙产商SSG系列多Wan口环境下NAT/Zone的排错心得


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

所以流量从DC服务器(10.99.200.100)发起时候,SSG防火墙分别依序check/match了1)路由2)NAT)Policy,到policy这里时候它认为是对外的流量,故它默认帮你匹配到PAT的过程,所以导致无法Ping。我上面截的图是数据从外到内,这里的流程是从内到外。希望读者能正反向理解下,我找个文献介绍这一流程的,如下截图:
记一次老牌防火墙产商SSG系列多Wan口环境下NAT/Zone的排错心得


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

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


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


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

                                                ——————Allen在路上

QQ:549675970

Wechat:

Johnny_JunJun

QZONE:

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

E-mail:

      549675970@qq.com

      allen_junjun@hotmail.com

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