客戶某兩地都要加入F5 BIGIP+AWAF各一台, 且都使用inline mode -> two arms bridge/transparent mode
Site1:
這裡FW只有一台, 沒有問題
Site2:
這裡FW有兩台, 且是A/A mode
這樣有陷阱, 要想個解法
客戶某兩地都要加入F5 BIGIP+AWAF各一台, 且都使用inline mode -> two arms bridge/transparent mode
Site1:
這裡FW只有一台, 沒有問題
Site2:
這裡FW有兩台, 且是A/A mode
這樣有陷阱, 要想個解法
近日使用Resolver Cache去幫客戶解一個原本在雲上的zone,要改為解成private ip
這個zone可以從內部走到私有雲.
而這個zone一開始說只有一個A record.....意思是說未來此zone會成長, 而且要考慮到Resource (ex:A record)維護方便, 於是研究後就用Resolver Cache處理, 還有Cache功能.
客戶原本是只用local BIND.
本來Resolver Cache研究出來, Lab測試也正常(Lab裡F5是用WideIP)還很高興, 部屬到線上後, 災難開始了.
忘記解析有順序, 且也不知道有一個特性在(Cache與BIND的前後順序).
DNS解析順序:
iRule->Wide IP->DNS Express->Cache(ex:Resolver Cache)->local BIND
後來Support說可以在DNS Express去綁local BIND, 這樣順序就能走在Cache前面.
然後昨日研究DNS Express如何綁BIND進來.....讀了多篇文章才研究出來.
高興高興.
今日終於搞懂Wireshark TCP protocol : allow subdissector to reassemble tcp streams (for HTTP)使用時機
摘要:
當你只想知道http delta, 不care封包重組事情, 此時就要關掉
當你case封包重組事情, 此時就要打開, 此時看到的http delta就不準