Was this page helpful?

Padavan custom firmware

    內容表格
    沒有標頭
    Padavan f/w是針對ASUS部分機種的第三方優化方案, 基於Linux-based kernel(大多都是BusyBox solution), 比起原廠f/w提供與眾不同的GUI和模組. Padavan f/w對於部份機種的支持係因為僅針對於MIPS-based CPU solution調校, 它並不能支持ARM-based CPU架構.
    從官方網站進去後, 可以直接看到Padavan主要係針對N56U的RT3662 solution進行優化與調校, 從左邊f/w選單下載所需的Padavan f/w:
    尾部單字: dlna, aria, base等代表同樣的f/w, 但是自帶的模組各有不同, 可以從changelog查看Padavan f/w自帶了哪些模組以及移除掉原本存在的模組:
    根據官方網站描述, Padavan f/w提供如下列表的多種特徵, 其中包含了硬件加速(Hardware Acceleration)的支持, 真正呼叫RT3xxx ASIC driver去執行相關的硬線加速電路:
    當刷新成Padavan f/w並且登入它的GUI介面後, 便可以看到與原廠非常不同且簡約清新的操作畫面:
    GUI的操作簡單易懂, 且相當直覺.雖然Padavan f/w移除掉QoS模組, 但也增強了許多特性, 包括了Monitoring的強化以及硬件加速的特徵.

    Hardware Components
    根據N56U的硬件設計, 主要包括了: RT3662F SoC, DDR2 RAM buffer, 802.11n 2.4GHz RF PHY和1Gb/s ASIC Switch logic.
    從上圖的PCB照片可以看到幾個主要的IC元件組成, RT3662F這個SoC為主要的中央單元, 包括了一顆MIPS-based CPU操作, SoC負責與其他元件通訊與協調, 從如下的方塊圖可以看出SoC包括了各種不同的任務區塊:
    由於無線單頻的情況下, 另外透過一條PCIe lane接入一顆2.4GHz的802.11n Wireless PHY(RF/BBP/MAC): RT3092. 實體連接(PHY port linking)接入了一顆Realtek的Switch chip: RTL8367M, SoC與Switch之間的host-bus頻寬為1Gb/s. RT3662本身SoC高效的主要特徵包含了Frame Engine元件, Frame Engine讓SoC兼任了NPU的各種操作, NPU使得traffic進入SoC時, 引入fast-path直接由特定的ASIC進行處理, 而不用透過cpu port的slow-path送到CPU去handle, 大幅提升吞吐量操作(900~950Mbps).
    為了讓traffic透過fast-path傳入, 這個前提是packet的格式必須是ASIC能夠識別的, 當然! wireless traffic全部不能被ASIC加速電路操作, 因此它會提升CPU loading. 從Frame Engine可以看到一個關鍵的部分: PPE(Packet Processing Engine). 這個模組即為大幅提升吞吐量的ASIC重要元件, PPE等於擔當了NPU的責任, 因此它可以負載標準的ethernet packet. PPE包括以下的相關特徵:
    ASIC的PPE雖然提供了這些特徵, 但必須視f/w載入的driver而定, driver載入將會初始化上述的特徵並且執行運作. 從PPE可以看出除了對標準IPv4 packet的加速, 也包括了PPPoE加速的支持(without MPPE), 在一般家用環境上, PPE能夠大幅提升WAN端效能, 因為居多使用者接入PPPoE協定來連結網際網路(Internet). PPE能承載的頻寬大約1Gb/s的吞吐量. PPE提供對H/W QoS的加載, 在Padavan f/w因為某些原因已將QoS module移除, 而且原廠的module似乎是software-based, PPE的QoS實際上沒有任何作用.
    Wireless本身SoC已經具備, 不過在單頻的情況下(5GHz), 為了能夠支持2.4GHz頻帶另外接入了2.4GHz Wireless PHY(RT3092), 但是從Wireless進入的traffic全部無法被PPE加載, 請注意! Wireless與Wired網路不是同個層級下的硬件架構. 無線流量會被CPU全部handle, 要注意高負載的情況, 比方說多個wireless clients, 大量的multi-threading網路環境(N65U的情況可能不同, 它的硬件架構有些不一樣).
    N56U包括了一顆128MB的DDR2-800 RAM, 不算多也不算少, 請謹慎注意RAM的負載量, 尤其是USB Application, 因為caching的情況下會大幅占用RAM buffer, 並且提升CPU loading.
    CPU是所有SoC的心臟, 也是最重要的處理單元, CPU必須負載各種業務, OS本身的操作, packet的處理, 兼任內部debug等..RT3662內置了一個MIPS-based CPU: 74Kc, clock為500MHz, 這是一顆用的相當廣泛的泛用化single-thread CPU, 不具備FPU.
    CPU本身不算太好, 但也不至於太差, 足以負載300M的無線網路流量, 但是要注意的是! 請盡可能避免使用VPN, 因為它是完全的software-based, 加解密操作都要交給CPU執行, 由於RT3662是74Kc, 不是高性能版本(74Kf), 要小心負載量, 因為他能夠操作的VPN吞吐量很低, 在MPPE工作後, 會大幅提高CPU loading.
     
    Padavan System
    在進入Padavan系統後, 可以看到非常值觀的GUI介面. 其中左半部為context menu.
    這邊將會重點說明: VPN, Monitor, Wireless, LAN/WAN, Firewall. 其它部分僅會快速帶過. 系統本身僅提高兩種語言: 
    本地化語言(Russia)以及國際語言支持(English)
    Network Map可以說是一個dashboard, 提供了基本的整體資訊, 讓使用者快速了解當前的網路環境.
    使用者可以設定GUI管理的存取控制, 允許WAN端(Inbound)存取哪些管理服務(Administrative traffic), 與原廠f/w不同的地方是port range.
    比較不能理解的是, 與原廠f/w一樣都是一次只能一個User存取GUI, 其它User無法同一時間登入, 它沒有允許限制一次可以登入的連線數量. 有時帶來了不便, 比方說在進行網路調整的時候, 2台電腦以上進入GUI檢查卻只能一台使用, 這樣的限制不會提升安全性, 只會徒增困擾.
    AP模式的切換在Padavan提供兩種模式使用: Wireless Router Mode (Default) 和 Access Point Mode (AP)
    預設的情況下是一個Router Mode, 這代表了除了L2功能之外,還包括了L3/L4或著以上的功能, 例如IP routing, NAT, DHCP等. 而AP mode就是單純的L2 Bridge, 它僅具備有關L2的轉發功能. 在這個模式下, SPI Firewall, Routing和NAT等都會全部被關閉掉.
    一個如下圖的案例, 當PC client發出DHCP請求時, 中間的Router處於Router/NAT或著AP/Bridge mode下不同情況的操作.
    當Router/NAT mode的情況下, PC cient發出DHCP請求(UDP, 67-68, 廣播), 中間的Router會直接接收這個請求並且最後配發IP給該client, 那對於DHCP Server來說將永遠不會收到這筆DHCP請求, 因為它已經被處於Router mode的Router給處理掉; 反之, 當Router被設定為AP/Bridge/Transparent mode情況下, 將會把client端的DHCP請求記錄直接轉發到DHCP Server, 而DHCP Server就會收到該請求並且進行後續動作, 完整一個DHCP的操作.
     
    AiDisk & USB Application
    AiDisk是一個精靈模式, 它與USB Application是完全關聯的, 用於配置連接在N56U上的USB儲存裝置. 除非有必要, 否則建議盡可能不要使用它, 因為他會大幅消耗記憶體, 並且額外消耗CPU time.
    如果需要使用的話, 必須選擇如下的選項以利記憶體回收, 否則被cached的記憶體將會很慢釋放:
    下圖為當使用USB Drive做為N56U上的附加儲存裝置(Add-in Storage)進行FTP的存取操作時, CPU使用率以及系統記憶體負載情況:
    從上圖可以看出, 除了系統記憶體上cached memory消耗很大之外, CPU也占用一定程度的使用率(CPU Usage). 這是使用SanDisk的低階隨身碟16GB的情況下, 流量大約4~9MB左右, 下圖記錄了一小段時間的吞吐量情況:
    針對USB Application的管理, Padavan提供了基礎的RBAC, 可以簡單新增/修改/刪除使用者帳戶, 並且調整當下的目錄存取權限:
    Padavan允許USB儲存裝置掛入以下的存取服務, 包括常見的FTP服務:
    Padavan也允許透過特定的USB裝置提供其相關服務: USB Printer提供印表機服務和接入3G/4G(LTE) USB裝置使用Wireless WAN功能:
    以下為Padavan針對儲存裝置(USB Storage)提供的相關組態設定, 有些設定是針對機械式的儲存裝置:
    Note(s):
    1. Padavan支持NTFS格式的檔案系統(File System).
    2. 如下為使用500GB USB Drive連接至N56U進行FTP操作的最大I/O極限:
    從上圖來看, 受限於CPU的影響. I/O介面15~22MB之間, 無法再拉升, 因為Administrative Traffic是無法扔入PPE加速.
    [UPDATED, 201402131744] How to use Transmission?
    在Padavan提供了一個現成的套件工具:Transmission, 這個工具可以用來支持BitTorrent協定的P2P傳輸, 包含了對magnet的支持. 利用該工具可以使Padavan直接操作BitTorrent協定進行P2P資料交換傳送至安裝在USB上的儲存媒體(建議機械式硬碟). 使用前必須要先在儲存媒體上建立transmission的空目錄:
    當指定的目錄生成後, 開啟Torrent Transmission服務, 它包含了Incoming Port(inbound)以及內置的WebUI登入介面所使用的RPC Port:
    之後再從SPI Firewall允許這項服務(Transmission)存取:
    到System Log的Port Forwardinh進行觀察, 發現會多出幾筆紀錄:
    使用者不須手動設定Port forwarding去做DNAT轉發, 只需在SPI Firewall開啟相關服務將會自動新增相關的轉發紀錄. 使用PRC Port指定Public IP登入WebUI, 是一個精簡的互動式操作環境:
    從上圖可以看到已經成功開始操作BitTorrent協定的資料通訊了. 接下來使用System Info的CPU monitor觀察負載情況:
    從WebUI進行相關組態的設定, 檢查CPU的負載以及網路吞吐量:
    可以發現對CPU的衝擊其實不小, 當torrent(s)數量愈多, 排程的下載任務愈多, 相對造成CPU loading也會隨之增長, 使用時須注意負載情況.
    Transmission版本的韌體可以提供高階的GUI操作介面, 而且UI的操作更為友善, 設定項目也較為豐富:
     
    Software-based VPN
    VPN Server與VPN Client可以配置VPN的連接環境, 他能支持如下的VPN協定:
    配置上並不困難, 居多使用這可能會配置PPTP或著L2TP, OpenVPN較麻煩一點. 由於VPN是完全的software-based, 加密的操作會對CPU造成重大打擊:
    VPN對CPU的殺傷力極強, N56U並沒有獨立的ASIC來負責VPN的加解密操作, 雖然Padavan使用上不困難, 在沒有必要的情況下, 並不建議使用, 額外使用x86 CPU的獨立NAS獲取的效益更佳(ex: SYNOLOGY, QNAP, etc...).
    MPPE encryption is software processed by router CPU and is very hard, max 24-25Mbit/s. PPTP w/o MPPE ~170Mbit/s
    當然! 可以選擇完全不加密, 吞吐量會提高許多, 不過幾乎沒有使用者會這樣做, 除非不在乎安全性問題.
    [UPDATED, 201402181941] How to setup the PPTP Server?
    使用VPN可以使得Remote Network與Local Network看起來就像是在同一個LAN下, 彼此透過一條專屬的tunnel相互通訊. 在Padavan支持了幾種VPN通訊模式, PPTP是最簡單的通訊模式, 設置PPTP是相當易用的. 在設置PPTP讓遠端網路通訊, 可以看到如下圖的相關設定:
    其中可以設定驗證模式以及加密強度, 預設是使用MPPE-128加密, 這個加密方法對大幅提升CPU loading並且改進安全性. 往下則可以設定基本的帳戶資訊, 設定帳號以及該帳號之密碼:
    除此之外可以設定VPN client指派的IP位址, 按照預設會與LAN綁在同一個網段下, 如需要隔離則可以更改Allocate Subnet for VPN Tunnel的配發網段, 這將會把VPN client綁在其他網段下
    完成這些設定後, client便可以透過相關的應用程式與設置PPTP VPN的Padavan連線, 從System Log可以查看連線中的過程:
    使用MPPE-128加密通訊用的tunnel. 通訊完成後, Routing table會出現改變, 它會增加一個固定的VPN client的routing:
    而client部分, Routing table也同樣出現一些變化: routing的增加以前不同的計量(Mertic)變化:
    從VPN的連線資訊可以看到一個被建立的session存在, 包括了指派的IP資訊:
    VPN的通訊使得Routing table增加了新的default route(0.0.0.0/0)並且為最高優先(Metric最低), 因此所有的通訊會轉發到這條default route, 這代表一個虛擬的PPTP tunnel已經被建立. Ralink RT3662並沒有實作相關的VPN硬線加解密(enc/dec)電路, 請注意CPU loadingk的負載:
    當啟用MPPE-128去加密tunnel後, 會造成網路效能上的打擊, 吞吐量會出現明顯的下降, 並且CPU loading會大幅提升. PPTP雖然簡單易用, 不過先前需評估當前的網路情況而定, 如果使用者的網路相當快速(>100M), 將不得不注意當前的系統資源負載情況. Padavan所有的VPN都是software-based, 加解密模式的啟用會對網路效能造成打成, 只有選擇不進行加解密的操作獲得大幅改善, 不過安全性會受到影響.
     
    Resource Monitoring
    Padavan比起原廠f/w多出兩個重要的Monitor: CPU和Memory. 這兩個Monitor對於使用者來說是非常有幫助的, 隨時可以監控當前的機器負載狀況為何?! 下圖為頂部直觀的資源占用原件表示CPU和記憶體的使用率情況:
    CPU Usage的資源監視器:
    Memory Usage的資源監視器:
    一個與原廠f/w相同的部分, Traffic Monitor依然是存在的, 方便使用者查看當前的網路流量負載情況, 並且提供幾種時段的查詢:
    Wiresless 2.4/5GHz
    Padavan提供兩個頻段的無線網路調整: 2.4GHz和5GHz. 並且提供Guest, Bridge, Filter, RADIUS驗證以及進階的專業設定:
    使用Guest AP可以建立特屬的Guest連線, 用於阻斷與LAN的連線並且允許孤立Guest之間的通訊(即不允許). 雖然不具備Captive Portal機能, 但也是個簡單的Guest訪問機制的實現.
    Isolaion between Guest AP and LAN: 用來決定是否阻斷與LAN的通訊.
    Set AP Clients Isolated: 孤立Guest之間的通訊 (即Guest之間不能直接相互連線).
    透過Bridge機能可以實現AP與AP之間的串接以延長通訊距離, Pradavan允許如下幾種方式實現:
    可以使用WDS或著建立Server-Client的主從架構, 不過這些並非是一種標準的Mesh架構, 也沒有提供相關的AP Load-balancing, 但不失為一種延長通訊距離的簡單方案, 並且成本較低.
    Padavan允許使用進階的RADIUS驗證提供遠端驗證存取, 前提是必須有RADIUS Server的存在, 如果使用Windows Server, 需放行這台AP的連線, 即新增一個RADIUS Client並且允許連線.
    設定完RADIUS連線, 也需將驗證方式調整為RADIUS的驗證存取:
    雖然Padavan撤掉了QoS模組, 但對於Wireless所支持的QoS依然按照標準支持, 相容了對WMM規範(802.11e)的支持.
    在Padavan無法做任何調整, 比方說你無法重寫優先權順序(Priority), 這邊優先權並不是一般所講的佇列(Queue)優先權, 而是同一個排列下不同的優先順序, 可以使用上層支持QoS的設備重寫順序(如果存在的話). 如下圖使用FortoGate改寫DSCP(相容COS)重寫優先順序:
    下圖為以太網路(Ethernet)規範定義的802.1P與無線網路的WMM QoS優先權的COS對應:
    也可以參考UBNT對於WMM QoS標準記載的相關文件: UniFi - How is QoS and prioritization handled?
    一般預設的情況下為BE(Best Effort), 大家都是公平同等, 公平競爭, 即不會重排列的FIFO(有些traffic會例外, 例如Administrative Traffic).
    由於DSCP, COS, TOS等的QoS設置對於一般使用者甚至MIS都過於艱澀難懂, 因此居多情況下幾乎都不會去用它. 在Padavan的設定中, 沒有使用到可以完全忽略這個WMM QoS項目. DSCP, COS, TOS等..., 容易被硬件實作(Hardware-based), 因此大多的L2 switch或著具備NPU機能的switch logic都存在這類的H/W QoS機制. 在RT3662F SoC的Fame Engine也是沒有例外:
    不管是SoC內置的5GHz頻段以及外接2.4GHz的PHY(RF/BBP/MAC), 經過ADC/DAC=>MAC之後, 還原成封包(packet)進行後續的處理並沒有特定AP/NP logic操作, CPU(MIPS 74Kc)必須承載這個業務, 以致CPU資源會有一定程度的消費:
    5GHz和2.4GHz WiFi traffic會同時消費CPU資源, 這有可能會大幅提高loading, 因此需要注意這個情況, PPE不能夠加載這些traffic以減輕CPU負擔. 下圖為2.4GHz WiFi client存取FTP服務時, 消耗的CPU loading以及吞吐量輸出情況:
    在WAN的設定中有一個Hardware offload NAT/Routing IPv4的設定項目, 其中有兩個看起來像是WLAN的PPE加速:
    但Wireless client與AP(Padavan)取得通訊上網後, 卻不是那麼一回事! CPU(MIPS 74Kc)依然要被消費資源去操作無線流量. 事實上, 該選項選擇WLAN一起被offload到NPU看起來更像是當traffic請求WAN端時(inbound), 進行NAT(DNAT)轉發並且交由PPE操作:
    在N56U的無線方案是以SoC內置加上外連的Wireless PHY(RF\BBP\MAC)一起雙頻(Dual-band)輸出, 由於外連的2.4GHz PHY(RT3092)操作traffic, 將無線信號進行轉換經過基頻單元(BBP)的ADC/DAC轉換輸出到MAC還原為封包資料, 但是有關TCP/IP stack相關的操作無法在這個2.4GHz PHY處理, 它必須送到SoC的CPU(MIPS 74Kc)進行後續業務操作(AP/NP), 在同時輸出5GHz和2.4GHz的情況下, CPU業務將有可能變得很繁重, 所幸Frame Engine中的PPE大幅承載了以太網路(Ethernet)標準IPv4流量以減輕負擔, 否則無疑是雪上加霜. 在另一款的N65U將2.4GHz PHY變更了設計:
    從原本的RT3092(RF/BBP/MAC)更換為RT3352, 而SoC採用RF3883F(MIPS 74Kc, 500MHz), 這樣的變更使得情況變的不同! RT3352與RT3883F本質上是同類型的, 都屬於SoC. RT3352主要用於2.4GHz的Wireless承載, 比起N56U的RT3662+2.4GHz PHY(RF/BBP/MAC), 2.4GHz的業務完全是由RT3352來負責, 由於內置了一顆CPU(MIPS 24Kc, 400MHz), 因此將由本身的CPU來負責2.4GHz無線頻段的開銷, 對於主要CPU(Main CPU; RT3883F)來說, RT3352就像是一顆協處理器(Co-processor), 極大的程度減輕了主要CPU去負載該業務的開銷. RT3883F+RT3352就像是雙CPU架構, 只是RT3352負載2.4GHz無線頻段的業務, 而RT3883F僅負責5GHZ無線頻段.
     
    LAN&WAN Configuration
    Padavan的LAN以及WAN的設定與原廠f/w稍微有一些變化, 不過基本上都是一致. Padavan的WAN的設定允許選擇不同類型的連線, 除了PPPoE之外也包括了VPN連線:
    除了IPoE(標準IPv4封包交換)以及PPPoE之外, 其餘連線類型皆無法透過內置的PPE進行加速, 必須注意! VPN連線是會嚴重打擊網路性能. PPPoE能夠被PPE負載是該SoC的一個高效特徵, 雖然同時支持的sessions數量有限, 但大多情況下幾乎可以受益於PPE的良好表現.
    PPTP and L2TP cannot HW_NAT offloaded for RT3662. Only IPv4/IPv6 and PPPoE (up to 900Mbit/s) => IPv6加速目前沒包含

    不論來自LAN或著WAN的traffic, 在預設的情況下, 都可以排入NPU操作以提高網路性能. 在一個LAN之間的相互傳送資料下, 這是一個簡單的L2轉發(forwarding), 它不會經過SoC, 僅會在switch logic之間相互轉發frame(高效能), 只有當routing到非同一個網段下才有可能經由switch logic轉發到SoC進行操作, 在Padavan操作下即為LAN=>WAN的轉發. 由於外部網路(Internet)並不會知曉LAN網段的IP range(Private IPs), 基於安全性以及資料保證會建立一個table記錄public IP以及Private IP之間的對應, 即為NAT轉換, 下圖為來自Fortinet教育文件的一張NAT轉發概念圖:
    上圖看到內部的192.168.1.0/24會透過外部網路看的到的Public IP: 172.20.120.14透過NAT轉發出去, 為了讓遠端網路能夠識別來源為何?! 表頭(Header)的Source會從192.168.1.x/24替換為172.20.120.14(Src Port亂數對應LAN的IP的Src Port)後送出去, 這種基於來源端的轉換, 可稱為SNAT(Source-NAT); 將表頭的來源掉包為Public IP, 因為上層Gateway有這筆Public IP的routing. 在上圖的範例, 包括了使用built-int Sniffer進行相關的packet追蹤, 結果如下每筆記錄列出:
    一般大量的NAT轉換意謂對應的table size也會水漲船高, 這表示所需記憶體空間更大, 轉發效率更為重要. N56U所使用的RT3662F SoC, 它所對應的家用環境, 一般情況下並不會遭遇到大規模的NAT轉發, 例如同時存在7~8萬個sessions; 因此足以應付大多的應用: P2P, 線上影音等.. 在SoC提供的Frame Engine, 期內置的PPE加速器能夠支持TCP和UDP封包格式(依存限制), 並且提供基於ASIC的H/W NAT轉發, 從Padavan的WAN設定下可以看到相關項目:
    從Hardware offload NAT/Routing IPv4最後一個Disable即表示關閉H/W NAT, 此時會將所有的NAT轉發不會經由fast-path, 而是引入較慢的slow-path傳送到CPU進行操作, 其效率會比基於ASIC的H/W NAT轉發相差3~4倍以上. 當啟用或關閉H/W NAT之後, 可從System Log查看相關執行紀錄:
    根據以下兩張圖, 比較了H/W NAT開啟與關閉的不同情況下所表現的吞吐量, 當關閉H/W NAT的情況下(LAN=>WAN):
    可以看到Downlink常常出現一堆高峰值, 但整體而言並不平坦, 相對的; 他依賴非常多的CPU資源, 從CPU Load可以看到這是滿載的情況下, 過重的負載會影響整個網路性能, 使其受到打擊. 而在啟用H/W NAT後則出現不一樣的變化(LAN=>WAN):
    Downlink可以是非常的平坦, 不會隨便一堆CPU的I/O中斷而受影響, 這是H/W NAT啟用後由Frame Engine的PPE負責封包的轉發及操作, 他維持了整體網路環境的高效益, 並且巨觀地提升網路I/O吞吐量, 一般如果不是debug或著測試用途請勿關閉H/W NAT. 下圖是用FGT200B對N56U監控的Traffic Monitor, 左右為CPU和H/W Acceleration負載時的不同流量情況(LAN=>WAN):
    由於沒有開啟Jumbo frame, 用FTP傳輸大型檔案, PPE加速的情況下頻寬卡在一定程度就無法再上去; 使用FGT200B監控CPU負載traffic的吞吐量還不算太差, 不過這時CPU已經完全滿載(100%), GUI操作會有明顯的延遲情況.
    [UPDATED, 201402140031] PPE vs. QoS vs. Non-QoS
    這邊刷入原廠f/w啟用QoS比較Non-QoS與PPE加速不同的差異, 在QoS的設定如下圖所示, 一個預設的流量塑形和新增的優先權:
    使用FTP傳輸大型檔案, 取得不同的吞吐量情況, 如下圖所示:
    可以看到PPE加速永遠保持最好的情況, 並且CPU loading是最低的, GUI操作是平滑順暢的. 重點在於啟動QoS以及一般CPU負載的差異, 當啟動QoS後, 吞吐量比起未啟動QoS有所下降, 但是基本上都保持在200Mbps以上, 足以應付100~150Mbps的網際網路(Internet), 雖然兩者在這樣的吞吐量情況下(>200Mbps), CPU loading已達100%, 並且GUI操作出現明顯的延遲感.
    Note(s):
    設定預設的流量塑形, 調整在100(推薦)~150Mbps避免CPU負擔過重的吞吐量能有效改善網路效能以及GUI操作平滑順暢.
    (非常愚蠢的轉圈圈技術...!!)
     
    當一個SNAT的請出轉送出去之後, 即反方向(Reversed)轉發回來源端, 根據NAT建立的table找查出對應的Client並且送回, 這是一個情況. 那麼, 由外部網路對N56U下某一個client進行某種請求, 比方說是FTP(20, 21)請求, 這會是另一種情況, 外部網路必須要能正確請求內部網路下的某一個client, 在Padavan的設定下透過Port Forwarding去指派對應.
    外部網路的來源請求N56U下的某一個client, 並且對應FTP資料服務(21), 由於外部網路只會知道WAN的Public IP, 因此讓WAN IP與被請求的client進行對應即可, 請求是FTP服務, 雙方的port沒有任何改變, 讓WAN IP對應LAN client並且使用FTP port. 在System Log的Port Forwarding會出現該筆的對應紀錄:
    如下為來自Fortinet教育文件的案例圖, 使用Port Forwarding:
    外部網路由於只會知道172.20.120.14這筆Public IP, 並不知曉內部網路的192.168.1.110這筆紀錄, 但是外部網路依然可以正確存取到該client的資源. Port Forwarding實現了這個結果, 172.20.120.14<==>192.168.1.110進行對應並且使用80 port存取Web資源. 當外部網路直接存取172.20.120.14, 使用80 port請求時, 透過Port Forwarding直接轉發到192.168.1.110, packet的header中的DST(目的端)會被替換, 這樣的操作即為對目的端的NAT轉發, 可稱為DNAT(Destination NAT), 由於他是一個Public IP以一個固定port(fixed port)去對應LAN的其中一個client IP, 為固定且靜態的一對一, 因此又可稱為Static NAT. 在上圖的範例, 包括了使用built-int Sniffer進行相關的packet追蹤, 結果如下每筆記錄列出:

    當你需要將某一台client暴露在外部網路下, 即為全部的port與Public IP完全對應, 請使用DMZ(Demilitarized Zone).
    只能指定一台client作為DMZ, 這是很合理的, 因為只有一個WAN IP去完全對應一個client. 但是一個例外的情況會存在, Administrative Traffic以及Port Forwarding(DNAT)的轉發, 其優先權會完全高過DMZ的轉發. 優先順序如下:
    Administrative Traffic => Manual DNAT Traffic => DMZ Traffic
    因此從System Log進行觀察, 發現Port Forwarding table順序也是如出一轍:
    從上圖可以看出有兩筆轉發紀錄的port是一模一樣的, 192.168.1.1:21和10.2.150.190:21, 這說明了在DNAT轉發的過程中必定會發生衝突. 由上往下按照優先順序, 屬為Administrative的192.168.1.1必定是最高優先權, 因此在DNAT轉發的過程中將永遠不會抵達10.2.150.190:21. 
     
    這種情況的發生在啟用USB Application的時候可能會碰到, 開啟的服務(Service), 比方說FTP(21), Padavan在操作的過程中直接DNAT轉發對應到192.168.1.1:21的Administrative的IP去直接存取USB Drive, 而使用者又在Manual Port Forwarding設定的相同的Port轉發指向不同的client IP, 這時就會形成所謂的Port衝突(Port Conflict). 其結果就是Manual Port Forwarding的client將永遠不會被抵達, 要解決這種衝突情況只有轉發不同的port或著停用相關的Router Service才可以避免發生; 按照上圖的範例, 為了存取10.2.150.190:21, 將192.168.1.1:21為FTP的Router Service關掉即可:
    Padavan支持DDNS主要針對來自PPPoE或著ISP使用DHCP配發的IP提供Domain Name的轉發. 提供對如下主流的DDNS服務:
     
    在Padavan對於LAN提供的MTU大小支持允許擴展到16K, 這種超出IPv4標準乙太網路封包大小1500bytes稱為Jumbo Frame:
    雖然可以將MTU大小拉到16K, 不過要注意的是client同樣開啟Jumbo Frame後, 他有機會提高LAN網段下的I/O吞吐量(雙方都要開啟).
    但是卻可能會導致LAN=>WAN之間的通訊異常, 這並非為f/w帶來的問題(issue), 而是硬件限制所引發的. 確實, RTL8367M號稱支持16KB的MTU大小, 可是RT3662F的SoC可不是這樣:
    從上圖來看, 這完全是硬件問題所導致的, SoC根本不支持超過4KB的MTU大小的packet. 強制client啟用超過4KB的Jumbo Frame只會導致LAN=>WAN的通訊可能會有異常的情況. 對於Jumbo Frame大小的建議, 請於client使用預設的IPv4標準乙太網路封包大小即可(1500bytes).
    Note(s): Administrative Traffic的packet不支持Jumbo Frame, 因此需要使用USB Application的服務, 請勿於client端開啟Jumbo Frame.

    不管是WAN或著LAN當設定的對於Router(N56U)的本地IP後, 會自動產生一筆固定的靜態路由(直接連結), 他的優先權是最高的. 並且當WAN IP設定完成後, 會立即產生一筆0.0.0.0/0的Default Route, 這個預設的路由會指向Gateway. 從System Log的Routing Table進行觀察:
    10.2.129.0/24以及192.168.1.0/24分別為WAN以及LAN的本地網段; 127.0.0.0這是預設會產生的loopback, 永遠生效. 如果請求的目的端(DST)並不屬於上述的網段, 將會自動透過default(0.0.0.0/0)轉發到10.2.192.100的Gateway(UG)往上請求, 因此可以看出Iface的介面是對向WAN的eth3介面, br0則是Port1~4的LAN.
    當對於一個目的端的請求並非來自Gateway之後, 而是從LAN往下尋找, 例如LAN網下接一台Router, 往下請求的網段為192.168.2.0/24. 由於Padavan下沒有這筆路由, 因此必須要自行加入讓Padavan得知有這筆資訊, 否則他將會往上層Gateway(UG, 10.2.129.100)轉發, 結果就是永遠無法抵達(Unreachable). 從Route設定下加入需要的靜態路由, 如下圖所示:
    在增加192.168.2.0/24的靜態路由指向192.168.1.101的Gateway(UG), 使用System Log的Routing Table進行觀察:
    可以發現有了這筆的路由紀錄, 因此下次對於192.168.2.0/24請求將會轉發至下層的Gateway(UG, 192.168.1.101)進行訪問. 使用靜態路由保證了特定路由的轉發, 避免不可抵達(Unreachable)的情況發生.

    Padavan提供STP(Spanning Tree Protocol)的基本功能, 用來預防異常的L2 loop情況發生(同一層).
    按照預設, 這個功能是啟動的.

    IPv6 Connection
    在IPv4中, IP定址長度是由四組8位元組成一組32位元長的一串二進位數字. 為了理解以便於計算, 將其轉換為十進位格式, 如下的範例所示:
    由於IPv4的定址空間不足應付現今的需求, IPv6解決了這個問題. 它提升了定址長度; 相對的, 計算上也變得較為複雜, 如下圖的範例:
    IPv6是由8組16位元長組成128位元的一長串二進位數字. 為了理解以便於計算, 將其轉換為十六進位格式(8001.0DB8.AC10.FE01::). IPv6還附帶了首碼(prefix)用於區隔網路前綴(network prefix)和介面ID(interface identifier). 一台client取得的IPv6位址是獨一無二, 一個Unicast形式:
    network prefix為routing prefix和subnet id組成, 而interface id則可以用來表示client真正的唯一位址, 用以作為識別. subnet id可以被用來對本地網路切割數個子網段.
    一個案例取得了一個LAN網段所使用的IPv6網路前綴: 1234:5678:9012:0200::/56, /56為routing prefix, network prefix=64. 規畫8個子網段.
    1. 得知subnet id為64 - 56 = 8, 可用來切割數個子網路.
    2. 計算關鍵部分: 存在subnet id那一段16位元長的十六進位字串(:200:).
    3. 將存在subnet id的十六進位字串轉成二進位字串. :200: => 0000 0010 0000 0000
    4. 取得subnet id的那一部分用於計算子網路( [ 和 ] 符號選取): 0000 0010 [0000 0000]
    5. 規畫所需的子網路, e.g., [0000 0001]~[0000 0008]規畫8個子網路=>0000 0010 [0000 0001]~0000 0010 [0000 0008] => 201~208
    6. 轉換為十六進位, 再全部組成為真正的IPv6網段: 1234:5678:9012:201::~1234:5678:9012:208::
    7. 配合subnet id相關的計算後, 附帶network prefix(/64): 1234:5678:9012:201::/64~1234:5678:9012:208::/64
    最終, 這便是規劃出來所需的8個IPv6子網段(1234:5678:9012:201::/64~1234:5678:9012:208::/64).

    Padavan提供了基本的IPv6網路功能, 使用者可以藉以設定完成IPv6通訊, 支持的IPv6通訊模式如下:
    其中DHCPv6包括了不同的IP取得方式: SLAAC和Stateful的DHCPv6指派
    SLAAC與Stateful DHCPv6差別會在於header其中的兩個flag設定不同(M, O flags).
    DHCPv6部分需要上層網路設備支持, 如果是固定IP的情況下, 可以選擇最快的SLAAC直接由上層委派IPv6位址於WAN端或著設定Native Static, 請注意固定IP的情況下LAN網段的規畫部分, 它會涉及到基本的子網路切割(IPv6沒有Subnet mask概念, 它是用prefix長度).
    一般大多屬於PPPoE的使用者則需要申請Tunnel建立IPv6通訊.
    有關IPv6的H/W offloading由於可能的bug情況, 現已被強制關閉掉, 因此現在都是交給CPU(MIPS 74Kc)去handle.
    [UPDATED, 201402141253] How to setup IPv6-over-IPv4 tunnel with Tunnel Broker?
    通常採用浮動制IP配發的用戶, 由其是使用PPPoE連線的, 為了使用IPv6會應用Tunnel Broker技術建立一條IPv4 tunnel封裝IPv6封包轉發到IPv6網路, 這樣看起來就像是兩個環境同時運作一樣(Dual-stack).
    對於終端的client用戶來說, 一般會下載專屬的Tunnel Broker撥接軟體來建立tunnel; 而另一種方式就是透過支援IPv6的網路設備來建立tunnel, 這需要視該網路設備所能提供的IPv6機能而定. Padavan對於IPv6支持了IPv6-over-IPv4 tunnel使用Tunnel Broker與IPv6網路連線:
    在透過Padavan設定IPv6 with Tunnel Broker之前, 必須先申請Tunnel Broker的連線資格取得相關的連線資訊, 這邊使用HE申請tunnel資格:
    當完成申請取得資格後, 可以免費建立5個tunnel. 對於一台N56U來說, 只需要一個即可.
    建立一條tunnel之後, 可以查看相關的連線資訊, 包括了伺服器端, 用戶端, 首碼, IPv6 DNS以及配發的LAN網段資訊:
    從Routed IPv6 Prefixes資訊看出允許兩種網段分配形式: 自動設定(autoconfig, Routed /64)和手動切割(Routed /48). 針對Padavan使用手動切割. 點擊對手動切割的指派去配發一組固定的IPv6網段, 用於LAN網段的規劃. 首碼為/48這代表了有存在subnet id的可能, 此為routing prefix, 將network prefix扣除routing prefix取得subnet id(64 - 48 = 16).
    一個範例為2001:470:cdcf::/48, network prefix為64, 取得subnet id(16)後, 取得存在subnet id的那段二進位字串用來規畫子網段.
    1. 2001:470:cdcf:[0000]::/48, subnet id長度不小, 因此可以很彈性規畫, 這裡簡單設定為: 2001:470:cdcf:[0001]::/48
    2. 已經應用了subnet id來規畫子網段, 將原本的首碼(/48)更改為/64: 2001:470:cdcf:[0001]::/64
    3. 2001:470:cdcf:[0001]::/64此為所需的一組IPv6組網段, 可將其配置在Padavan的IPv6設定裡.

    將相關的資訊填入至Padavan的IPv6設定裡, 首先設定有關Tunnel Broker的端點資訊以及WAN端的部分:
    其中一個關於MTU的資訊, 可以從HE的網站取得該數值設定(Default: 1480):
    接下來配置有關LAN的IPv6網段部分, 請注意LAN的網段規畫:
    按照剛剛的LAN網段計算的範例, 可將
    2001:470:cdcf:1::/64填入, LAN IPv6 Address填入自訂的Unicast位址(2001:470:cdcf:1::1), 此為對於LAN的上層Gateway, 然後填入LAN網段的首碼(Prefix, 64), 完成這些設定後將其套用. 可從Network Map查看相關的組態資訊:
    最後進行基本的連線測試以確定Padavan設定的IPv6是否正常通訊, 這邊使用FGT80C設定固定IPv6位址連線測試:
    於client端使用tracert進行追蹤:
    雖然經過不少節點, 但是最終與Padavan設定的IPv6成功通訊, 完成一個連線的過程(ICMP).

    SPI Firewall (Stateful Packet Inspection Firewall)
    Padavan提供所謂的SPI Firewall機能, 這個Firewall具備一些基本的防護能力, 包括Filter(Port, MAC, URL), DoS, SYN Flood Prevention等.
    SPI表示Stateful Packet Inspection, 對當前traffic穿入(Inbound/Outbound)防火牆(Firewall)時進行相關的封包檢測, 防火牆可以截取有關封包的資訊,例如SRC, DST, SRC_Port, DST_Port, Protocol(TCP/UDP/ICMP, etc)等..., 透過這些資訊進行封包檢測(Packet Inspection), SPI能夠處理何種程度得視該硬體以及軟體的機能而定. 
    SPI只是一個封包探測的檢測過程(部分packet), 它沒有涉及到特製化的樣版清單匹配(白名單)以及異動封包內容的操作. 在中高階的防火牆產品會涉及到的封包檢測(Packet Inspection)可能不單單只是一個單純的SPI, 它可能還會牽涉到清單匹配(pattern-matching, ex: White-list), 內容檢查(Content Inspection; basic or complete content)等, 因此對於系統效能以及系統記憶體使用會非常敏感.
    不同形式的檢測方式對於系統資源消耗也因此有所差異, 精準度也不一樣:
    大量的檢查(Inspection)會嚴重影響防火牆性能, 涉及到特殊的清單匹配或著內容檢查沒辦法只是單純的L3/L4 NPU直接加載.., CPU會承載業務或著其他專屬特製化的ASIC來分擔相關操作, 分離式架構在中高階的防火牆產品是比較常見的.
    在Padavan無法提供複雜的Firewall Inspection, 但提供了基本的SPI機能, 適應於一般家用環境. Padavan對於SPI Firewall的實作使用了iptables來達成基本的實作, 提供單純的允許(Allow)和阻擋(Block):
    DoS Attacks Protection請參閱如下wiki:
    SYN Flood Attack(DoS, 攻擊網路頻寬)請參閱如下wiki:
    在Netfilter中可以允許VPN穿透形式以及ALG服務的啟用或關閉, 另外包括了NAT Loopback. 其中一個項目: Maximum Connections; 它會牽涉到PPE的最大承載sessions數量, 一般情況下, 請勿隨意調整.
    其他URL, MAC, LAN to WAN filter則是不同用途的過濾功能; MAC Filter請使用在同一層的L2轉發環境下(MAC無法經過L3設備轉發出去).
    Note(s):
    1. 基於iptables的實作, 可以透過linux command查看相關資訊: 使用Administration的Console和SSH的CLI環境, 如下為GUI的Console:
    iptables -L -v -n
    Was this page helpful?
    標籤 (Edit tags)
    • No tags

    文件 1

    文件大小日期附件上傳者 
     unifi-ap-ac-lite-controller-2.jpg
    無描述
    71.64 KB22:18, 7 Aug 2017vxr動作
    您必須 登入 才能發佈評論。
    Powered by MindTouch Core