ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 【转贴】pfsense 建置 Captive portal

【转贴】pfsense 建置 Captive portal

原创 Linux操作系统 作者:cngd1 时间:2011-05-06 23:40:46 0 删除 编辑
http://www.mml.com.tw/topic/index?id=146444
有不少人問我~ 這種的驗證方法要怎麼做?
呵呵... 其實也不難~ 靠的就是 pfsense 的 Captive Portal

PS: 以下文章建議需要有基本的網路基礎、Linux系統(Unix Like)的經驗、HTML語法基本撰寫等~ 來閱讀會比較省力!


OK 首先了解這部份的架構以後~ 這樣才能構建構出需要的部份~
簡單來說~ 這種驗證的方法就好比 閘道管控 一樣~ 好比台灣警察在各個重要的交通路口設置臨檢一樣的意思~所以 Captive Portal 的建置也就強烈建置在需要管制網段網路的咽喉點~ 這樣才能夠達到管制的效果~

實做的架構(其實這個架構算是簡化我自己家裡的網路所繪製出來的)


所建議的Captive Portal建置架構 與 驗證使用者 的方式


簡單來說~ 由於我家的架構比較小~ 所以會把很多功能集中在 pfsense 上頭來運作~
假設架構需求要更大的話~ 建議將這些功能給予分別獨立開來~ 才不會造成機器過度的負擔~
而這次的pfsense身負著DHCP Server、Captive Portal的功能~ (省的每次除了要key驗證之外,還得自己先輸入IP等網路組態)這篇文章應該也會順帶一提關於NAT架構內的DNS解析~ (如何讓NAT內部用戶端來解析NAT內部的伺服端)

此篇文章會講到的部份

都在 Service 這個大項當中~~~

 

Service → DNS Forwarder 的部份

(若不想用 FQDN 解析 Captive Portal Server 的話,此步驟可跳過)

 

 

 

何為 Forwarding DNS?

http://linux.vbird.org/linux_server/0350dns.php#forwards

 

 

簡單來說 DNS Forwarder 是一個DNS的中間人~ 而簡單的DNS解析功能亦可藉此替內部網路用戶端來解析內部網路伺服端的主機。

 



這個部份就是內部沒有建置伺服器環境(或者存取內部伺服器僅使用區網IP而不做解析)的資料流

 

 

假設內部有建置伺服器,而外部的DNS已經設定好解析的部份 (而NAT Port Forward也設OK) 並能外部能存取內部的伺服器



在於沒有建置 DNS Forwarder 的狀況~ 就會像這張圖一樣~

 

 

外部能夠存取內部的伺服器;但內部卻無法透過FQDN來存取內部的伺服器(僅能用IP來存取)


在NAT內部的用戶端輸入FQDN後一樣會向 Internet 上的 DNS 要求名稱解析,而Internet DNS 伺服器解析到 NAT 的 WAN IP 後。此時內部用戶會直接向NAT提出連線需求。然而內部用戶端提出要求後到NAT。此時仍屬NAT內部的運作,而無法直接轉向到內部伺服端,因而 time out 的情況出現。

這樣的狀況解決方法有不少~
1. DNS Loopback 的功能打開 (視設備的支援能力而定)
2. DNS Forwarder (視設備的支援能力而定) → 剛好這次就是講這個部份的解決方案
3. 修改內部每個用戶端 hosts 檔 (太麻煩!若有100台電腦;豈不是得設定100次?)


以這次的 DNS Forwarder 的解決方案來說~ 他的解析過程會變成下面這兩張圖

1. 連線到外部的伺服端

假設內部用戶端要連線到外部端,首先就得從 DNS Forwarder 那邊進行解析的行為,而 DNS Forwarder 就好像是代理人,幫忙各個用戶端來進行解析的行為。
若在自身的紀錄當中找不到相關的解析部分,則會從外部的DNS來要求解析。


2. 連線到內部的伺服端

假設內部用戶端需要連線到內部端,跟上面一樣也是從DNS Forwarder 那邊進行解析;與上方不同的,就是查詢自身的紀錄~




OK! DNS Forwarder 的理論大致上算是講完了,接下來開始實做 pfsense 的 DNS Forwarder



首先勾選 啟動 DNS Forwarder


由於我已經先建立好一個FQDN 以便內部解析~ 可以看一下設定的UI(介面) 應該是不太難設定才對~


開個cmd來測試一下這條紀錄是否生效! (前提: 自身的DNS組態必須為DNS Forwarder的IP,要麻自己設定 or 由DHCP來配發這組態,DHCP部份容後說明)
執行 ping 指令就可以得知 auth.anpan.idv.tw 這個FQDN所解析出來的IP為 10.0.150.254


首先來增加一筆記錄吧~ 點選+的符號(看圖比較清楚)


