802.1X、FreeRADIUS 和動態 VLAN：完整指南

資訊科技數位 » recursos » 802.1X、FreeRADIUS 和動態 VLAN：完整指南

如果您管理有線或 Wi-Fi 網絡，並且希望在不採用昂貴的網路存取控制 (NAC) 解決方案的情況下，按使用者類型隔離流量，那麼有效利用802.1X、FreeRADIUS 和動態 VLAN 分配是您可以採取的最強大的措施之一，並且值得了解它如何與零信任架構相契合。正確實施後，您可以根據裝置的身份、來源或所屬目錄群組來決定每個裝置連接到哪個網絡，而無需到處建立 SSID 或綁定到單一供應商。

本文將詳細解析整個流程：802.1X 的功能、典型的 FreeRADIUS 配置、VLAN 的 RADIUS 屬性、與 Wi-Fi 控制器和交換器的整合、實際應用案例（Omada、ExtremeCloud IQ、傳統交換器）、常見問題，甚至包括 Azure AD 和 LDAP 中錯誤的屬性格式。我們的目標是讓您在閱讀本文後，能夠清晰、實用地理解相關知識，並將所學內容應用到您自己的基礎架構中，無論規模大小。

802.1X 和動態 VLAN：基本概念和組件

簡而言之，802.1X 標準就像網路的守門人：設備只有通過身份驗證，連接埠或 Wi-Fi 才能允許其存取合法網路。為了實現真正的網路分段，它與使用 RADIUS 屬性的動態 VLAN 分配相結合，伺服器會在客戶端完成身份驗證後決定將其指派到哪個 VLAN。

在任何 802.1X 部署中，無論使用 Omada、ExtremeCloud IQ 或通用交換機，總是會出現三個關鍵元件：

• 祈求者：想要連接的客戶端（筆記型電腦、手機、「就緒」印表機等）。
• 驗證器：控制存取的網路設備（交換器、AP 或 Wi-Fi 控制器）並與 RADIUS 伺服器通訊。
• 身份驗證伺服器通常是 半徑通常使用 FreeRADIUS，它會驗證憑證並決定策略（允許、拒絕、放入某個 VLAN 或其他 VLAN）。

動態 VLAN 的奧妙在於Access-Accept 協定中的 RADIUS 屬性。對於 VLAN，幾乎所有廠商都理解這種類似隧道屬性的組合：

• 隧道類型 = VLAN
• 隧道介質類型 = IEEE-802
• 隧道私有群組 ID =「VLAN ID」（通常是 1 到 4095 之間的數字，儘管它以文字形式發送）

當交換器或 AP 收到具有這些屬性的 Access-Accept 時，如果它支援 802.1X 和動態 VLAN，它會將連接埠或 Wi-Fi 會話分配給RADIUS 指示的 VLAN，忽略連接埠的預設 VLAN 或 SSID（除非 RADIUS 沒有發送任何內容，在這種情況下，它會應用其本機設定）。

動態VLAN的FreeRADIUS配置

FreeRADIUS 是典型的開源 RADIUS 伺服器。它可以安裝在任何配置適中的 Linux 系統上，甚至像 NanoPi NEO 或 Raspberry Pi 這樣的小型硬體上，並且透過適當的配置，它可以應對非常苛刻的環境。對於動態 VLAN，有兩個關鍵方面：定義使用者/群組以及在處理鏈中正確放置模組。

在簡單的部署中，可以直接在FreeRADIUS用戶檔案中定義測試用戶，並為其指派應使用的 VLAN。在 Debian/Ubuntu 系統中，該檔案通常位於/etc/freeradius/3.0/users，VLAN條目如下所示（已簡化和重寫）：

employee10 明文密碼 := "key10" 服務類型 := Framed-User，隧道類型 := VLAN，隧道媒體類型 := IEEE-802，隧道私有群組 ID := "10" employee20 明文密碼 := "key20" 服務服務類型 := := "20"

在這種結構下，FreeRADIUS 會在收到 Access-Accept 請求後傳回三個隧道屬性，以便NAS（交換器或 AP）能夠根據使用者將用戶端置於 VLAN 10 或 VLAN 20 中。關鍵在於網路設備必須支援相應的 RFC 規範，並在配置存取 VLAN 之前遵循這些屬性。

在某些情況下，例如與 ExtremeCloud IQ 整合時，這些屬性必須準確地在Access-Accept 語句中傳送，而不能僅作為「隧道」屬性在 EAP 流程的其他階段傳送。在預設配置中，FreeRADIUS 可能會先處理eap模組，然後再處理files模組（讀取使用者檔案）。這會導致控制器在適當的時間錯過這些屬性。

