跳至主要內容

什麼是 DNS Filtering?如何阻擋顧客 WiFi 上的有害內容

這份詳盡的技術指南解釋了 DNS Filtering 如何在網路層運作,以保護企業顧客 WiFi 的安全,涵蓋部署架構、規避預防以及 Captive Portal 整合。它為零售、餐旅和公共場所領域的 IT 主管提供實用的實施指導,幫助他們執行內容原則、保護品牌聲譽,並證明符合 PCI-DSS 和 GDPR 的規範。來自飯店和零售環境的實際案例研究,說明了決定部署成功的實際權衡和設定決策。

📖 8 分鐘閱讀📝 362 字數🔧 2 範例4 練習題📚 9 關鍵定義

收聽此指南

查看播客逐字稿
歡迎來到 Purple 技術簡報。今天我們將深入探討企業網路安全的一個關鍵組件:適用於客用 WiFi 的 DNS 過濾。 對於管理飯店、零售或大型場館等公共網路的 IT 經理、網路架構師和營運總監而言,提供無縫的 WiFi 體驗只是成功的一半。另一半則是確保該網路的安全、合規和效能。客用網路本質上是不受信任的環境。如果沒有強大的控制措施,它們就會成為惡意軟體傳播、非法下載和存取不當內容的管道,這會嚴重損害場館的品牌聲譽。 今天,我們將探討為什麼 DNS 過濾是降低這些風險最有效的架構方法、它與其他替代方法的比較,以及部署的最佳實踐。 讓我們從技術深度探討開始。DNS 過濾實際上是如何運作的? 其核心在於,網域名稱系統(即 DNS)是網際網路的電話簿。當訪客連接到您的 WiFi 並在瀏覽器中輸入網站地址時,他們的裝置必須將該人類可讀的網域轉換為機器可讀的 IP 位址。 在標準設定中,此查詢會傳送到預設的解析器,通常由 ISP 提供。在採用 DNS 過濾的安全架構中,該查詢會被攔截。您網路上的 DHCP 伺服器會指派一個特定的、安全的 DNS 解析器給訪客裝置。當查詢到達此過濾引擎時,它不只是解析 IP - 它還會根據即時威脅情報來源和您的特定企業策略來評估該網域。 如果該網域是良性的,就會傳回 IP,並繼續進行連線。這會在幾毫秒內完成。然而,如果該網域被標記為惡意 - 例如已知的網路釣魚網站或殭屍網路命令與控制伺服器 - 或者如果它違反了您的內容策略,例如成人內容或非法串流媒體,引擎就會進行干預。它要麼傳回一個不可路由的 IP 位址(一種稱為沈沒路由 "sinkholing" 的技術),要麼將使用者重新導向至品牌封鎖頁面。 為什麼這種方法優於深層封包檢測(DPI)或代理過濾等其他方法?這歸結為效能和規模。 DPI 需要網路硬體來檢查每個封包的負載。在體育場等擁有五萬名並行使用者的密集環境中,DPI 會引入巨大的延遲,並且需要極其昂貴的硬體。另一方面,DNS 過濾在連線生命週期的最起點運作。它評估一個輕量級的 UDP 封包。一旦 DNS 解析完成,實際的資料傳輸就會直接在用戶端和安全伺服器之間進行。過濾引擎不需要處理繁重的資料負載。這導致幾乎零延遲影響,通常小於兩毫秒。此外,由於 DNS 過濾在建立連線之前就開始運作,因此它完全與協定無關。無論應用程式是嘗試使用 HTTP、HTTPS、FTP 還是自訂連接埠,它都會阻斷連線。 讓我們來看一個真實世界的範例。假設有一家擁有五百間客房的奢華連鎖飯店。他們因為非法串流媒體而面臨高頻寬佔用,且收到了關於在公共區域可以存取不當內容的投訴。他們的物業管理系統透過 VLAN 共享相同的實體基礎設施。 這裡正確的方法是部署雲端 DNS 過濾解決方案,並專門針對 Guest WiFi VLAN 設定 DHCP 範圍,以指派雲端 DNS IP。至關重要的是,您要在閘道器上實作防火牆規則,以阻斷從 Guest VLAN 到除已核准 DNS 伺服器以外任何外部 IP 的輸出 UDP 和 TCP 連接埠 53 流量。接著,您建立一個阻斷成人內容、盜版和惡意軟體類別的原則。關鍵的架構決策是確保物業管理系統 VLAN 繼續使用內部 DNS 伺服器,將過濾原則完全隔離在訪客網路中。 現在,讓我們來談談實作上的陷阱。 最基礎的步驟是網路設定。您必須設定您的閘道器或 DHCP 伺服器,將 DNS 過濾服務的 IP 位址發送給 Guest VLAN 上的所有用戶端。 但這裡有一個關鍵的經驗法則:阻斷連接埠 53,否則過濾形同虛設。 如果您只是透過 DHCP 指派 DNS 伺服器,精通技術的使用者或惡意應用程式可以透過硬編碼他們自己的 DNS 設定 - 例如 Google 的 8.8.8.8 或 Cloudflare 的 1.1.1.1 - 來繞過過濾器。為了防止這種規避行為,您必須在閘道器實作防火牆規則,阻斷所有指向您指定過濾伺服器以外任何 IP 位址的連接埠 53 輸出流量 - 包括 UDP 和 TCP。 另一個主要的陷阱涉及 Captive Portal。我們經常在零售和旅宿業的部署中看到這種情況。場所實施了嚴格的 DNS 過濾,突然之間,訪客無法登入了。為什麼?因為 Captive Portal 仰賴外部網域進行身分驗證 - 例如用於社群登入的 OAuth 提供者。如果您的 DNS 過濾器在使用者通過身分驗證之前就阻斷了這些網域,您就會陷入兩難的困境。使用者無法存取網際網路來進行身分驗證,也無法透過身分驗證來存取網際網路。 解決方案是確保您的 Walled Garden 已正確設定。您必須在 DNS 過濾原則中,明確地將 Captive Portal 體驗所需的網域加入允許清單。第二個真實場景:一家大型零售購物中心希望提供免費的公共 WiFi,並搭配用於收集人口統計數據的 Captive Portal,同時遵守嚴格且適合家庭的企業規範。將 DNS 過濾與 Captive Portal 整合時,需要將驗證網域(Google、Facebook 和任何身分識別提供者)新增至驗證前的允許清單。接著,只有在使用者成功通過驗證後,才會套用內容過濾原則。這種方法將潛在的技術衝突轉化為無縫的使用者體驗。 現在,讓我們針對在實際環境中常見的場景進行快速問答。 第一個問題:我們可以在訪客網路中使用透明 HTTPS 檢查來代替 DNS 過濾嗎? 不行。透明 HTTPS 檢查需要將自訂根憑證部署到終端裝置以解密流量。您無法將憑證部署到非受控的訪客裝置。這會產生嚴重的安全性警告,從而破壞他們的瀏覽體驗。DNS 過濾才是適用於內置裝置(BYOD)環境的正確方法。 第二個問題:DNS 過濾如何處理 DNS over HTTPS(即 DoH)? DoH 會加密 DNS 查詢,這可以繞過傳統的網路層級攔截。最佳實踐是利用威脅情資資料來源,在防火牆阻擋已知 DoH 提供者的 IP 位址,強制用戶端回復使用標準且可過濾的 DNS。 第三個問題:DNS 過濾是否有助於合規性? 絕對有。對於像 PCI-DSS 這樣的框架,證明網路分割和強大的存取控制是強制性的。雖然訪客網路應始終與付款網路分割,但在訪客網路上防止惡意軟體執行可以降低場所的整體風險狀況。就 GDPR 而言,證明您已採取合理的技術措施來防止濫用您的網路,是合規的積極指標。 總結今天的簡報。DNS 過濾不僅僅是安全性最佳實踐 - 它也是企業公共網路的營運必要條件。它提供了一種可擴充、低延遲的機制,以阻擋惡意威脅並實施可接受的使用原則。 五個關鍵要點是:第一,DNS 在建立連線之前攔截網域查詢,增加的延遲不到兩毫秒。第二,始終在防火牆阻擋輸出連接埠 53,以防止透過自訂 DNS 設定進行規避。第三,仔細設定您的 Walled Garden(圍牆花園),以確保 Captive Portal 驗證網域不會被阻擋。第四,使用 VLAN 分割將過濾原則專門套用於訪客流量,以保護營運系統。第五,DNS 過濾透過展示強大的網路存取控制,支援符合 PCI-DSS 和 GDPR 的要求。 您的下一步:稽核您目前的訪客網路 DNS 設定、確認出站連接埠 53 已受限,並對照您啟用的 DNS 篩選原則來檢視您的 captive portal 隔離園區。 感謝您收聽本次 Purple 技術簡報。如需更詳細的部署指南與架構模式,請造訪 purple.ai。

