本頁面由 Cloud Translation API 翻譯而成。

規則評估順序

規則評估會根據您在政策中設定的規則，判斷是否應允許或拒絕網路要求。系統會根據下列屬性做出決策：

規則的優先順序：整數值越小，優先順序就越高。
SessionMatcher：與下列工作階段層級屬性相符：
- 來源機器的 IP 位址
- 來源機器的服務帳戶
- 來源機器的安全標記
- 目標機器的主機名稱
ApplicationMatcher：比對下列 HTTP 要求屬性：
- 網址
- 路徑
- 要求標頭

如需所有 SessionMatcher 和 ApplicationMatcher 屬性的清單，請參閱「SessionMatcher 和 ApplicationMatcher 中可用的屬性」。

規則評估的運作方式

系統會按照下列順序評估規則：

系統會先評估優先順序較高的規則。
優先順序最高且符合 SessionMatcher 和 ApplicationMatcher 屬性的規則，會決定要對流量採取的動作。
如果要求不符合該規則的 SessionMatcher 和 ApplicationMatcher 屬性，系統會評估優先順序最高的下一個規則。
這個程序會持續執行，直到找到符合要求的規則，或已評估所有規則為止。如果找不到相符項目，系統會拒絕要求。

設定 TLS 檢查功能之前

您必須先瞭解下列規則評估情境，再設定 TLS 檢查功能：

用戶端可以將 HTTP 要求傳送至 Proxy 伺服器。系統會使用所有可用資料 (包括主機名稱、來源身分、HTTP 標頭和路徑) 評估要求。

如果要求獲准，HTTP 流量就會傳送至目的地。不過，如果要求遭到拒絕，則不允許 HTTP 流量通過。
用戶端可以向 Proxy 傳送 HTTP CONNECT 要求，藉此建立前往目的地的 TCP 通道。當用戶端想要傳送任意 TCP 流量，或透過 Proxy 與目的地建立端對端 TLS 連線時，就會執行這項操作，就像 HTTPS 一樣。
如果規則含有相符的 SessionMatcher 屬性，且不含 ApplicationMatcher 屬性，且規則評估結果為允許流量，則會建立通往目的地的通道，並為流量提供 TCP 代理程式。這項規定適用於 HTTPS 和 TCP 流量。
如果優先順序較高的規則無法判斷應對要求採取哪項動作，則會繼續進行規則評估。如果評估作業繼續執行至具有 ApplicationMatcher 屬性的規則，則會將建立通道的流量解讀為 HTTP 或 HTTPS。

如果基礎資料不是 HTTP 或 HTTPS，連線就會失敗。

如果底層資料為 HTTP，系統會評估要求，包括主機名稱、來源識別資訊、HTTP 標頭和路徑。系統會根據評估結果允許或拒絕流量。
針對 HTTPS 流量，只有在啟用 TLS 檢查標記時，系統才會評估規則；否則，系統會略過該規則。
針對 HTTPS 流量，只有在符合下列條件時才會檢查規則：
- 已啟用 TLS 檢查標記。
- 流量符合 SessionMatcher 屬性。

設定 TLS 檢查規則的建議

如果您想允許 TCP 流量，則允許 TCP 流量的規則優先順序必須高於允許 HTTP 流量的規則。
使用 SessionMatcher 屬性，可將含有 ApplicationMatcher 屬性的規則納入嚴格範圍，盡量避免將不相關的流量解讀為 HTTP。
允許 TLS (包括 HTTPS) 流量但不執行 TLS 檢查的規則，可解讀為 TCP Proxy 規則。
為避免對流量進行不必要的 TLS 檢查，TLS 檢查規則的優先順序應低於非 TLS 檢查規則。或者，如要針對不相符的流量快速失敗，請使用 SessionMatcher 屬性，將 TLS 檢查規則的範圍嚴格限制。

TLS 檢查規則設定範例

請參考以下兩個範例中的規則。

範例 1

在本例中，我們假設有其他優先順序較低的規則。請考慮下列兩個規則：

規則 1

description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

規則 2

description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

在這個範例中，Secure Web Proxy 會將這兩個規則解讀如下：

允許 TCP 流量但禁止特定類型的 HTTP 要求是互斥的，因為 TCP 流量可能包含 POST 要求。
規則 2 一律禁止流量。系統會拒絕這項要求，因為從標記 12345 到 example.com 的流量會遭到攔截，並解讀為 HTTP，以便評估 HTTP 方法。
如要讓規則 2 生效，您可以使用下列任一解決方案：
- 建議做法：將規則 2 的優先順序調高至更高層級 (優先順序：5)。
- 範圍規則 1，避免允許的流量與其 SessionMatcher 屬性重疊：
  
  sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')
  
  我們不建議採用這個解決方案，因為這會導致許多重疊的規則難以維護。

範例 2

請考慮下列兩個規則：