已被證明行之有效的實用解決方案是修改`/etc/freeradius/3.0/ sites-enabled/default` 文件，將`files`模組移至`authorize`程式碼區塊內的`eap`之前。這樣，FreeRADIUS 會先載入靜態使用者屬性（包括 VLAN），然後再處理 EAP，從而在建置最終的 `Access-Accept` 要求時，隧道屬性會包含在控制器期望的位置。

另一個建議的調整是停用一些安全性較低的 EAP 方法，例如EAP-MD5，這些方法原本就不適用於生產環境。透過編輯檔案`/etc/freeradius/ 3.0/mods-enabled/eap`，註解掉或刪除 MD5 部分，FreeRADIUS 將停止提供此功能。建議您將設定重點放在更可靠的方法上，例如EAP-TLS（憑證）或使用 MSCHAPv2 的 PEAP。

使用 Omada 進行 VLAN 分配：內部 RADIUS 和外部 FreeRADIUS

TP-Link 的 Omada 生態系統（控制器 + 交換器 + AP）將 802.1X 與動態 VLAN 完美集成，既可使用其內部 RADIUS 協議，也可委託給外部 FreeRADIUS 協議。這是一個非常直觀的例子，因為整個工作流程清晰可見。

要使用 Omada 控制器內建的 RADIUS 功能，通常需要遵循三個步驟。首先，在控制器的全域選單中，透過指定 IP 位址（控制器本身的 IP 位址）並啟動「隧道應答」選項來啟用整合 RADIUS功能，以便將隧道屬性正確傳送到存取設備。

然後，進入特定網站後，依序點選「設定」>「設定檔」>「RADIUS設定檔」，編輯設定檔並建立內部RADIUS使用者。 Omada允許您為每個使用者設定名稱、密碼和VLAN ID，這樣，當該使用者進行身份驗證時，控制器會將VLAN屬性直接傳回交換器或AP，而無需經過外部伺服器。

最後，在「設定」>「驗證」>「802.1X」中，啟用 802.1X，選擇內部 RADIUS 設定文件，並明確啟用「VLAN 指派」選項。在同一部分中，選擇需要進行 802.1X 驗證的交換器連接埠。儲存後，連接到這些連接埠的任何裝置都需要進行身份驗證，如果該帳戶已指派 VLAN ID，則會自動將其指派到該 VLAN 中。

如果我們希望將所有功能集中在一個外部 FreeRADIUS 伺服器上，Omada 完全支援此方案。第一步是編輯FreeRADIUS 伺服器上的clients.conf文件，將控制器（或交換器/AP 所在的位址範圍）授權為 RADIUS 用戶端，並指定 IP 位址或子網路以及共用金鑰，稍後我們將在 Omada 中配置該金鑰。

接下來，返回 Omada，依序選擇「設定」>「設定檔」>「RADIUS 設定檔」 ，建立一個外部RADIUS 設定檔。在該設定檔中，輸入 FreeRADIUS IP 位址、認證連接埠（通常為 1812）和共用密碼。在控制器的 802.1X 設定中，選擇此外部設定檔並重新啟用VLAN 分配，標記要保護的連接埠或 SSID。

也可以從控制器本身進行進一步驗證：在「工具」>「終端」中，開啟已啟用 802.1X 的交換器的控制台，並執行命令show dot1x auth-state。如果一切正常，您將看到已認證的連接埠和 RADIUS 指派的 VLAN（例如，連接埠 1/0/1 已認證並關聯到 VLAN 2）。

使用 FreeRADIUS 和 ExtremeCloud IQ 在 Wi-Fi 上實現動態 VLAN

另一個非常全面的例子是ExtremeCloud IQ (XIQ)管理的 Wi-Fi 網絡，它使用 FreeRADIUS 作為認證伺服器。在這種情況下，動態 VLAN 主要根據 FreeRADIUS 傳回的隧道屬性指派給 Wi-Fi 用戶端。

首先，FreeRADIUS 準備像以前一樣在 Access-Accept 中發送這三個屬性：/etc/freeradius/3.0/users中的條目，其中包含用戶及其 VLAN，以及sites-enabled/default中的設置，以便在eap之前處理文件模組，因為 XIQ 期望 Accept 中完全包含這些屬性。

強烈建議停用 EAP-MD5，並使用PEAP/EAP-TLS等方法。修改 EAP 設定檔後，請使用 ` systemctl restart freeradius` 指令重新啟動服務以套用變更。之後，伺服器即可回應由 XIQ 管理的存取點所傳送的請求。