header_image.png

執行摘要

對於管理大規模公共網路的企业 IT 決策者而言,確保安全、合規且高效能的瀏覽體驗是一項至關重要的營運職責。飯店、零售和公共場所的 Guest WiFi 網路是惡意活動和違反政策行為的首要目標 - 從機器人網路命令與控制流量到非法串流媒體和不當內容。本指南提供關於 DNS filtering 的權威技術參考:在網路邊緣阻止有害內容並降低風險最有效率的機制。

與消耗資源的深層封包檢測 (DPI) 或僵化的 IP 阻止清單不同,DNS filtering 會在初始網域名稱解析請求時進行攔截。藉由對照即時威脅情資來源評估查詢,它能在任何載荷交換之前,阻止與惡意或不當網域的連線。這種方法確保了高吞吐量和極低的延遲 - 這對於支援數千名同時上線使用者的環境至關重要。

實施強大的 DNS filtering 不僅能保護場所的名譽,還有助於遵守數據安全法規和家庭友善使用政策。對於利用 Guest WiFiWiFi Analytics 等解決方案的組織而言,整合 DNS 級別的控制是一項基礎安全要求,為訪客網路堆疊的每個其他層級提供支援。

技術深度剖析:DNS Filtering 如何運作

DNS filtering 在網路架構中扮演主動安全層的角色。當用戶端裝置嘗試存取網域時,本地 DNS 解析器會攔截該查詢。此查詢不會立即傳回 IP 地址,而是被轉發到過濾引擎,過濾引擎會根據政策和威脅情資進行評估,然後決定解析或阻止它。

