JN的電腦網路日常 - Page 11 of 36 - 網路教學與日常學習

工作經驗分享

Gateway打錯而失聯，使用ARP Proxy救回。

在設定網路設備的時候，一個看走眼打錯IP、Subnet、Gateway是很正常的，導致的結果就是失聯。一般會先用同網段的IP去ping，再用不同網路的IP去ping，如果同網段ping得到，不同網段ping得到，那就是典型的「gateway問題」。

Gateway對初學者並不是馬上就能掌握的，Gateway就是同網段路由器的IP，典型設定在.254或者是.1，個人建議.254，因為DHCP可能是從前面發，所以.1可能會被衝突。萬一不是這兩種，那按照慣例的設定可能就會設錯囉。

為什麼會失聯？潛談ARP運作與封包轉送機制。

今天設備A要傳給設備B，設備A會檢查設備B的IP是否與自己是相同網段。

如果是，ARP詢問設備B的IP，設備B回應設備B的MAC，設備A以「設備B的IP加設備B的MAC為目的發送封包」。

如果不是，ARP詢問Gateway的IP，Gateway設備回應自身的MAC，設備A以「設備B的IP加Gateway的MAC為目的發送封包」，接著Gateway設備收到不是自己IP但MAC是自己的封包就會進行路由。

設備網路不一定要跟Gateway IP同網段，一旦有跨網段的需求，就會透過ARP詢問Gateway MAC，所以通常Gateway打錯，ARP就會詢問不到或是詢問到錯誤的設備，導致封包無法被轉送出去。

啟用ARP Proxy之後，如果有其他設備詢問ARP，啟用ARP Proxy設定就會查看自身的ARP是不是有紀錄，如果有就回覆自己的MAC。一般來說，不同網段會搭配不同VLAN，ARP廣播是傳送不到其他的VLAN，啟用ARP Proxy才能穿越VLAN這一限制。

在Windows系統，如果沒有打上Gateway，在跨網段的傳輸會直接找不到。

在網路設定過程中，第一個就是要確保自己的網路能通而且能被管理，這樣才能遠端解決，到近端往往很不方便。能遠端就不要近，

Jian Ning
2022-12-12

Openwrt

Openwrt 新增SMB使用者

Openwrt可以輕鬆掛載外接儲存設備，再透過Samba分享檔案給其他人，當然也希望檔案不被其他人看到，設定許可使用者，存取時就需要透過帳號密碼才能進入著。

最近發現很多時候不是從一篇搜尋到的文章就能完成，就像要限制使用者存取也找了四篇文章才完整解決掉。

從以下文章是在嘗試過程中得到幫助的，希望可以幫助減少一些試錯時間。

在圖形化介面新增Samba，《Day_25 Samba》
如何新增Samba使用者，《OpenWrt 如何設置Samba 服務 – Spimet》
發現新增Samba使用者之前，要先在OS新增使用者，《解決 smbpasswd 設定出現 Failed to add entry for user test 問題》
發現SSH進去OS沒有adduser指令，需要安裝「shadow-useradd」，《Create new users and groups for applications or system services》

Jian Ning
2022-11-22

AAA Aruba

Multi PreShare Key(MPSK)與Aruba CPPM實作

MPSK是個一般WPA2 Personal要提升安全性的方案。

單一個SSID，可以用不同的Key做驗證，藉此避免一般PSK的弱點，一但被人知道KEY，大家都能用，或是存取權限難以切割。

MPSK是個結合MAC Auth與PSK的方法，在安全性上會更強一點。

MPSK只維持同樣的Key，用戶不用調整設定，就能達到權限切割。因為MPSK會結合Radius Auth，所以能透過CPPM的Policy達到單一Key就能切Role，不同Role也擁有不同的存取權限。

MPSK相較於802.1X

升級到802.1x時，因為連線時須提供的資訊不同，所以不可避免要將同事的裝置全部調整，會有痛升級。但用MPSK可以無需調整再做到權限切割。

802.1x會帶入用戶訊息，因此能透過授權(Authorization)再得到相關資訊，例如部門等。但MPSK只能透過設備MAC去篩選要對應甚麼樣的Key，在MAC隨機化當道的現在，基本上只能把重點設備(如IOT)做特別的Key與權限，對於單一用戶多裝置是很難或很花心力才能區分。

