policy只是針對traffic的安全放行...
VIP所採用的DNAT行為並不是他的責任....
這種secrity policy的設定除了安全性的增進...
也保證了inbound/outbound traffic的方向性...
那些traffic操作DNAT, 那些traffic操作SNAT, 又或著那些操作shaper, QoS, BYOD control等...
統一由security policy來控制...
user確實只專注一個security policy的部分..
VIP只是一個責任上的耦合分割..
他的職責就是單純負責DNAT的操作, 至於那些traffic "需不需要" 做DNAT, 統一由policy來控制...
這種security policy的高度設計同樣使得任何interface幾乎沒有太大差別..
任何一個interface可以是DMZ, 也可以不是....
目前policy control還缺乏IPv6的混合式操作...
IPv4和IPv6 policy控制的職責幾乎是一樣的...
如果一個unified security policy同時控制IPv 4和6便可以讓policy進一步得到簡化以及大幅節省管理時間(如果有需要IPv6的操作)..
vxr wrote:
VIP指定的port與Service不相符就是unmatched...
traffic直接被drop...
Service開ANY...
但是依賴的還是VIP指定的forwarding port...
只有VIP做成DMZ設計才可能存在各種安全性風險...
security policy只是一道防護措施以及方便管理各種traffic處理的功能操作....
如果有20多個VIP物件...
那通常開ANY的機會居多..
因為一個一個指定Service port還蠻麻煩的.....(恕刪)
vxr 兄前面有解釋過 VIPs & Policy 之間的關係, 實際 NAT 是依據 VIPs 的設定在運作, 但同時 Security Policy 那裡也要 match 才算成立.
但有時候為了方便把 Service Port 開成 ANY, 似乎又違背了 vxr 兄最前面所提的, 為了提高安全性, 所以在 VIPs & Policy 這兩邊都做了多處的 '重覆' 參數的設定.
不過小弟不再執著於系統的設計邏輯了, 反正現階段系統規定要這麼設定, 就依照規定做就好.
FB: Pctine
良好的policy UI自定化可快速理解各種policy的操作以及避免混亂...
在FOS設計上policy的每個欄位顯示都是可以自訂的...
但他是被存放在cookie...
如果需要持久性保存...
需操作CLI控制...
例如如下管理UTM的policy欄位設定...
config system settings
set gui-default-policy-columns "#" "policyid" "last_used" "count" "session" "srcintf" "source" "dstintf" "dstaddr" "schedule" "service" "action" "nat" "profile-group" "traffic-shaper" "logtraffic" "status" "comments"
end





























































