解析管道

DNS filtering 解析管道包含四個不同的階段。第一,查詢攔截(query interception):訪客裝置連接到網路並透過 DHCP 取得 IP 設定,其中指定將 DNS filtering 伺服器作為主要解析伺服器。第二,原則評估(policy evaluation):過濾引擎接收到查詢(例如 malicious-domain.com),並將其與即時更新的分類阻擋清單和動態威脅情報源進行交叉比對。第三,解析或黑洞化(resolution or sinkholing):如果該網域安全無虞,引擎會解析出實際的 IP 位址,連線便照常進行。如果該網域違反原則,引擎會傳回一個不可路由的 IP 位址 - 此技術稱為黑洞化(sinkholing) - 或者將使用者重新導向至自訂品牌的阻擋頁面。第四,記錄儲存(logging):不論是已解析或已阻擋,每次查詢都會記錄下來,以供稽核與分析之用。

architecture_overview.png

架構優勢

與其他替代的內容控制方法相比,部署 DNS filtering 具有明顯的優勢。延遲開銷微乎其微 - DNS 查詢是輕量級的 UDP 封包,評估時間不超過 2 毫秒,對終端使用者來說完全感覺不到。此方法也具備協定無關性(protocol-agnostic):因為過濾是在連線建立之前進行,因此無論底層的應用程式協定(HTTP、HTTPS、FTP)或連接埠號碼為何,它都能發揮作用。與基於 URL 的代理過濾相比,這是一項顯著優勢,因為後者在沒有於每個端點部署自訂根憑證的情況下,無法檢查加密的 HTTPS 流量 - 而這在未受管理的訪客裝置上是無法實現的。