MPSK的運作

設備連入SSID，因為是PSK驗證，所以需要輸入一組Key。

Network-Access Server(NAS)也就是AP或是Controller將用戶設備MAC做Radius Auth。

Radius Server(CPPM)收到內容之後，依照Policy篩選，回傳這次的Role與Key。

NAS依照從Radius Server收到的內容，去比照用戶的Key與Server回傳的Key，如果相同則認證通過，如果不同則認證失敗。

Aruba MPSK是使用Vender Specific Attribute(VSA)屬性

MPSK的運作跟PSK不同，一般PSK驗證是最前面的，如果PSK+MAC Auth，那PSK要對才會進行MAC Auth；而MPSK是先以MAC Auth取得Key，然後再對比。MPSK的功能是需要產品有支援才能使用。

Jian Ning
2022-11-15

工作經驗分享

IP衝突導致遠端連線不穩?靜態ARP

前幾天去客戶端上設備，習慣性用Ping掃描，結果發現已經有設備使用待上設備的IP，預期接下來會有IP衝突狀況發生。雖然反應了，不過客戶並沒有掌握那些設備資訊，認為沒有被用到，於是就果不其然的發生IP衝突。

IP衝突為什麼會導致網路斷斷續續的？因為ARP機制。

ARP是個將IP與MAC做一對一綁定，除了一開始會有廣播詢問，問到之後紀錄IP與MAC就能以單播傳送封包。

IP衝突即單一IP有兩個以上MAC出現，而ARP只能一對一綁定，因此就會出現有時候ARP對應的是A MAC，有時候是B MAC。因此單一IP目的的資料，會往存在A MAC的Port或是往存在B MAC的Port送，設備A收到給B的資料會看不懂，反之亦然，能不能順暢收發資料就是看機緣了。

IP衝突會導致兩設備遠端連線皆不穩，那就沒有辦法先「遠端連線」至其中一台改IP，所以大部分就是選擇讓要保留IP的設備下線，再把在線設備的IP更改，接著下線設備重新上線，就能錯開IP。

第二招，因為遠端連線不行，所以只好近端接線進CLI介面更改，缺點就是設備上架的位置不見得好操作，人一定要在設備旁邊，費工費時。

一般來說，對兩台設備都會有管理權，所以第一招執行起來很輕鬆。要是行不通，還能直接用第二招來停損。要是其中一台設備沒有管理權，也不能下線，另一台設備是要拿梯子爬上去接線，有沒有辦法輕鬆地改呢?

回到概念，ARP是做IP與MAC一對一綁定，甚麼IP綁定甚麼MAC是透過別台設備的ARP回應決定的，在IP衝突環境中，同IP會有兩台設備MAC回應，然後自己的ARP被影響，反覆跳。要不如就靜態指定，不要透過詢問去決定。

透過詢問後收到回應的方式記錄ARP是動態ARP，手動設定一對一為靜態ARP。

要是沒有特別需求，基本上不會做ARP設定，一旦設定將IP與MAC綁定，之後設備換IP或是換設備MAC，就會因為ARP而導致網路不通。

ARP的作用範圍只有同網段內的，因此靜態ARP要下在最後一跳的L3上面，如果同網段就下在自己身上。

LAB

先起一台設備，不斷ping 168.95.1.1，再把Aruba AP更改至相同網路IP設定，發生IP衝突現象。

因為Aruba AP跟Controller間是以tunnel溝通，因此可以看到tunnel介面反覆up/down，然後也會導致AP up/down。

開始在Controller刷指令reprovision ap，在up/down的瞬間，永遠趕不上把指令完整送到AP更改，遠端控制失敗。

如果AP與Controller同網段，在Controller設定靜態ARP，過一陣子，AP就會穩定上線，這時候就能慢慢修改IP。

一旦修改好IP，記得刪掉對應的ARP。

Jian Ning
2022-11-11

強制門戶(Captive Portal)機制與OAuth白名單

存取網路認證這一塊有個俗稱「網頁認證」或者稱為「強制門戶」，為什麼要做強制門戶？因為這作法是不受系統平台拘束，只要有瀏覽器都就能進行身分驗證。設定簡單，使用簡單，所以是個廣泛使用的方式

根據《維基百科》，以下有三種常見的實現方式。

