跳至主要內容

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

本全方位技術指南深入解析 DNS filtering 如何在網路層運作,以保障企業訪客 WiFi 的安全,內容涵蓋部署架構、規避預防,以及 Captive Portal 整合。此指南為零售、旅宿和公共場所的 IT 領導者提供可行的實作指引,協助其執行內容策略、維護品牌聲譽,並證明符合 PCI-DSS 與 GDPR 規範。來自飯店與零售環境的真實案例研究,闡明了決定部署成功的實際權衡和設定決策。

發佈於 更新於
📖 8 分鐘閱讀340 字數2 範例4 練習題9 關鍵定義

Video overview

收聽此指南

查看播客逐字稿
歡迎來到 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 檢測需要將自訂根憑證部署到終端裝置以解密流量。您無法將憑證部署到未託管的訪客裝置,這會導致嚴重的安全性警告,進而破壞其瀏覽體驗。對於自攜裝置(BYOD)環境,DNS 過濾才是正確的做法。 問題二:DNS 過濾如何處理 DNS over HTTPS(即 DoH)? DoH 會加密 DNS 查詢,這可能會繞過傳統的網路層級攔截。最佳做法是利用威脅情報資料,在防火牆上識別並阻擋已知 DoH 提供者的 IP 位址,藉此強制用戶端降級使用標準且可過濾的 DNS。 問題三:DNS 過濾有助於合規性嗎? 絕對有幫助。對於 PCI-DSS 等架構,證明網路分割和強大的存取控制是強制性的。雖然訪客網路應始終與付款網路分割,但防止惡意軟體在訪客網路上執行,可降低場域的整體風險概況。就 GDPR 而言,證明您已採取合理的技術措施來防止網路遭濫用,是合規性的積極指標。 總結今天的簡報:DNS 過濾不僅是安全性最佳做法,更是企業公共網路營運的必要條件。它提供了一種具備擴充性且低延遲的機制,可阻擋惡意威脅並執行可接受的使用政策。 五大核心要點為:第一,DNS 過濾在連線建立之前攔截網域查詢,增加的延遲不到 2 毫秒。第二,始終在防火牆阻擋輸出連接埠 53,以防止透過自訂 DNS 設定規避。第三,仔細設定您的 Walled Garden(圍牆花園),確保 Captive Portal 驗證網域不會被阻擋。第四,使用 VLAN 分割將過濾政策專門套用於訪客流量,以保護營運系統。第五,DNS 過濾透過展示強大的網路存取控制,支援符合 PCI-DSS 和 GDPR 規範。 您的下一步:稽核您目前的訪客網路 DNS 設定,驗證輸出連接埠 53 是否受限,並根據您現行的 DNS 過濾原則檢視您的 Captive Portal walled garden。 感謝您收聽本次 Purple 技術簡報。如需更詳細的部署指南和架構模式,請造訪 purple.ai。

核心系列的一部分:企業 WiFi 安全指南

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

執行摘要

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

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

實施強大的 DNS 篩選不僅能保護場地聲譽,還有助於遵守資料保護法規和家庭友善的使用政策。對於利用 Guest WiFiWiFi Analytics 等解決方案的組織而言,整合 DNS 層級的控制是一項基礎安全要求,為 guest 網路架構的每個其他層級提供支援。

技術深入探討:DNS 過濾的運作原理

DNS 過濾是網路架構中主動運作的安全防護層。當用戶端裝置嘗試存取某個網域時,本地 DNS 解析器會攔截該查詢。此查詢不會立即傳回 IP 地址,而是先轉發到過濾引擎,由該引擎根據原則與威脅情資進行評估,進而決定予以解析或封鎖。

解析流程

DNS 過濾解析流程分為四個不同階段。第一,查詢攔截:訪客裝置連線至網路並透過 DHCP 接收 IP 設定,該設定將 DNS 過濾伺服器指定為主要解析器。第二,原則評估:過濾引擎收到查詢(例如 malicious-domain.com),並將其與即時更新的分類封鎖清單及動態威脅情資進行比對。第三,解析或沈陷(Sinkholing):若網域安全無虞,引擎會解析出實際的 IP 地址,連線便正常進行。若網域違反原則,引擎則會傳回無法路由的 IP 地址(此技術稱為 Sinkholing),或將使用者導向至品牌專屬的封鎖頁面。第四,記錄:不論是解析或封鎖,每次的查詢都會記錄下來,以供稽核與分析之用。