擴充性是另一項核心優勢。單一強大的 DNS 叢集每秒可處理數百萬個查詢,非常適合體育場、大型會議中心或多據點 Retail 部署等高密度環境。對於複雜的多租戶拓撲,DNS filtering 可輕鬆與基於 VLAN 的區段策略整合,詳細內容請參閱 MDU的多租戶 WiFi 架構設計

comparison_chart.png

方法 部署複雜度 延遲影響 粒度 訪客網路適用性
DNS Filtering 極低 (<2ms) 網域級別 推薦
URL/Proxy Filtering 中 (10–50ms) URL 級別 有限 (HTTPS 問題)
Deep Packet Inspection 高 (50–200ms) 承載資料級別 不推薦
IP Blocklists 僅限 IP 層級 僅限補充
Application Firewall 應用程式層級 補充

部署指南

部署 DNS filtering 需要精心規劃,以在不中斷合法流量的情況下確保全面覆蓋。以下步驟概述了適用於 HospitalityHealthcareTransport 以及零售環境且不受特定廠商限制的部署策略。

步驟 1:網路分段與 DHCP 設定

最穩健的部署方法是設定網路閘道或 DHCP 伺服器,將 DNS filtering 伺服器的 IP 位址分配給所有訪客用戶端。這可確保加入網路的任何裝置都會自動使用安全解析程式,而無需在端點上安裝任何代理程式。

對於具有複雜拓撲結構的環境 - 例如在 為 MDU 設計多租戶 WiFi 架構 中所述的環境 - 請確保將專用於訪客流量的 VLAN 嚴格透過過濾的 DNS 進行路由,而營運 VLAN(PMS、POS、建築管理)則繼續使用內部解析程式。這種基於 VLAN 的隔離是符合 PCI-DSS 的先決條件,該規範強制要求在持卡人資料環境與不可信的訪客網路之間進行嚴格的網路分段。

步驟 2:防止規避 - 封鎖 Port 53

這是許多部署失敗的關鍵步驟。僅透過 DHCP 分配 DNS 伺服器是不夠的。在裝置上設定了自訂 DNS 設定(指向 8.8.8.8 或 1.1.1.1)的使用者將完全繞過過濾器。解決方案很簡單:在閘道上套用防火牆規則,封鎖除了指定的過濾伺服器之外,指向任何 IP 位址之 Port 53 (UDP 與 TCP) 的所有輸出流量。這會強制所有 DNS 流量透過受控的解析程式傳輸。

此外,請考慮封鎖 DNS over HTTPS (DoH)。DoH 會將 Port 443 上的 HTTPS 流量中的 DNS 查詢進行加密,使其在網路層級上與一般網頁流量無法區分。最有效的防範措施是維護已知 DoH 提供者 IP 位址(Cloudflare、Google、NextDNS)的封鎖清單,並在防火牆上封鎖它們。

步驟 3:原則定義與類別管理

根據場所的需求和受眾建立詳細原則。針對公共 WiFi 的典型基準原則包括封鎖安全性威脅(惡意軟體、網路釣魚、Botnet C2 伺服器)、成人內容和非法活動(盜版、非法串流)。在特定領域中,可能適合封鎖其他類別:例如 Healthcare 設施封鎖賭博與武器,或企業訪客網路在工作時間內封鎖社群媒體。

步驟 4:Captive Portal 整合 - 圍牆花園 (The Walled Garden)