HTTP重定向

常見方法之一是將所有全球資訊網流量定向至網頁伺服器，同時向強制門戶返回HTTP重定向。當現代網際網路設備首次連接至網絡時，其將發出HTTP請求並期望返回HTTP 204狀態碼。若設備接收到HTTP 204狀態碼，則設備將認為自己擁有無限的網際網路訪問權限；若設備接收到HTTP 302狀態碼，則設備顯示強制門戶提示。

ICMP重定向

網關也可使用網絡層的網際網路控制消息協議重定向客戶端流量。

重定向DNS

當客戶端請求網際網路資源時，瀏覽器會查詢DNS。在強制門戶中，防火牆將確保僅有網絡DHCP伺服器提供的DNS可被未認證的客戶端使用（或將所有未認證客戶端的請求轉發至此DNS伺服器）。隨後，網絡提供的DNS伺服器將對所有的DNS查詢結果返回強制門戶頁面的IP位址。
強制門戶使用DNS劫持攻擊（與中間人攻擊類似）進行DNS重定向。為了減輕DNS投毒的影響，伺服器通常將存活時間設置為0。

最常見的就是第一種HTTP重定向，使用者可以看到瀏覽器上的url被改為強制門戶的url。這是因為收到回應來自強制門戶位置的HTTP 302狀態，HTTP 302狀態提示使用者需要進行強制門戶認證，而回應的位置也是強制門戶的URL，使用者瀏覽器就自然能切換到強制門戶網頁上。

Response Headers Location為被Redirect後的URL

但在被Redirect之前，需要先有一個「HTTP請求」的動作，才能收到來自強制門戶的回應。因此只要設備一連上網路，就會先測試做個HTTP請求，來測試自己是否HTTP是不受限制的。

Windows10裝置一連上無線網路，就會DNS詢問「www.msftconnecttest.com」，然後測試自身HTTP存取權限是否受限。

因此可以知道是否當前的網路是否需要經過強制門戶才能得到網路存取權限，也就是自動跳通知提示要登入。

像Windows10是測試「www.msftconnecttest.com」，那其他平台也可能有自己的測試網址，透過DNS與錄封包可以抓到。總之，這些網址絕對不能放入白名單內，否則連線成功回傳HTTP 204，就不會觸發提示開啟瀏覽器登入與自動跳轉的功能。

如果要做強制門戶認證，那為什麼還要開其他的白名單呢？

因為要結合Oauth，我們需要連到相關網頁，例如微軟的Azure AD或是Google，帳密資訊與操作都在這些外部網站，因此勢必要開白名單才能順利完成Oauth。

白名單開太多，可能會造成提示登入與網頁跳轉功能失效，因此白名單要盡可能少開才行。

那要怎麼知道Oauth所需要開的Domain?上網搜尋相關白名單？這篇就是因為網路上找到的對應白名單不是太多就是有少，所以得好好了解到底過程中用到甚麼。

一般來說，白名單只會開放強制門戶的URL，因此就先只開放這個。設備連上線後，跳出強制門戶網頁，這時候打開「開發人員工具」，然後點入Oauth的按鈕，因為Oauth相關網頁不在白名單，過程會因此卡過。

一個正常的網頁，上面的檔案要能正常被下載，然後到終端瀏覽器呈現。因此，在Oauth網頁檔案的Request URL，從中找到Domain，然後放入白名單內，反覆此流程，最終達到開最少白名單就能完成Oauth。

以下是測試出來的Azure AD Oauth所需要開的白名單

AzureAD_Oauth
login.microsoftonline.com
aadcdn.msftauth.net
login.live.com

Jian Ning
2022-11-04

Aruba

Aruba Clearpass Onboard (Azure AD) OAuth

本文以Microsoft Azure Activity Directory為整合例子。

OAuth 是 Open standard Authorization 的縮寫，因為變成開放標準，所以可以整合一些社群網站，一個網站就利用取得該社群網站的資訊去註冊會員。

由於雲端化服務，要串接授權服務是透過API，利用ID與Secret去使用API得到權限，與網路傳統的本地端以帳密或是通訊埠對接差異極大。API需要先在後台創造使用權限，然後一番操作才能產生ID與Secret，再放入Clearpass的設定中。

