Openswan Porting to Pronghorn-Metro 實務經驗分享 05

在上一次的最後，我們總算將這隻難纏的天鵝給移植到版子上了，接下來，會一帆風順嗎？？（我好希望這答案是肯定句唷 ... ）

首先，來參考一下官方網頁的設定步驟：

http://wiki.openswan.org/index.php/Openswan/Configure

首先，來看看自己身上的金鑰

# ipsec showhostkey --left

結果，當然找不到金鑰囉，哼，那就自己產生吧。

# ipsec newhostkey --output /etc/ipsec.secrets

恩，好像有點久ㄟ，畢竟只是版子，運算能力差了點，RSA 又是很需要運算的動作，先去作其他事吧...。天真的我真的去處理其他工作上的事了。幾個小時以後... 「甚麼，還沒算完，到底怎麼了？？」嵌入式系統在爛也不是這樣的吧！！於是一氣之下，去看看到底他程式是怎麼寫得...

openswan/programs/rsasigkey/rsasigkey.c

33 #ifndef DEVICE
34 #define DEVICE "/dev/random"
35 #endif

恩... /dev/random ... 嗎... 思緒飄回過去。那年，我還是甚麼都不懂得研究生，一個叫做「小龍」的學長正在研究室完版子，那時候他正在 porting 一個叫做 dropbear 的 SSH Server （附帶一題，這是嵌入式系統常見的 SSH Server，跟常見的 Openssh 比起來輕巧多了）

小龍：阿，總算搞定了

我：不過就是 porting 一個伺服器上去啊，怎麼能讓學長這麼鬆了一口氣（我真是不知天高地厚）

小龍：是早就上版子了啦，但一直不知道為甚麼會卡住，剛剛才解決。

我：卡住？

小龍：對啊，就是程式執行就會停在那邊。找到理由就很簡單了。聽好了， Linux 底下是透過 /dev/random 去取得 random number，而 /dev/random 會收集系統的 interrupt 來作為產生亂數的 seed。你想想看之前你用 putty key gen 來產生憑證的時候，他是不是有要你敲鍵盤嗎？那也是同樣的意思。而在 Linux 底下，如果他覺得他無法產生「數學上夠完美」的亂數，整個系統就會停在那裡，等到收集到足夠的熵。

我：如果是這樣的話，那照理來說 Openssh 也有同樣的問題啊，可是我在家裡的 Linux Server 卻重來沒遇到這件事情，何解？

小龍：你在家裡使用的是 Fedora 對吧（不要懷疑，我研究所的時候真的是 RH 的支持者），那種 distribution 在開機的時候早就做了一堆事情，也為系統累計了足夠的亂渡了，但是 uclinux 沒這麼複雜 ... 所以無法收集足夠的亂度。

我：那要怎麼辦呢？

小龍：/dev/urandom ...

感謝小龍學長～不然天曉得我要研究多久...稍微紀錄了一下，請參考下面的內容：

/dev/random v.s. /dev/urandom

解決方案：

mv /dev/random /dev/random_bak
ln -s /dev/urandom /dev/random

於是，順利的產生出 Host Keys. 然後，為了順利執行 ipsec，也安裝了一些需要的工具。所需要的 ipsec.conf 如下：

conn mswitch
....left=192.168.8.227
....leftid=@123.mswitch
....leftsubnet=172.16.0.0/24
....leftrsasigkey= xxx （不告訴你）
....leftnexthop=192.168.8.228
....right=192.168.8.228
....rightid=@456.mswitch
....rightsubnet=10.0.0.0/24
....rightrsasigkey= yyy （不告訴你）
....auto=add

一切都很順利...於是...執行吧
才怪～又遇到問題了呢 ... 那麼，下回再見囉~

Porting 的紀錄又翻過了一頁～

留言

張貼留言

這個網誌中的熱門文章

如何將Linux打造成OpenFlow Switch：Openvswitch

圖片
因為工作上被指派去做SDN，自然需要SDN的網路設備才可以。問題是SDN Switch賣的超級貴的，一台差不多要30萬台幣。這跟當初推廣SDN的人說法完全不一樣！他們當初說SDN網路設備會變得比較便宜，因為網路設備上不需要在堆疊這麼多的網路協定，因此硬體可以Cost Down，也可以省下軟體的錢。問題是，如果單單賣純種SDN Switch根本是不可能的事情啊，因為缺少可以在上面跑的軟體和控制器，所以只好保留傳統設備上的功能，再多加OpenFlow的支援，並提供給使用者選擇的開關。這樣當然只會更貴不會便宜啊！！ 在沒錢、沒人、沒資源的情況下，要怎麼辦呢？用模擬軟體？可惜要Demo的時候行不通。那就只好自己來打造一台SDN Switch了。雖然沒有晶片的支援，但只要不牽扯到效能的話，應該沒太多問題。下面是我和同事想過的一些解決方案： 自己打造OpenFlow的Agent，反正OpenFlow的網路協定並不複雜，然後透過Linux Kernel的netfilter來模擬晶片的行為。因為是用軟體模擬，所以效率會比較差，但反過來說，因為是軟體，所以我可以滿足所有OpenFlow的要求，不會有做不到的事情。不過這個提案被一個PM的同事封殺了，理由是這不能賣錢 ...  有一個同事找到一個有趣的專案 FlowForwarding 。這個專案提供了Open Source的OpenFlow Agent: LINC。LINC是用Erlang所開發的軟體。雖然我根本不會Erlang，但程式語言不是我考慮的重點，我好奇的是它要怎麼模擬晶片來處理封包。從網頁上看到，LINC在使用上需要libpcap的函式庫，初步猜測，LINC應該是把所有的封包透過libpcap攔截到user space以後進行修改。這樣做的效率應該會比我的解決方案更差。 OpenVswitch 。這是大部份產品的解決方案。我聽過一堆公司宣稱自己有了SDN Switch，而內容只不過是把Openvswitch移植到自己原有的產品上罷了。一樣，我好奇它要怎麼模擬晶片來處理封包，看了編譯過程，它會產生openvswitch.ko，在加上它利用bridge的特性，所以應該是在linux bridge那邊進行hook後修改。 考量到移植的方便性，所以後來我個人選擇openvswitch作為SDN Switch...
閱讀完整內容