設定相關的組態,新增完後請點選 Save



可看到剛剛新增的條目。確認OK後,套用(Apply) 並 存檔(Save)。


確認解析的狀況

以上就是 DNS Forwarder 的介紹




再來就是設定 DHCP Server 的部份









最後就是重頭戲(主角) Captive Portal 的設定了

簡單講一下 Captive Portal 的驗證部份

Captive Portal 簡單來說就是一個網頁的驗證機制~
經過驗證機制後,再給予放行or阻止~ 成果部份~ 我想在這邊我就不囉唆!
(一開始的網頁連結已經有了答案) 那就開始講如何設定的部份吧!



設定的大綱~

首先設定主要的設定項目~

PS: 一般來說~ Captive Portal 只是一個管制的手段,所以用在有線的介面或者無線的介面都可。只不過一般來說都會用在無線方面居多。


這裡我補充的就是 若只是要迫使用戶端網頁導向到該所指定的網頁,而不驗證用戶端,則可選不認證。
(此章節僅說明 Local users 部分,RADIUS部分請閱讀官方網站文件區)


僅RADIUS啟用後 此部分才能設定


OK! 這邊有個HTTPS的部份,請注意! 雖然無線網路有他的加密機制(WEP、WPA、WPA2..等) 不過加密的效果有限~~~
若以WEP為例,以目前電腦硬體的破解應該只需要30秒就能破解完成~ 可以藉由破解加密過而竊聽無線網路的封包~
其他種方法:如Hide SSID(隱藏SSID)以及MAC Filter(MAC過濾)機制~ 一樣可以破解~ Hide SSID 可以藉由Sniffer 蒐集封包後得知SSID。而MAC Filter 一樣的手法;只不過得多一道偽造MAC的部份來偽裝合法MAC位置來通過MAC Filter。而這些機制都是屬於 OSI L2 的部份,當然越高階層的機制對於硬體與系統的要求也越高。 而HTTPS算是高層的加密機制~~~至少在於驗證的部份,可以保有隱密性~~~ 而且破解所需要的程度與時間也要來的高~~~ 而且可以搭配原有的 WEP WPA 等的加密機制(加密再加密!)

OK~~~ 如何實做 HTTPS 的驗證呢?
不要偷懶在pfsense上頭產生key(除非僅使用IP才可使用pfsense上頭產生;若使用FQDN則會造成整個服務的終止)!
產生兩個Key得在其他裝有openssl套件的Unix Like OS上頭產生~
先連線到其他台裝有openssl套件的Unix Like OS 的OS吧~~



(RH派確認是否openssl套件,可使用 rpm -qa | grep openssl)
產生CA
openssl req -new -nodes > cert.csr






拿CA來產生公鑰與私鑰
openssl x509 -in cert.csr -out cert.pem -req -signkey privkey.pem -days 9999


cat cert.pem
並將此檔的內容全部貼到 HTTPS Certificate 欄位當中


cat privkey.pem
將此檔的內容全部貼到 HTTPS Private Key 欄位當中





上傳驗證網頁以及驗證失敗的網頁~~~

撰寫驗證入口網頁(偷懶的話,pfsense的那個註解就有相關的程式碼)


撰寫驗證失敗網頁

http://www.flickr.com/photos/44220930@N02/5572328931/sizes/l/in/photostream/



設定完成後,可別忘了按下 Save 儲存設定(同時也會將剛剛設定的key內容與網頁檔一併儲存到 pfsense 當中)



再來就是設定 MAC By-Pass 的部份


設定 IP By-Pass 的部份

From 應該就很容易理解~ 首先從DHCP保留區配發給Captive Portal區域內的機器~
於是會配發IP給 Captive Portal 內的機器~ 而這個部份的 To / From
To 就是從非驗證端連入驗證端 (允許) : 一般這種方法就是在需驗證端設置伺服器來讓非需驗證端連入,而不受到 Captive Portal 的干擾。
From 就是從驗證端連入非驗證端 (允許) : 一般這種方法就好比 IP By-Pass 的方式 讓需驗證端by-pass到非驗證端,而不受Captive Portal的干擾。

設定 Captive Portal 帳號與密碼 於 pfsense Local端




檔案管理



除錯: 曾因為CA Key錯誤而導致整個 Captive Portal 服務終止。原因則是HTTPS Server Name與CA當中的 Common Name 不相符而導致。測試的方式很簡單,只需把HTTPS功能拿掉就可以測試是否問題出在這裡了。

Captive Portal 伺服端的設定就到這裡告一段落了~~~ 切記:每次設定完後 記得 Apply Changes 以及 Save 即可

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10990946/viewspace-694665/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2008-08-15

  • 博文量
    17
  • 访问量
    47822