在Aruba Support Portal中可以透過關鍵詞找到Clearpass與其他平台整合的文件，這次的參考文件是《Onboard and Cloud Identity Providers》。

所需條件:

Microsoft Azure
Clearpass
DNS host for Clearpass
Https Certificate

要整合Azure AD，首先要有個Microsoft Azure帳號，第一次註冊會送一些點數使用，但使用上不會用到收費項目，可以大膽使用。

在Microsoft Azure上的設定，請對應參考文件設定，如果順利完成，可以得到API要使用的應用程式ID與其Secret，並且在Clearpass onboard中設定完成。

使用者使用流程：

使用者設備連線到onboard設定用ssid，跳轉至設定網頁
選擇 Microsoft Azure AD，並且登入帳號密碼。(※如果非該AD內的帳號，會跳出錯誤通知)
得到Onboard連線的SSID設定檔，Windows跟MAC可以直接安裝設定檔，而Android跟iOS需要透過安裝「ClearPass QuickConnect」才能打開並執行設定檔。
使用者手動從設定用SSID切換至連線用SSID。
成功連線。

兩種SSID

第一種設定用SSID是Open的認證方法，目的是為了讓使用裝置能到指定網頁登入，並取得相關設定檔才能連上連線用的SSID。此SSID設定的需要受限制，在白名單盡量最少開放能讓各平台可以運作的Domain Name，除了基本的MS，還要開Google Play讓使用者能下載應用程式。開放太多，也會使得跳轉至登入網頁失靈。

第二種連線用SSID是透過第一種SSID下載的設定檔安裝後才能連線，設定檔裡面包含憑證，這憑證會於802.1x中以TLS協定，對Clearpass來說收到Client的憑證，會去向OSCP URL做查閱，看看該憑證是否為有效的憑證。

因此簽發設備憑證CA的OCSP URL是很重要的，如果不是用CPPM預設的Local CA，就要記得修改才會正常。

設定流程：

設定規劃與前準備：決定兩種SSID的名稱分別為何？CPPM DNS Name？能被信任的Https Certificate？Onboard License？要用於簽發使用者憑證的CA?
Microsoft Azure AD設定：請參考《Onboard and Cloud Identity Providers》
Clearpass設定
Controller設定

Clearpass設定

首先進入Policy Manager安裝憑證。

Radius憑證以憑證要求簽名(CSR)向簽發使用者憑證用的CA做簽署，然後放回去。

Https憑證則直接匯入.pfx檔，可以順帶連根與中間CA都匯進去。若是拆開的，根與中間CA要去信任列表手動匯入。

本文是以ClearPass Onboard新增一個Root CA，名為Azure Oauth，若直接使用內建的 Local Certificate Authority也可以。

在Onboard => 配置 => 網路設定，新增一個Profile，SSID名稱為連線用的SSID名稱

在Onboard => 部署和預配 => 配置文件，新增一個Profile，在網路選擇剛剛在網路設置新增的Profile

在Onboard => 部署和預配 => 預設配置，新增一個Profile，配置文件改成上一部新增的Profile。
證書頒發機構與TLS證書頒發機構

在Web-登錄分頁，勾選「使用雲標示/社交網路憑證啟用登錄」，並且添加新身分驗證提供程序。

客戶端ID與密鑰請對照參考文件取得，端點屬性選擇「創建其他端點屬性，已將任何數組轉換為JSON」

添加按鈕html至頁角或頁眉html，Microsoft Azure AD按鈕會出現在該位置。

在Onboard客戶端，地址部分填上CPPM FQDN，按保存。此時CPPM的DNS要能解析出該名稱，否則無法按保存。

按啟動，並且保存該網頁(CPPM Onboar Device Provisioning)的URL，用於設定用SSID的Captive Portal。

在Policy Manager => 配置 => 服務模板與嚮導，使用「Onboard」模板。※不要點到「僅Onboard服務」。

選擇 Authorization 服務 => 授權，新增 Social Login 與 Endpoint。

選擇 Authorization 服務 => 身分驗證，選擇「EAP TLS With OCSP Enabled」然後複製，改名為「EAP TLS With OCSP Enabled_v2」，並且取消選取「所需授權」。OSCP URL改為簽發使用者憑證CA的OCSP URL。

最後到配置 => 網路 => 設備，新增Controller。

Controller設定