這是部署中技術細節最複雜的環節。Captive Portals 在允許訪客獲得完整網路存取權限之前,需要先對他們進行驗證。在預先驗證階段,訪客裝置處於受限狀態 - 它只能存取 Captive Portal。如果在此階段啟用 DNS filtering,它可能會阻擋社群登入(Google OAuth、Facebook Login)或接受服務條款頁面所需的外部網域。

解決方案是正確設定 walled garden:這是一組在驗證完成前,於 DNS filtering 策略中明確允許的網域。此清單必須包含 Captive Portal 自己的網域、任何 OAuth 識別提供者網域,以及呈現入口網站資源所需的任何 CDN 端點。未能正確設定此項是導致訪客連線體驗中斷最常見的原因。此整合考量同樣適用於辦公室環境,正如 Office Wi Fi: 最佳化您的現代辦公室 WiFi 網路 (此處保留原文連結格式)中所討論的。

步驟 5:阻擋頁面自訂與使用者溝通

提供清晰、具備品牌形象的阻擋頁面,解釋內容為何被限制,並在阻擋屬於誤判(false positive)時提供申請審查的管道。這能顯著減少服務台的工單量,並強化場所對於維護安全瀏覽環境的承諾。設計良好的阻擋頁面能將限制轉化為品牌接觸點。

最佳實踐

若要將 DNS filtering 的效果發揮到最大,請遵循以下產業標準建議。

高可用性架構:設定次要與三次 DNS 解析器。如果主要過濾引擎失效,流量應無縫轉換至次要解析器。避免將 ISP 的預設解析器設定為備份,因為這會在故障期間完全規避過濾機制。

定期策略稽核:持續審查記錄與分析數據,以識別誤判與新出現的威脅模式。將 DNS 查詢記錄與您的 WiFi Analytics 平台整合,以便將瀏覽行為與網路效能指標進行關聯分析。

威脅情資來源品質:DNS filtering 的有效性與威脅情資來源的品質和即時性直接成正比。評估廠商時,請考量情資更新頻率(每小時更新為基本要求,即時更新更佳)、類別涵蓋範圍的廣度,以及誤判率。

DNSSEC 驗證:在支援的情況下,於過濾解析器上啟用 DNSSEC 驗證。這能防止 DNS 快取污染攻擊,避免攻擊者植入虛假的 DNS 記錄以將使用者重新導向至惡意網站。

疑難排解與風險緩釋

即使有健全的架構,營運問題仍會發生。以下是最常見的故障模式及其解決方案。

誤判 (False Positives):合法的網域被錯誤歸類為惡意或違反政策。請維持一個易於存取的允許清單 (allowlist) 管理流程,以及針對使用者回報的快速回應 SLA。監控已封鎖查詢與總查詢次數的比例;異常高的封鎖率是政策設定過於激進的強力指標。

Captive Portal 失敗:如上所述,這是由於遺漏 walled garden 條目所致。在預先驗證階段,透過擷取測試裝置的 DNS 查詢並識別哪些查詢被封鎖來進行診斷。將這些網域新增至預先驗證允許清單中。

效能降級:DNS 基礎設施不足可能導致瀏覽速度變慢,這通常表現為網頁載入時間變長,而非完全無法使用。部署本地快取解析器 (caching resolver) 以減輕上游過濾引擎的查詢負載。監控 DNS 查詢回應時間;任何超過 50ms 的情況都需要進行調查。

DoH 規避:如果分析顯示儘管有防火牆規則,流量仍流向已知的 DoH 供應商,請驗證 DoH 供應商 IP 的封鎖清單是否為最新,且防火牆規則已套用至所有訪客 VLAN 出口點。

ROI 與商業影響

DNS filtering 的投資報酬率 (ROI) 遠不止於簡單的風險緩釋。對於 Hospitality 場所而言,確保家庭友善的環境會直接影響品牌聲譽和淨推薦值 (NPS)。訪客(尤其是未成年人)在場所網路上存取不當內容的單一事件,都可能帶來重大的聲譽與法律風險。

