NCTUns Tunnel Architecture PartI

在有關 NCTUns 的 Design 最重要的一環，就是利用 tunnel interface 達到 Traffic flow 的 Packet 可以在 kernel 和 user-level 的 NCTUns engine 可以相互轉傳資料，主要原因在於整個 NCTUns 的 Layer3 以上都是使用真實世界 Linux 系統的 Protocol Stack，最大的好處莫過於可以更逼近於真實世界系統的運作情況，詳細設計不是這一篇的重點，在這主要針對底層 tunnel 的設計。

Tunnel interface device 原本就存在於 Linux Kernel 裡，我們主要是 hack 了原本的功能，使其擁有我們所需要的能力，但因為原本 hack 的方式異常暴力，幾近破壞了原本 tunnel 的服務，因此如果使用我們 NCTUns kernel 會面臨到需要使用 tunnel 能力的服務全部無法運作（諸如 VPN 等），在設計上，NCTUns 允許最多開啟 4096 個 tunnel 做為模擬 Host 的 interface，額外還有 event tunnel 專司用來傳送 kernel 上到 engine 的 event 以及 tcpdump packet tunnel 專司用來處理 tcpdump 的 packet flow，因此使用的架構如下圖：


在右圖中可以看到 Tunnel device driver 上面建立了 4098 個 tunnel 的 devfs node，但事實上 open 這些 devfs 都會呼叫到同樣下層的 tunnel device driver，然而透過 ioctl 之後才會創建出 net_device 並將 net_device 向 network device subsystem 註冊。

原本 NCTUns engine 架構會針對每個有可能用到的 net_device 都預先使用 mknod 指令建立 devfs node，使得一開始就先建好 4098 個對應到同一個 tunnel device driver 的 devfs node ，這動作就顯得多餘，因此我在這邊做了大幅度的改進，主要有兩點如下：

撰寫獨立 nctuns_tun device driver
從 tunndel 將模擬所需使用的功能獨立成為 nctuns_tun 和原本 tunnel device driver 分開並使用不同 device major number ，最大好處在於可以維持原本 tunnel 功能，又可兼顧 porting 的獨立性，關於 nctuns_tun 的架構在 PartIII 再做詳細介紹。

移除多餘 devfs 的使用
將原本註冊了 4098 個 devfs node 改成僅需一個 devfs node 即可，更進一步使用 dynamic allocate 未使用的 major number 給 nctuns_tun 使用，配合 udev 機制於 loading 時動態創建這個 devfs node，詳細 udev 運作機制於 PartII 再做說明。


如右圖一般，如此一來在 user-level 的 NCTUns engine 於模擬前設定 tunnel 動作也會變的簡單許多，安裝的時候也不需要在 creating tunnel 步驟等待一段時間，甚至不需要等待，只需將 udev rule file 放進 udev/rules.d 目錄裡即可。二來透過動態配置 major number 也可以避免使用者因為 device 過多而產生 major 衝突問題。

當然這部分因為 nctuns_tun 只需要一個 major, minor pair 即可，因此要註冊在 misc 類別底下也可以，原本的 tunnel device 就是這種作法，為了保留彈性才讓 nctuns_tun 以一個獨立的 major 來配置。