透過CLI連入Controller，加入以下白名單。

Azure AD白名單

netdestination microsoftazuread
name privacy.microsoft.com
name aadcdn.msauthimages.net
name passwordreset.microsoftonline.com
name passwordsleakcheck-pa.googleapis.com
name *.google.com
name aadcdn.msauth.net
name aadcdn.msftauth.net
name www.microsoft.com
name login.microsoftonline.com
name *.aadcdn.microsoftonline-p.com
name aad.portal.azure.com
!

Android白名單※需要執行google play下載QuickConnect

netdestination googleplay
name android.clients.google.com
name *.googleapis.com
name *.gvt1.com
name *.ggpht.com
name *.googleusercontent.com
name *.gstatic.com
name clients.l.google.com
name accounts.google.com
name accounts.youtube.com
name connectivitycheck.android.com
name connectivitycheck.gstatic.com
!

CPPM白名單 ※二擇一

netdestination cppm
host <cppm ip>
!

netdestination cppm-onboard-provisioning
name <cppm onboard provisioning url>
!

新增Radius CPPM。

Configuration => Authentication => Auth Servers，新增Radius Server CPPM。

Configuration => Authentication => L3 Authentication，新增Captive Portal Profile，Login Page填入CPPM Onboar Device Provisioning的url，白名單選擇這次新增的白名單，再去Server Group更改為CPPM。

依需求新增Roles，SSID open-test需要使用Captive Portal，新增一個對應名稱的Role，Show Advanced View => More => Authentication，將Captive portal profile選擇剛剛新增的Profile。

在Policies，新增logon-control與captiveportal。

Configuration => WLANs，新增設定用SSID(test-open)、Security為open、Default Role為test-open(Captive Portal Role)。
連線用SSID(test-cppm)、Security為WPA2企業、Default Role為authenticated，勾選Server-derived roles可搭配CPPM作不同角色的權限分配。

Configuration => Authentication => AAA Profiles，將連線用的SSID其Server group改為CPPM。

實際測試

連上設定用SSID之後，輸入一個不允許DNS通行(即白名單之外)的網址，網頁會被redirect到設定網頁，按下按鈕Microsoft Azure AD，進行登入。

Windows (11)

登入成功後會下載ArubaQuickConnect.exe，然後使用系統管理員權限去執行它。安裝完成後，設備會直接連線到連線用SSID。

Android (13)

在使用Microsoft Azure AD登入之後，會先詢問有沒有安裝ClearPass QuickConnect，後面的設定檔要使用該APP才能安裝。下一步會自動下載quick1x.networkconfig，使用ClearPass QucikConnect開啟。順利安裝完成後，仍需要手動切換至連線用SSID。

iPadOS (15.6~15.7) iOS (15.5)

因為自動配置的網路設定檔安全層級為WPA，並不是正確的WPA2企業，所以安裝完後無法正常使用。

在使用Microsoft Azure AD登入之後，會先下載憑證，注意！憑證下載好後一定先進設定安裝，再繼續下載配置檔跟進設定安裝配置檔。不能一次下載兩個再一口氣安裝。

Jian Ning
2022-10-19

Aruba

Aruba Controller搭配SMTP寄信

Aruba Controller可以設定SMTP，用來寄送「訪客帳號註冊資訊」，可以寄給Guest Email跟Sponsor Email。

※SMTP並不用於寄送設備上下線告警！

客戶想要收到訪客帳戶註冊資訊，再用訪客管理員帳號註冊時就要填入Sponsor Email，而網管人員也要對mail server針對Controller做一些放行設定。

關鍵步驟

Controller做SMTP設定
SMTP做放行設定
訪客帳號註冊時，需要填入Sponsor Email。

Controller做SMTP設定

勾選Send automatically at account creation time

SMTP做放行設定

一般來說很難動到客戶端的mail server，於是只好自建練習。這裡使用hMail server。

關於hMail Server的教學，可以參考此篇《3分鐘輕鬆有自己的Mail Server》

在一些產品的SMTP設定中是沒有帳密輸入的，只能指定SMTP Server IP，因此得在SMTP Server針對那些設備IP取消驗證，這樣才能正常寄信。

厲害一點的，可以使用telnet寄信測試，如果寄得出去且收得到，那就沒問題了。

