| 作者 |
文章 |
|
|
 2023-03-07, 15:55 |
    
|
|
|
| 2023-02-10, 17:08 |
|
|
|
在17版前多WAN的情境下，對外要走哪個WAN？
可以直接在防火牆規則中指定，相當直覺方便∼
但在18版後，NAT與防火規則分拆開來，
對外要從哪個WAN出去變的麻煩多了...
要從哪個WAN出去，18版後只能在policy routing中額外去定義。
那麼policy route，vpn route跟static route三種路由的優先順序，在18版中又有什麼變化呢？
在XG中，可透過以下指令於console設定static route，VPN與policy route的優先順序。
system route_precedence set static vpn sdwan_policyroute
17版預設的優先順序為policyroute vpn static，
18版後預設的優先順序則改為static sdwan_policyroute vpn。
問題來了，18版中預設的路由優先順序是否符合一般情境？
順子認為，在只有一條WAN，且沒有site to site VPN的情境下，
維持預設設定是OK的，畢竟環境單純。
但若有多條WAN，內部網路或主機會依不同需求透過對應的WAN連外，且有site to site VPN的情境下，
這預設的路由順序是要需要調整的。
在有site to site VPN的情境下，VPN tunnel兩端網段的通導最為重要，
所以VPN要設定為最優先。
若內部有其它router來通導到內部其它網段，而policy route只是用來指定對要走的WAN，
那麼static route的優先權要大於policy route，
不然去到內部其它網段的路由會被policy route搶走而從指定的外網出去。
總結來說，順子建議18版後的路由優先順序可調整為vpn static sdwan_policyroute，
這樣的優先順序比較符合大部分的情境。
PS.
17版就沒有這些困擾，Sophos真的是在搬磚砸腳！
不知道會不會有一天，又把NAT跟Firewall rule綁在一起了...
♥順子老婆的網拍，請多關照∼
If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
|
|
| 2023-01-31, 17:33 |
|
|
|
客戶於Proxy mode下，出現了XG發出過期憑證給外部真實站台的問題。
由於憑證過期，用戶端的瀏覽器無法成功瀏覽外部站台。
網路上查到這是一個bug(NC-100078/NC-100265)，
可以透過清除 /var/certcache/ 目錄下的憑證快取．來解決此問題。
但又不建議刪光此目錄下的所有快取，所以我就開了case詢問原廠。
原廠給了以下advanced shell的指令，
透過以下指令來清除快取，再重啟web proxy服務來排除此憑證過期問題。
touch /var/certcache/.clear_all_certs_on_reload
service -ds nosync awarrenhttp:restart
經客戶測試後，問題順利排除！
順子留下此筆記。
♥順子老婆的網拍，請多關照∼
If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
|
|
| 2023-01-09, 10:55 |
|
|
|
Sophos XG在V18版後做了很大的變革，
NAT規則自原本防火牆規則分拆後，造成很多規則設定上的問題，
甚至有幾個客戶因為NAT規則的錯誤配置，而導致XG的失聯！
原本我以為在這情況下，只能恢復出廠預設值，然後再把備份的組態檔倒回去。
(這時候你就知道組態備份密碼與SSMK的重要性了吧!)
不過昨天客戶讓我知道了另一種更有效率的做法 - enable appliance access。
其實console下的這個指令，我在一開始接觸Sophos XG時就知道了。
system appliance access enable
我知道這指令在執行後，可以無視Device Access中的設定，
直接放行介面IP的連入權限。
但這指令 enable 後，會丟棄所有外出到internet的流量，
所以在正常運作情況下，appliance access是要保持在disable這個狀態的。
我以為V18版後，錯誤的NAT規則會持續在XG中運作發酵，
即便是 enable appliance access，也無濟於事...
但客戶讓我知道即便在錯誤的NAT規則作用下，
還是能透過 enable appliance access 來放行介面IP的連入能力，進而去修復錯誤的NAT規則，
完成後再將appliance access disable即可。
這真是很重要的一個資訊啊！
(當然問題發生時，你還是必需找到console線直連XG，才有辦法進console去下達這個指令。)
♥順子老婆的網拍，請多關照∼
If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
|
|
| 2022-11-25, 15:03 |
|
|
|
Sophos的ATP模組能在traffic透過XG做routing時，即時的過濾攔阻有害連線，
但在網域環境中，最頭痛的就是DNS Client的解析問題。
雖然惡意domain的DNS解析被XG的ATP攔下來了，
不過網域中client的DNS是指向內部的DNS Server，
當client欲連到惡意domain時，第一步的DNS解析工作會交給內部DNS Server來進行，
內部DNS Server沒有惡意domain的IP對應資訊，因此會再向上層DNS主機要求解析，
以至於ATP攔截事件中，攔的來源IP往往都是內部的DNS Server，而不是直正的DNS Client...
找不出來真正有問題的DNS Client，不是DNS Server也不是ATP的問題，
它們都正常的執行交付的工作．這是網域環境架構下的限制。
那麼在這樣的架構下，有沒有辦法揪出真正的DNS Client呢？
順子想到了一個做法，不過它需要DNS Server的配合。
既然DNS解析工作是由內部的DNS Server來進行，那麼我們就直接在DNS Server上建立一筆該domain的IP對應record，
例如將惡意domain msdnupdate.com 對應到 10.199.199.2 這個沒在使用的IP。
如何設定？Windows的DNS主機可以參考 這一篇 的做法。
然後在XG上啟用一個閒置介面，配置一個zone與這個假IP同網段的IP，例如 10.199.199.1/29，
接著設定內部到這個zone(或IP)的阻擋規則，並勾選log記錄，
這樣當內部電腦欲連到這個惡意domain時，DNS Server就會指向這個假IP，
而電腦依照DNS解析出來的結果，透過XG routing要連到這個假IP時，就會被XG上的阻擋規則所記錄下來，
我們只要去查看log，就可以清楚知道有哪些內部IP試圖連到這個惡意domain，揪出真正的DNS client！
為了避免連線被ATP所攔截，設定完成後，
請將這個惡意domain加到ATP的exception中，做例外放行，由設定阻擋規則來進行攔阻。
這個方法在實做上有幾個重點要注意。
- 綁IP的網卡必需為up狀態，簡單來說就是這張網卡必需接上switch，
這樣介面路由才會運作，導向假IP的流向才會routing到這個介面，進而被防火牆規則阻擋而留下記錄。
若只是設定好IP資訊，但網卡介面為down，則介面routing不會生效。
網卡介面可以是一般網卡、VLAN或是Alias IP，
若使用Alias IP來設定，那封鎖記錄的防火牆規則需小心定義，以免連帶擋掉所有正常流量。
- 用來補抓DNS Client IP的防火牆規則必需是阻擋類型，
若採用放行規則，則該網卡介面必需真的接到一台設定假IP的主機才會留下記錄，
大大的增加複雜度。
♥順子老婆的網拍，請多關照∼
If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
|
|
| 2022-09-20, 14:14 |
|
|
|
| 2022-05-09, 10:35 |
|
|
|
| 2022-02-18, 17:11 |
|
|
|
| 2022-01-25, 16:31 |
|
|
|
| 2021-10-06, 15:39 |
|
《分享》MTA mode吊詭的policy設定
《分享》routing defer (-51):retry time not reached
《分享》18版後的路由優先順序
《分享》Proxy mode下XG發出過期憑證
《分享》揪出ATP事件中真正的連線client
《分享》通行費詐騙
《分享》SSLVPN客戶端軟體EoL？
《分享》V18的Direct Proxy設定
SD WAN Policy Route
