外部網路由於只會知道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