訪客帳號註冊時，需要填入Sponsor Email

這部分常見交給其他同仁處理，想加入訪客帳號便不再需要透過網管人員，因此網管人員想掌握所有的訪客帳號資訊，就需要強調要記得將網管人員信箱填進Sponsor Email。

功能測試

寄信方向必須開內對內，如果想讓訪客收到，就要再開內對外。

Jian Ning
2022-10-06

Excel

Excel帶條件過濾的不重複項計算

透過Countif()可以計算該數在一個範圍出現次數，假設一個數字a出現n次，倒數為1/n，該數的倒數總和為1/n*n=1，因此所有數字的倒數和加總就是不重複的數字共有幾項。

網路上的範例多到此為止，倘若今天想針對一個個體(如姓名)去做不重複項統計，就得針對範圍作過濾。

最難的部分是範圍是浮動的，而且範圍中數值也不能為空，反則會出現計數為零，倒數變成除零的錯誤。如果把值設定預設值填滿，就要在計算不重複數時扣除。

透過filter()去過濾，再Countif()的部分跳出錯誤，原因是先Filter可能會造成範圍不連續導致Countif()的Criteria無法對比，範例中是連續範圍。

換個思路，若以連續範圍為主，就要先以match()找到範圍上限下限，Indirect()框出目標範圍，然後再以Countif()如範例統計，面對缺值空項以Filter()去掉空項出現次數0，最後倒數，再總和，就能得到帶條件的不重複項。

範例Excel下載連結

這種方法有個限制，需要有個連續排序，最後一個match()需要手動指定數值否則會跳error，不過都帶條件了，要做排序是很容易的。

Jian Ning
2022-10-04

Aruba

Aruba Controller Httpd造成CPU負載過重

今年碰到兩個案例，皆是使用「網頁認證」(Captive Portal)作為無線認證的主力。

一個使用Aruba 3000系列控制器，Client數目大概到了一百多。
另一個使用Aruba 7220，總Client可到三千，使用網頁認證的大約占三成。

一旦碰上尖峰，CPU負載會達到100%並持續一段時間。

在6版OS，使用「show cpuload current」可以看見甚麼類型的程序占用CPU的百分比。

httpd是提供網頁服務，像是管理網頁與網頁認證，因此如果無線使用者使用網頁認證，就會有個USER為nobody的程序在。

Aruba控制器在架構主要是個L3 Switch，一般來說流量都會回到控制器上，而Switch的CPU負載過重會造成整個無線網路的不穩定。雖然知道httpd是造成CPU負載過重的主因，可會遇到這問題的案例，通常網頁認證已經佔有很重的部分，所以沒辦法說停就停，以求讓網路表現變得更穩定。

要解決httpd造成CPU負載過重，以下有兩個主思路：
1. 提升CPU運算能力，更新更強大運力的控制器。
2. 降低CPU的負擔，減少網頁認證使用，減少提供網頁造成的CPU負載。

在案例一，替換成7000系列的控制器就把CPU負載穩穩壓在20%以下。
在案例二，每當特定時段會出現大量使用者連線，進行網頁認證的使用者數目可超越三百，即便是7220也會造成CPU使用率飆升至紅線80%，這時候就需要走第二個思路去減少CPU負載。

相比802.1x、MAC、PSK認證，網頁認證需要進行更長的時間、傳送更長的封包，因此如果能將採取前項的無線認證方式，會能夠減少更多的CPU負載，需要鼓勵使用者使用其他方式認證的無線，或是讓網頁認證的無線更難用一點(?)。

要如何讓網頁認證更難用一些? 控制器Captive Portal設定中:
1. 提升Redirect Pause Seconds，讓等待時間久一些。通常是塞車時(CPU負載高於門檻，預設60%)才會用到，過短會造成更快reload網頁的惡性循環。
2. 降低CPU utilization threshold，塞車時會讓CPU負載比這值高一些，建議為預設值60%，如此塞車時CPU使用率會在更高一些，不建議超越90%造成網路不穩。
3. 關閉bypass-cp-landing-page，官方文件寫說關閉能降低cpu負載，開啟與關閉在於網頁轉導的方式不同，預設值為關閉。

塞車的原因是來不及消化，前兩項只是控制塞車造成的影響，並無助於提升消化網頁認證速度而避免塞車。第三點能有效幫助網頁認證造成的CPU負載。