在 Extreme 雲端平台方面，有兩種相關的帳戶類型：免費的Connect 帳戶，允許對最多 10 台裝置進行基本管理，但不支援動態 VLAN 的高級分類規則；以及Pilot版本，提供 90 天的試用期，並啟用基於 RADIUS 屬性的完整設定檔和規則集。

使用 Pilot 帳戶，從「設定 > 網路原則」功能表建立新的網路策略，為其命名，並為簡化作業選擇「僅限 Wi-Fi」。在第二步驟中，定義 SSID，通常設定為使用 WPA2 或 WPA3 的企業網絡，並關聯一個RADIUS 群組。建立此群組時，將 FreeRADIUS 新增為外部伺服器，並指定其 IP 位址、金鑰和連接埠 1812/1813。

接下來，設定使用者設定文件，實際上，這些設定檔是與不同 VLAN（例如 VLAN10 和 VLAN20）關聯的存取設定檔。對於 RADIUS 未傳回隧道屬性的用戶端，將指派一個預設設定檔；但對於動態 VLAN，則根據Tunnel-Private-Group-ID值和其他 RADIUS 屬性定義指派規則。

規則很簡單：「如果來自 Accept 請求的 Tunnel-Private-Group-ID 為 10，則指派使用者設定檔 VLAN 10」；如果為 20，則指派使用者設定檔 VLAN 20，依此類推。 ExtremeCloud IQ 在實務上將這些規則轉換為將用戶端放置在與 FreeRADIUS 傳送的屬性相符的 VLAN上。

最後，您需要在AP的有線側授予這些VLAN存取權限。具體操作是在XIQ中調整AP設定文件，確保上行鏈路連接埠允許所有已配置的VLAN，並保持原生VLAN（通常為VLAN 1）。儲存所有設定並將網路原則套用到AP後，您可以使用XIQ整合的RADIUS測試工具來驗證FreeRADIUS是否可訪問，以及伺服器是否為每個使用者傳回預期的VLAN屬性。

Omada SDN 與 FreeRADIUS：有線與無線 VLAN

Omada 的 SDN 解決方案還可讓您使用 FreeRADIUS 等外部 RADIUS 服務，在有線和無線網路中同時指派動態 VLAN 。這樣就無需建立多個不同的 SSID 或在交換器連接埠上使用靜態 PVID。

典型的網路拓撲結構包括 Omada 控制器、EAP 存取點、JetStream 交換器以及運行在 Linux 系統上的 FreeRADIUS 伺服器。為了允許網路設備向伺服器發送身份驗證請求，需要編輯clients.conf文件，將客戶端位址設定為 Omada 網路範圍（例如 192.168.0.0/24）並設定共用密碼。

接下來，在使用者檔案中設定帳戶，例如定義兩個使用者：一個用於 VLAN10，另一個用於 VLAN20，並分別設定它們的隧道類型 (Tunnel-Type)、隧道媒體類型 (Tunnel-Medium-Type) 和隧道私有群組 ID (Tunnel-Private-Group-Id) 屬性。在 WPA-Enterprise 中，通常還需要修改EAP 設定文件，以使方法適應客戶端類型（例如，Windows 筆記型電腦使用 EAP-PEAP）。

在 Omada 控制器的身份驗證部分，建立一個指向 FreeRADIUS 的RADIUS 設定文件，並選擇「為無線網路啟用 VLAN 分配」選項。這樣可以確保當客戶端透過 WPA-Enterprise 進行驗證時，Omada 將查詢 RADIUS 伺服器並將裝置放置在伺服器傳回的 VLAN 中，而不是 SSID 的靜態 VLAN 中。

此外，還需要在「設定」>「有線網路」>「區域網路」中定義網路的 VLAN 接口，例如，建立兩個邏輯介面分別對應 VLAN10 和 VLAN20，並為其配置各自的 IP 閘道。這樣，當客戶端位於 VLAN10 時，它將獲得該 VLAN 位址範圍內的 IP 位址；VLAN20 也遵循相同的規則。

在無線方面，我們使用WPA-Enterprise 協定建立 SSID ，並指向 RADIUS 設定檔。例如，當用戶端連線並驗證身分時，如果使用 test10，則會從 VLAN 10 取得 IP 位址；如果使用 test20，則會被指派到 VLAN 20，而無需為每種情況建立特定的 SSID。

有線側的邏輯類似，但採用基於連接埠的 802.1X協定。在控制器的相應部分啟用 802.1X，選擇“基於連接埠”類型，啟動“VLAN 分配”，並標記需要身份驗證的連接埠。然後，將連接埠設定檔套用至這些連接埠，新增 VLAN10 和 VLAN20 作為未標記網絡，並確保將 802.1X 控制模式設定為“自動”，以便交換器在偵測到客戶端時自動發起協商。