透過封鎖耗費頻寬的非法串流媒體,場所還可以最佳化網路效能,從而延緩昂貴的基礎設施升級。在一間擁有 500 間客房且有大量訪客從盜版網站進行串流傳輸的飯店中,部署 DNS filtering 來封鎖這些網域可使尖峰頻寬使用量減少 20 - 35%,這直接改善了所有訪客的體驗,並避免了對額外上行鏈路容量的需求。

從合規性的角度來看,展示強大的網路安全控制措施通常是 PCI-DSS 認證的先決條件,並支援 GDPR 設計時保護數據的原則。對於雲端處理解決方案,DNS filtering 的部署成本分攤到每位使用者每月僅需極少費用,與監管罰款或損害品牌的安全事件之潛在成本相比,幾乎微不足道。 對於在多個站點管理高頻部署的 IT 團隊而言,營運開銷極低。雲端 DNS filtering 解決方案不需要任何地端硬體,能自動更新威脅情報,並透過單一儀表板對數百個位置提供集中式原則管理。

關鍵定義

DNS 過濾

一種安全技術,在解析或封鎖所請求的網域之前,攔截 DNS 查詢並根據原則與威脅情資進行評估。

企業級訪客 WiFi 網路內容控制的主要機制,運作於網路層,無需安裝端點代理程式。

DNS 墜道(DNS Sinkholing)

針對指向惡意或違反原則網域的 DNS 查詢,回傳虛假、不可路由的 IP 位址,以阻止建立連線的作法。

用於中和惡意軟體命令與控制(C2)流量,並阻止存取有害網站,而使用者不會收到標準的連線錯誤訊息。

Captive Portal

公共存取網路的使用者在獲得完整的網際網路存取權限之前,必須進行互動的網頁,通常用於接受條款、進行驗證或收集資料。

對於訪客引導與資料收集至關重要;必須與 DNS 過濾仔細整合,以避免 walled garden 的兩難困境。

Walled Garden

在預先驗證階段,DNS 過濾原則中明確允許的一組網域,使 Captive Portal 和驗證服務能在使用者接受條款之前正常運作。

在進行 DNS 過濾的訪客網路中,walled garden 設定錯誤是導致 Captive Portal 體驗中斷最常見的原因。

深層封包檢測(DPI)

一種網路封包過濾形式,在封包通過檢測點時檢查其資料負載,以進行內容層級的分析。

比 DNS 過濾更消耗資源的替代方案;對於高吞吐量的訪客網路並不實用,且在沒有憑證攔截的情況下無法檢測加密的 HTTPS 流量。

DNS over HTTPS (DoH)

一種將 DNS 查詢加密於 HTTPS 流量中的協定,可防止網路層級對 DNS 查詢進行攔截。

可用於繞過傳統的 DNS 過濾;管理員應在防火牆封鎖已知的 DoH 提供者 IP,以維持過濾覆蓋率。

VLAN (Virtual Local Area Network)

一種邏輯網路分段,可在交換器或路由器層級執行,將裝置分組而與其物理位置無關。

對於將訪客 WiFi 流量與內部企業或營運網路進行隔離至關重要,也是符合 PCI DSS 合規性的先決條件。

威脅情資摘要(Threat Intelligence Feed)

持續更新的資料流,包含已知惡意網域、IP 位址和 URL 的資訊,用於支援安全系統運作。

威脅情資摘要的品質與即時性,直接決定了 DNS 過濾佈署防範新註冊惡意網域的成效。

DNSSEC (DNS Security Extensions)

一組 IETF 規範,為 DNS 回應增加密碼學驗證,以防止快取污染和欺騙攻擊。

在支援的 DNS 過濾解析伺服器上應啟用此功能,以防止攻擊者植入虛假的 DNS 記錄來重新導向使用者。