既然網頁在控制器上會有很重的CPU負擔，那可以把控制器的角色單純一點，將網頁外置，如此可避免尖峰時段無線控制器CPU負載過重造成不穩。

在一個中大型場景，網路的穩定度越需要更精確的分工合作，一方面方便管理，另一方面也會有效率。畢竟無線控制器最重要的是管理好無線網路設備，畢竟控制器一倒的話，全部無線都會受影響，為避免電話接不完，還是讓控制器有餘韻能專一在它的專業功能上。

Jian Ning
2022-09-27

Python

Python 清理製表內容的空白分割

在抓取資料時，表格資料會使用製表符號做資料項區隔，方便人眼辨識資訊。

"A       B    C is Great.                     D"

利用 “”.split() 可以使用快速以” “做分隔，產生值為 [“A”, “B”, “C”, “is”, “Great.”, “D”]的串列。不過這樣的結果，並不是期望的[“A”, “B”, “C is Great.”, “D”]串列。

因為是製表符產生的空白，所以項目間的空白長度是浮動的，就沒有辦法利用固定長度洗掉。

這裡面有個資料項是敘述類型，中間帶有” “，需要完整呈現，不能把中間的” “被當成split()的依據。這行資料只是一個樣本，每行資料敘述是不是帶有” “，不一定，” “數量多少也不一定。

但仔細觀察，項目與項目中間的空白會有至少兩個，敘述內的空白只會有一個。

說到「至少兩個空白」的規則，可以使用正則表達式，以「” +”」表示。

搭配””.split()，但因為敘述中會有” “，所以要換個分割符，原則上只要不會出現就好，這裡使用「!@#」。

結合兩者，可以得到以下的程式碼

import re
text = "A       B    C is Great.                     D"
print(re.sub("  +", "!@#", text).split("!@#"))

# => ['A', 'B', 'C is Great.', 'D']

不過，有時候會產生歪斜的字串，可能會出現以下情況

"  A       B    C is Great.                     D"

或是自己鐵了心不想使用re，不想多引用一個套件。

上述的字串經過””.split(” “)以雙空白分割後，串列內會有許多””的，這部分不需要，這時候可以使用filter()將其過濾掉。

filter()這個類別可以設定條件去過濾串列，符合條件的會被過濾掉，留下沒有被過濾掉的。我們可以把””濾掉，””相等None，於是可以寫成以下。

text = "  A       B    C is Great.                     D"
print(text.split("  "))
# => ['', 'A', '', '', ' B', '', 'C is Great.', '', '', '', '', '', '', '', '', '', ' D']

fliter_text = filter(None, text.split("  "))
print(list(fliter_text))
# => ['A', ' B', 'C is Great.', ' D']

雖然項目數目是正確的，但資料項可能會有空白，這是因為單數長度的空白分隔導致，不過也好處理多了。使用””.strip()，可清除頭尾空白。

text = "  A       B    C is Great.                     D"
fliter_text = filter(None, text.split("  "))
print([row.strip() for row in list(fliter_text)])
# => ['A', 'B', 'C is Great.', 'D']

Jian Ning
2022-09-14

WiFi 802.1x 認證介紹與設定流程

參考《802.1X 概述與 EAP 類型》

關於WiFi 802.1x 認證

WiFi認證有三種模式：Open、PSK(WPA Personal)、802.1x(WPA Enterprise)。
各自連線時需要輸入：無密碼、一組密碼、一組帳號密碼。

進行802.1x驗證時，Client會與Server透過可延伸的驗證通訊協定 (EAP)進行直接溝通傳遞驗證資訊，而EAP中最常使用PEAP：

PEAP

PEAP (防護型可延伸的驗證通訊協定) 提供了一種經由 802.11 Wi-Fi 網路來安全地傳輸驗證資料 (包括舊型的密碼式通訊協定) 的方法。PEAP 達到此一目標的方式，是在 PEAP 用戶端與驗證伺服器之間使用隧道功能。就像競爭的標準型「隧道式傳輸層安全性」(TTLS)，PEAP 只使用伺服器端的憑證來驗證 Wi-Fi 區域網路用戶端，因此可以簡化安全 Wi-Fi 區域網路的實施與管理。PEAP 是由 Microsoft、Cisco 及 RSA Security 共同開發。