我弟家的新居感恩禮拜分享：善頌善禱

語本禮記·檀弓下：「晉獻文子成室，晉大夫發焉。張老曰：『美哉輪焉！美哉奐焉！歌於斯，哭於斯，聚國族於斯。』文子曰：『武也，得歌於斯，哭於斯，聚國族於斯，是全要領以從先大夫於九京也。』北面再拜稽首。君子謂之：『善頌善禱』。」 不知為什麼，我一直對禮記中的這一篇印象深刻，大概是小時候記憶力比較好，所以一直刻劃在心中吧。之前有天我弟要我把時間留下來，要參加他們家的家庭禮拜，結果到了以後才發現原來是新居感恩禮拜（我說，你們小倆口根本已經搬進去很久了吧），然後居然還要說些祝福的話（喂喂，下次這種事要先講，我本來抱定只聽只吃不說話的態度啊），在想要講什麼的時候，第一個浮出的念頭就是「善頌善禱」的這個故事 ... ㄜ ... 不是聖經經文啊，所以就想找找，在聖經中哪一段有「新居落成」的相關經節，可以作為分享，結果就是以下面這段文章來做分享： 王上9：1-10 所羅門建造耶和華殿和王宮，並一切所願意建造的都完畢了，耶和華就二次向所羅門顯現，如先前在基遍向他顯現一樣，對他說：「你向我所禱告祈求的，我都應允了。我已將你所建的這殿分別為聖，使我的名永遠在其中；我的眼、我的心也必常在那裡。你若效法你父大衛，存誠實正直的心行在我面前，遵行我一切所吩咐你的，謹守我的律例典章，我就必堅固你的國位在以色列中，直到永遠，正如我應許你父大衛說：你的子孫必不斷人坐以色列的國位。倘若你們和你們的子孫轉去不跟從我，不守我指示你們的誡命律例，去事奉敬拜別神，我就必將以色列人從我賜給他們的地上剪除，並且我為己名所分別為聖的殿也必捨棄不顧，使以色列人在萬民中作笑談，被譏誚。這殿雖然甚高，將來經過的人必驚訝、嗤笑，說：耶和華為何向這地和這殿如此行呢？人必回答說：是因此地的人離棄領他們列祖出埃及地之耶和華─他們的神，去親近別神，事奉敬拜他，所以耶和華使這一切災禍臨到他們。」所羅門建造耶和華殿和王宮，這兩所二十年才完畢了。 在列王記上的記載裏面，所羅門花了二十年的時間完成了聖殿和皇宮的建造，而現在上帝來參加這個「新居感恩禮拜」。上帝說：「 我已將你所建的這殿分別為聖，使我的名永遠在其中；我的眼、我的心也必常在那裡。 」感謝上帝，這是上帝同在的保證，這是基督徒最喜歡傳講平安的福音：「以馬內利，上帝與我們同在」，以上帝給的祝福來說，沒有比這更大的。可是等等，接下來的話是新居落成時所該給的祝福嗎？一開始還好，可...
閱讀完整內容

Linux Virtual Interface: TUN/TAP

圖片
今天要介紹的，不是什麼新技術，只是之前沒碰過，而現在工作有用到，所以做個私人紀錄。 問題描述以及過去的解決方案 工作上面遇到的問題，如何建立一張虛擬的網路介面，並且讓封包經過該介面後額外封裝一個新的 Header。建立虛擬網路介面不難，但要如何去撈封包（使封包經過該介面）呢？並且之後封包的處理又是如何？之前在公司曾經用過幾種招數： 第一個作法是透過 Bridge 來將網卡綁在一起，然後去修改 Bridge 的程式碼做自己想做的事情。第二個作法是透過 Netfilter 來攔截封包，做完事情以後再硬導到正確的網卡。這兩個作法很 亂來 ，我的亂來指的是不理會 Linux 內部封包處理流程，隨意的處理並安插封包，但我可沒說這樣做不到啊。第3種方法很好，完全符合 Linux 核心的封包處理程序，代表的例子就是 GRE，問題是現在的封裝技術亂七八糟（這個詞純粹是為了抱怨用），並不一定是單純的 IP-in-IP ，所以這個架構不一定適用。正當決定來亂搞的時候，有人提供了一個新的方向（應該是說自己孤陋寡聞）：TUN/TAP。 TUN/TAP: Virtual Network Kernel Device 我們先抄一下 Wiki 上的說明： In computer networking, TUN and TAP are virtual-network kernel devices . Being network devices supported entirely in software, they differ from ordinary network devices which are backed up by hardware network adapters. TUN (namely network TUNnel) simulates a network layer device and it operates with layer 3 packets like IP packets . TAP (namely network tap) simulates a link layer device and it operates with layer 2 packets like Ethernet frames . TUN is used...
閱讀完整內容