什麼是 DNS Filtering?如何阻擋訪客 WiFi 上的有害內容 - architecture overview

架構優勢

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

擴充性是另一項核心優勢。單一健全的 DNS 叢集每秒可處理數百萬次查詢,非常適合體育場、大型會議中心或多站點 零售 部署等高密度環境。對於複雜的多租戶拓撲,DNS 過濾能與基於 VLAN 的區隔策略無縫整合,詳細資訊請參閱 為 MDU 設計多租戶 WiFi 架構

什麼是 DNS Filtering?如何阻擋訪客 WiFi 上的有害內容 - comparison chart

方法 部署複雜度 延遲影響 細緻度 訪客網路適用性
DNS Filtering 極低 (<2ms) 網域層級 推薦
URL/代理伺服器過濾 中 (10 - 50ms) URL層級 有限 (有 HTTPS 問題)
深度封包檢測 高 (50 - 200ms) 負載層級 不推薦
IP 黑名單 僅限 IP 層級 僅限補充
應用程式防火牆 應用程式層級 補充

對於您的特定設置有任何疑問嗎?

我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。

實作指南

部署 DNS 過濾需要仔細規劃,以確保在不干擾合法流量的情況下實現全面覆蓋。以下步驟概述了適用於 HospitalityHealthcareTransport 和零售環境的廠商中立部署策略。

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

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

對於具有複雜拓撲結構的環境 - 例如 Designing a Multi-Tenant WiFi Architecture for MDUs 中描述的環境 - 請確保將專用於訪客流量的 VLAN 路由到經過嚴格過濾的 DNS,而營運 VLAN (PMS、POS、大樓管理) 則繼續使用內部解析器。這種基於 VLAN 的隔離是符合 PCI-DSS 的先決條件,該規範強制要求在持卡人資料環境與不受信任的訪客網路之間進行嚴格的網路分段。

步驟 2:防止繞過 - 封鎖連接埠 53

這是許多部署失敗的階段。僅透過 DHCP 分配 DNS 伺服器是不夠的。在其裝置上設定了自訂 DNS 設定 (指向 8.8.8.8 或 1.1.1.1) 的使用者將完全繞過過濾器。解決方案很簡單:在閘道上實作防火牆規則,封鎖所有針對 連接埠 53 (UDP 和 TCP) 到指定過濾伺服器以外之任何 IP 位址的外網流量。這會強制所有 DNS 流量通過受控的解析器。

此外,請考慮封鎖 DNS over HTTPS (DoH)。DoH 將 DNS 查詢加密在連接埠 443 上的 HTTPS 流量中,使其在網路層級上無法與正常網頁流量區分。最有效的緩解措施是維護已知 DoH 供應商 IP 位址 (Cloudflare、Google、NextDNS) 的黑名單,並在防火牆上封鎖它們。

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

根據場域需求與受眾建立細部原則。公用 WiFi 的典型基本原則包括封鎖安全性威脅(惡意軟體、網路釣魚、殭屍網路 C2 伺服器)、成人內容以及非法活動(盜版、非法串流)。在特定產業中,可能需要設定其他類別:例如 醫療保健 機構封鎖賭博和武器,或企業訪客網路在上班時間封鎖社群媒體。

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

這是部署中技術細節最複雜的層面。Captive Portal 要求訪客在獲得完整網際網路存取權限之前進行驗證。在預先驗證階段,訪客裝置處於受限狀態 - 僅能存取 Captive Portal。如果在此階段啟用 DNS 過濾,可能會封鎖社群登入(Google OAuth、Facebook Login)或服務條款同意頁面所需的外部網域。

解決方案是設定正確的 walled garden:這是在驗證完成前,在 DNS 過濾原則中明確允許存取的一組網域。此清單必須包含 Captive Portal 自身的網域、任何 OAuth 身分識別提供者網域,以及轉譯入口網站資產所需的任何 CDN 端點。未能正確設定此項是導致訪客上網體驗中斷最常見的原因。此整合考量同樣適用於辦公室環境,正如 Office WiFi: Optimise Your Modern Office WiFi Network 中所討論。