簡單來說，PEAP的功能是建立Client與Server之間的隧道，接下來會進行第二階段的驗證。而PEAP的隧道建立需要有Server Certificate，因此除了需要Server上要有憑證之外，如果該憑證是不受Client信任的，就會跳出告警問是否要繼續。

目前在Win11、iOS都會跳出告警，但是Android11以後就會強制拒絕，導致Android用戶無法像以往直接連上線。

PEAP在建立隧道後進行第二階段驗證，最常見的驗證方式為「MSCHAPv2」以及其他的驗證方式。某些Radius Server可能不支援此種驗證方式，需要改用Password authentication protocol(PAP)進行驗證。

甚麼憑證受信任?

在大部分情況下，透過802.1x進行驗證會跳出憑證信任的告警，這是因為許多網路環境並沒有進行憑證相關的管理。因此遇到Android新版本問題或是想要使告警視窗消除，就需要學習憑證相關知識。※Android 13 可以選擇第一次信任。

簡單來說，憑證(Certificate)是包含一對以能進行非對稱加密的公鑰與私鑰，將傳輸的資料以公鑰加密，接下來只能透過私鑰解密才能看到原始資料，不僅避免明碼傳輸，也大幅增加安全性。

公鑰會公開傳遞給其他使用者，私鑰留在自己身上。其他使用者想要傳遞資料給自己時，就利用該公鑰加密後，只有擁有對應私鑰的自己才能解密看到原始資料，其他人就算獲取加密訊息也難以解開。

然而，IP被被偽冒也很容易，導致公鑰也可能出現被偽冒的情形，於是就需要一種機制避免公鑰被偽冒，這個機制就是數位簽章。

自己的公鑰再拿去被認證機構(certificate authority, CA)簽署，這些認證機構可以是企業內部或者是公共認證機構，公共認證機構多半預設情形下會被用戶給信任，因為公共認證機構的公鑰在常見的作業系統都預載在用戶端上，而企業CA還需要匯入憑證與設定。

當認證機構簽署之後，上面就會留有一段認證機構的加密訊息，為認證機構用私鑰加密過後的內容，之後用戶端透過預載的CA憑證(公鑰)去檢查這段訊息的真偽，若為真就能信任該伺服器公鑰。

簽署一張憑證，CA可以有好幾個，形成串鏈，最後才到自己。最根層稱為Root CA，基本上為是公共CA或企業CA。接下來是中繼CA，具有簽署憑證的功能。最重要的就是Root CA，若Root CA被破解，就能大量簽署能被信任的憑證，也就不用費心費力去偽冒。

在802.1x中，用戶端會檢查伺服器憑證的Root CA，用戶端上面要有該Root CA的公鑰，在CA清單中能找到該Root CA，能順利解密出簽章訊息，這張伺服器憑證才會被信任。

WiFi 802.1x 環境準備

在瞭解上述內容之後，要建立一個良好的架構，這裡要準備以下幾點：

支援802.1x無線設備
認證伺服器憑證
用戶端信任認證伺服器憑證

支援802.1x無線設備

無線存取點或是行動裝置等雙邊都要能支援802.1x認證，目前WPA Enterprise的版本有1-3，級別越高越新也越安全，但是舊設備不一定能支持最新的版本。

認證伺服器憑證有且有效

當用戶端透過peap建立隧道溝通時，會需要使用認證伺服器憑證，若認證伺服器沒有憑證，就建立不起來，即便輸入帳密正確也無法使用。此外，憑證也要有效，這部分最多是憑證到期，其次是時間不正確。

用戶端信任認證伺服器憑證

在連線 WiFi 802.1x 時，跳出任何憑證告警都是用戶端不信任伺服器憑證，大部分是因為伺服器憑證的Root CA不在用戶端的CA清單上，還有一部份是用戶端沒有在CA清單上將Root CA勾選信任，即使該Root CA是公共CA。這部分會發生在Windows上直接連線802.1x時的WiFi，只要手動設定勾選就不會再跳出告警。

Android可以安裝WiFi憑證，該憑證專門用於特定一個802.1x WiFi連線，不一定要改動CA清單。安裝的WiFi憑證是認證伺服器的Root CA憑證，並不是認證伺服器的憑證。