範例

一家擁有 500 間客房的奢華連鎖飯店需要在其顧客 WiFi 上實施內容過濾。他們目前因非法串流媒體而面臨高頻寬佔用,並收到有關在公共區域可存取不當內容的投訴。他們需要一個不會影響其物業管理系統 (PMS) 效能的解決方案,該系統透過 VLAN 共享相同的實體基礎架構。

  1. 部署雲端 DNS Filtering 解決方案。設定顧客 WiFi VLAN 的 DHCP 範圍,將雲端 DNS Filtering IP 指派為主要和次要解析伺服器。 2. 在閘道器上實施防火牆規則,阻擋從顧客 VLAN 到除核准的 DNS Filtering 伺服器之外任何外部 IP 在連接埠 53 上的所有輸出 UDP 和 TCP 流量。 3. 建立內容過濾原則,阻擋「成人內容」、「盜版/著作權侵權」、「惡意軟體/網路釣魚」和「殭屍網路 C2」。 4. 設定帶有飯店商標和清晰訊息的品牌專屬阻擋頁面。 5. 至關重要地,確保 PMS VLAN DHCP 範圍繼續使用內部 DNS 伺服器。阻擋連接埠 53 的防火牆規則必須僅限於顧客 VLAN 的範圍,不能套用於全域。 6. 監控前 30 天的 DNS 查詢記錄,以識別並解決影響合法顧客服務的任何誤判。
考官評語: 此方法使用 VLAN 正確隔離了顧客流量,確保關鍵的 PMS 基礎架構完全不受影響。限定於 VLAN 範圍的防火牆規則是關鍵的架構決策 - 在全域套用連接埠 53 阻擋會破壞營運系統的內部 DNS 解析。透過阻擋輸出連接埠 53,它能防止使用者使用自訂 DNS 設定來繞過過濾器,解決了公共網路部署中最常見的漏洞。30 天的監控期對於調整原則並在升級到更嚴格的設定之前建立信心至關重要。

一家大型零售購物中心希望提供免費的公共 WiFi,但必須遵守嚴格的家庭友善公司原則。他們還需要透過具有社群登入選項的 Captive Portal 收集人口統計資料。他們應該如何設定 DNS Filtering,以同時支援這兩種需求,而不會中斷註冊流程?

  1. 將 DNS Filtering 解決方案與現有的網路閘道器整合,透過顧客 SSID 上的 DHCP 指派過濾 DNS IP。 2. 在套用任何阻擋原則之前,先設定 Walled Garden (圍牆花園)。將以下內容新增至驗證前允許清單:Captive Portal 自己的網域和 CDN 端點、Google OAuth 網域 (accounts.google.com, oauth2.googleapis.com)、Facebook 登入網域 ( www.facebook.com , graph.facebook.com) 以及任何其他正在使用的身分識別提供者。 3. 套用內容過濾原則 (成人、賭博、惡意軟體、盜版類別),使其僅在成功驗證後啟用。 4. 在顧客 VLAN 上實施連接埠 53 外出阻擋。 5. 使用零售中心的品牌形象和關於家庭友善瀏覽的清晰、友善訊息來客製化阻擋頁面。 6. 在上線前,使用多種裝置類型 (iOS, Android, Windows) 測試完整的註冊流程。
考官評語: 此場景突顯了 Captive Portals 與 DNS 過濾之間關鍵的互動關係。若未將驗證網域(即 walled garden)加入白名單,將會導致上網引導體驗中斷,使用者無法完成社群媒體登入,進而產生大量的技術支援求助。多裝置測試步驟是不可妥協的:不同的作業系統處理 Captive Portal 偵測的方式各不相同,有些會嘗試向特定的 Apple 或 Google 網域進行 DNS 查詢以驗證連線能力。這些網域也必須包含在 walled garden 中。品牌化的封鎖頁面能將限制轉化為正面的品牌強化,傳達場所對於提供安全環境的承諾。