步驟 5:自訂封鎖頁面與使用者溝通

提供清晰、具備品牌形象的封鎖頁面,解釋內容受限的原因,並在封鎖屬於誤判時提供申請審查的途徑。這能大幅減少服務台的工作票單,並強化場域對安全瀏覽環境的承諾。設計良好的封鎖頁面能將限制轉化為品牌接觸點。

最佳實踐

為極大化 DNS 過濾的效果,請遵循以下產業標準建議。

高可用性架構:設定次要與三次 DNS 解析器。如果主要過濾引擎變得無法使用,流量應無縫容錯移轉至次要解析器。避免將 ISP 的預設解析器設定為備用方案,因為這會在發生中斷時完全繞過過濾。

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

威脅情報來源品質:DNS 過濾的有效性與威脅情報來源的品質和即時性成正比。評估廠商時,請考量其情報更新頻率(每小時更新是基本要求,即時更新更佳)、類別涵蓋範圍的廣度,以及誤判率。DNSSEC 驗證:在支援的情況下,於過濾解析器上啟用 DNSSEC 驗證。這可防止 DNS 快取污染攻擊,此類攻擊中,攻擊者會植入虛假的 DNS 記錄,將使用者導向惡意網站。

疑難排解與風險緩釋

即使擁有強健的架構,也難免會出現營運問題。以下是最常見的故障模式及其解決方法。

誤判:合法網域被錯誤分類為惡意或違反政策。請維持一個易於存取的白名單管理流程,並針對使用者回報提供快速回應的 SLA。監控遭封鎖查詢次數佔總查詢次數的比例;異常高的封鎖率是政策設定過於激進的強力指標。

Captive Portal 失敗:如上所述,這是由於遺漏 walled garden 條目所致。診斷方法是在預先驗證階段擷取測試裝置的 DNS 查詢,並識別哪些查詢遭到封鎖。將這些網域加入預先驗證白名單中。

效能降低:DNS 基礎設施不足可能導致瀏覽速度變慢,表現為網頁載入時間過長,而非直接失敗。部署本地快取解析器以減少上游過濾引擎的查詢負載。監控 DNS 查詢回應時間;任何超過 50ms 的情況都值得深入調查。

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

ROI 與商業效益

DNS 過濾的投資報酬率 (ROI) 遠不止於簡單的風險緩釋。對於 旅宿業 場所而言,確保適合家庭造訪的環境會直接影響品牌聲譽和淨推薦值 (NPS)。只要發生一次訪客 - 尤其是未成年人 - 在場所網路上存取不當內容的事件,就可能帶來重大的商譽與法律風險。

藉由封鎖佔用大量頻寬的非法串流媒體,場所還能最佳化網路效能,延後昂貴的基礎設施升級。在一間擁有 500 間客房且有大量房客在盜版網站進行串流播放的飯店中,部署 DNS 過濾以封鎖這些網域可降低 20 - 35% 的尖峰頻寬使用率,直接提升所有房客的體驗,並推遲對額外上行鏈路頻寬的需求。

從合規角度來看,展示強健的網路安全控制通常是獲得 PCI-DSS 認證的前提,並支持 GDPR 的「規劃即保護資料」原則。對於雲端解決方案而言,部署 DNS 過濾的成本折合每位使用者每個月僅需極低費用,與潛在的監管罰款或損害品牌形象的安全事件成本相比,完全微不足道。

對於管理多個站點高頻率部署的 IT 團隊而言,營運開銷極小。雲端 DNS 過濾解決方案不需要任何地端硬體、會自動更新威脅情資,並可從單一儀表板對數百個位置進行集中式原則管理。

關鍵定義

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 (虛擬局域網)

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

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

威脅情資摘要 (Threat Intelligence Feed)

一個持續更新的資料串流,包含已知惡意網域、IP 地址和 URL 的資訊,用於為安全系統提供支援。

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

DNSSEC (DNS 安全擴充功能)

一組 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) 在活動前進行負載測試,模擬高峰期同時在線使用者,以驗證此架構。

對於您的特定設置有任何疑問嗎?

我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。