因此，透過一個 RADIUS 配置和幾個配置文件，Omada SDN 可以確保有線用戶和 Wi-Fi 用戶都能根據其憑證進入相應的 VLAN，而無需建立多個網路或手動調整每個連接埠的配置。

實用範例、常見錯誤和設定技巧

使用 FreeRADIUS 和動態 VLAN 並非一帆風順：從實驗室測試遷移到實際環境時，會反覆出現一些問題，尤其是在處理LDAP/AD 目錄、使用者名稱格式和複雜策略時。因此，良好的網路安全風險管理有助於減少安全事件的發生。

當伺服器使用屬性建構 LDAP 查詢時，會發生非常典型的故障。 %{使用者名稱} 它以 RADIUS 協議的形式到達。在許多 Windows 系統中，格式為： 網域\用戶其中反斜線被編碼為 5c如果 LDAP 模板是用以下方式建構的： uid=%{User-Name}產生的查詢語句大致如下： uid=DOMINIO\5cusuario這很少能與 LDAP 樹中的實際 uid 匹配，傳回零結果。

這表示目錄中找不到使用者的屬性，包括要對應的VLAN 或群組值。因此，伺服器不會新增 Tunnel-Private-Group-Id，用戶端仍保留在交換器或 AP 的預設 VLAN 上。這種模式在 FreeRADIUS 日誌中清晰可見：使用 uid「domain\5user」的 LDAP 查詢，但搜尋結果為空。

已成功應用的實用解決方案是將FreeRADIUS 配置中 LDAP 查詢範本裡的%{User-Name}替換為%{Stripped-User-Name} ，例如：

if ("%{ldap:ldap:///dc=example,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }

這樣，FreeRADIUS 就使用不含網域名稱或斜線的「乾淨」使用者名，搜尋再次成功。一旦 LDAP 傳回正確的項目，伺服器就可以套用邏輯，根據群組、組織單元 (OU) 或特定屬性指派 VLAN，並在 Access-Accept 中再次產生Tunnel-Type、Tunnel-Medium-Type 和 Tunnel-Private-Group-Id。

另一種特殊情況出現在某些交換器上，當連接埠上的靜態 VLAN 配置與動態 802.1X 配置混合使用時。例如，連接埠 17 被配置為靜態 VLAN 4，同時嘗試使用 RADIUS 強制將特定使用者指派到 VLAN 2。如果設備不遵循隧道屬性或動態 VLAN 功能被停用，無論 RADIUS 設定為何，該連接埠仍會將流量視為 VLAN 4。

在這種情況下，務必查看交換器的文檔，明確啟用透過 RADIUS進行的 VLAN 分配支持，並使用 ` show dot1x`或類似命令進行調試，檢查設備是否報告類似「忽略隧道屬性」或「動態 VLAN 分配已停用」的資訊。只有當製造商支援並啟用此功能時，預設會連接到 VLAN 4 實體連接埠的用戶，在以「carlos」或其他使用者名稱進行驗證後，才能真正進入 VLAN 2。

關於在遠端桌面 (RDP) 場景中使用動態 VLAN 的適用性，一直存在著經典的爭論。當 Windows 啟動時進行機器身份驗證，登入時進行使用者驗證時，使用者登入觸發的 VLAN 變更可能會中斷正在進行的 RDP 會話，或因連接埠從「機器」VLAN 切換到「使用者」VLAN 而導致 DNS 問題。許多管理員選擇在這種情況下為所有狀態維護一個 VLAN，或在機器層級和使用者層級指派相同的 VLAN，以最大限度地減少網段變更。

最後，在高階整合層面，人們越來越關注將 FreeRADIUS 與Azure AD連接起來，以便根據雲端群組成員關係確定 VLAN。目前，Azure AD 中還沒有官方的原生模組可以直接尋找 VLAN 的成員關係，需要透過外部腳本、呼叫 Microsoft Graph API 以及進行一些調整才能實現。這是一個動態領域，如果需要穩定且受支援的解決方案，通常會將此邏輯委託給商業網路存取控制 (NAC) 或其他中間元件。

透過有效結合 802.1X、FreeRADIUS 和動態 VLAN 分配，無需繁瑣的 NAC 解決方案即可實現精細的網路分段。這與強大的企業技術安全策略完美契合：從 Omada 或 ExtremeCloud IQ 等控制器到中端交換機，只要隧道屬性得到尊重、LDAP/AD 查詢得到妥善管理，並且能夠根據用戶的身份、角色或連接設備類型明確何時動態地將用戶從一個 VLAN 移動到另一個 VLAN，所有設備都能發揮作用。