練習題

Q1. 一位體育場 IT 總監回報,自從在訪客 WiFi 上部署 DNS 篩選後,訪客便無法在 Captive Portal 上完成社群登入流程。該入口網站使用 Google 和 Facebook OAuth。最可能的架構缺陷是什麼?您會如何解決?

提示:請考慮在預先驗證階段(即使用者接受服務條款之前),需要哪些外部資源。

查看標準答案

社群登入網域(accounts.google.com、oauth2.googleapis.com、 www.facebook.com、graph.facebook.com)尚未新增至 walled garden - 即 DNS 篩選策略中的驗證前允許清單。由於使用者尚未通過驗證,篩選器會阻擋這些查詢,因而造成惡性循環。解決方案是將所有必要的 OAuth 和身分識別提供者網域明確新增至驗證前允許清單,然後在重新部署之前,跨 iOS、Android 和 Windows 裝置重新測試完整的上網引導流程。

Q2. 為了提高網路效能,網路架構師建議實作透明 HTTPS 代理伺服器來檢查所有訪客流量,以取代 DNS 篩選。為什麼這種方法根本不適用於公共訪客 WiFi 環境?

提示:請思考檢查加密 HTTPS 流量的要求,以及非託管訪客裝置的本質。

查看標準答案

透明 HTTPS 檢查需要向每個用戶端裝置部署自訂根憑證,以便對 TLS 流量進行中間人解密。在受管理的企業網路中,這可以透過 MDM 或群組原則來實現。但在公共訪客網路中,場地無法控制訪客端點,因此無法部署憑證。在沒有憑證的情況下,代理伺服器會在每個 HTTPS 網站上產生嚴重的 TLS 憑證警告,完全破壞瀏覽體驗。DNS 篩選是 BYOD 環境的正確方法,因為它不需要端點代理程式或憑證。

Q3. 某零售連鎖店已透過在訪客 SSID 上經由 DHCP 分配篩選 DNS IP 來部署 DNS 篩選。分析顯示,仍有大量成人內容被存取。最可能遺漏了哪一個網路設定步驟?補救措施是什麼?

提示:技術能力較高的使用者可能會如何覆寫 DHCP 分配的 DNS 設定?

查看標準答案

網路管理員未能實作輸出防火牆規則,以阻擋從訪客 VLAN 到除了核准的 DNS 篩選伺服器之外任何外部 IP 的連接埠 53(UDP 和 TCP)。在其裝置上硬編碼自訂 DNS 設定(例如 8.8.8.8)的使用者完全繞過了 DHCP 分配的篩選解析程式。補救措施是新增閘道防火牆規則,將所有非發送到篩選伺服器的輸出連接埠 53 流量進行重導向或捨棄。此外,可考慮阻擋連接埠 443 上已知的 DoH 提供者 IP,以防止加密的 DNS 繞過。

Q4. 某會議中心正在籌備一項大型國際活動。他們預計在三天內會有 8,000 名並行 WiFi 使用者。他們目前的 DNS 基礎架構由單一地端篩選設備組成。這會帶來什麼架構風險?您會推薦哪些變更?

提示:請同時考慮效能容量與可用性。如果單一設備故障或過載會發生什麼事?

查看標準答案

單一地端設備會帶來兩個關鍵風險:單一故障點(如果它離線,所有 DNS 解析都會失敗,進而導致整個訪客網路癱瘓)以及在尖峰負載下的潛在效能瓶頸。建議:1) 遷移到具有地理分散式解析程式基礎架構的雲端 DNS 篩選服務,該服務能夠每秒處理數百萬個查詢。2) 在 DHCP 範圍中設定至少兩個解析程式 IP(主要和次要),指向不同的雲端解析程式端點。3) 在場地實作本機快取解析程式,以減少上游查詢負載並縮短回應時間。4) 在活動前進行模擬尖峰並行使用者的負載測試,以驗證架構。