OpenVPN簡易文檔

1    OpenVPN簡介
    VPN替代昂貴的專線用以在開放的Internet上實現了一個虛擬網路，該虛擬網路本身在不安全的真實網路上對資料提供安全保護。
    OpenVPN實現了一個靈活的VPN，和通過修改協議棧而實現的基於IPSec的VPN相比，OpenVPN有以下的優點：
1.    OpenVPN無需對協議棧進行任何修改，無需專門的策略來解決VPN資料穿越NAT的問題，因此可在現有的網路進行規劃；
2.    OpenVPN使用虛擬網卡和路由進行虛擬網路的構建，配置十分方便；
3.    OpenVPN使用SSL協議對虛擬網路提供保護，從而實現“專用”，而SSL提供了豐富靈活的安全特性；
4.    OpenVPN的push模式可以最大限度簡化用戶端配置，伺服器和用戶端可以不必花費太多的精力來使得兩端一致。
OpenVPN實際上是虛擬網卡裝置，TCP/IP網路技術，路由技術，SSL結合而成的一個應用，前三者構建了虛擬網路—隧道串連的網路，最後SSL保證了虛擬網路通訊的安全—隧道通訊的認證和加密，因此使用OpenVPN的過程基本就是對上述四方面進行配置的過程。
2    OpenVPN的參數集以及配置執行個體
2.1    參數詳解
OpenVPN擁有很多的參數，但是很多參數涉及到很多的細節，首先如果不考慮過多的細節，那麼這些參數大致可以分為五類，其中有一些參數是為了配置方便，組合其它的參數而成的：
2.1.1    虛擬網卡配置參數：
1)    --dev tunX|tapX：配置虛擬網路使用的網卡裝置，X是一個數字表示網卡的編號，在Unix/Linux系統中，它是一個字元裝置，在Windows中，它是一個裝置命名空間中的一個節點，tun裝置和tap裝置的區別在於出入前者的第三層（IP）資料報，而出入後者的是第二層（乙太網路）資料幀。
注意：tap裝置是二層裝置，tun裝置為三層裝置，此二者各有優劣，簡述如下：
tap特點：
a)    應用這種裝置可以複用任意的三層資料報；
b)    構成一個兩路層網路，比如乙太網路，因此廣播資料可以自由跨隧道傳輸；
c)    無需路由即可進行節點通訊；
d)    配置簡單，但是缺乏靈活性，IP層的優良特性無法自由應用。
tun特點：
a)    可以應用IP層的所有特性，比如Routing，IP-Qos，IP-fragment/de等，但是只支援IP資料報；
b)    構成三層網路，節點間如不在一個子網要路由；
c)    三層虛擬網路的每個子網下面沒有鏈路層承載（ip資料報直接匯出），因此鏈路層特性無法應用，比如乙太網路廣播無法跨隧道傳輸，因此此虛擬網路是無法指定網關的。
2)    --dev-type dt：指示虛擬網卡裝置的類型，僅僅在—dev參數無法識別裝置類型的時候使用。
3)    --dev-node node：任意節點node被指示為虛擬網卡裝置，node的路徑以及名稱可以任意，但是如果不是tunX/tapX的形式，那麼必須配置—dev-type參數。
4)    --lladdr hw：為虛擬網卡配置鏈路層地址。
2.1.2    網路設定參數：
1)    --local host：配置本地使用的IP地址，如果不是為了bind，那麼可以不配置此參數，OpenVPN會自行處理。
2)    --remote host [port]：用於client端，配置client串連的server的IP或者主機名稱以及port，該參數可以配置多個用以實現一定的冗餘，client則按照配置順序依次串連server，直到串連成功為止。
3)    --proto p：配置隧道的類型，可以是udp或者tcp，其中tcp必須指明是server還是client，而udp可以不區分server和client，因此p可以為udp，tcp-server，tcp-client。
注意：用tcp還是用udp構建隧道呢？預設是udp。任何有串連的協議在出現丟包時都會要求重發或者自動逾時重發，為了避免因對網路頻寬的未知或者網路擁塞而丟包從而導致端點重發，tcp實現了慢啟動，滑動視窗以及加增承減等機制，不幸的是，以上機制僅可用於分層模型中的一層，在不同層次都實現得如此複雜就可能引起判斷疊加從而使得上述機制無法做出最好的判斷，比如用tcp建立的隧道，並且上面承載的又是tcp資料，那麼一旦出現丟包，最終的端點以及隧道都要重發資料，這就導致了網路流量突然增大，後面的行為很難在短時間給出預測並採取措施。事實上如果隧道本身並不是非用tcp不可，那麼最好使用udp，保證串連與否是最終終端的事，而不是隧道的事，如果說終端使用者使用tcp，那麼他自己就保證了串連，如果他使用udp，那麼說明他不在乎是否有串連，因此隧道使用udp，相反隧道使用tcp建立的話，如果終端使用者使用tcp已經保證了串連，隧道沒必要再多此一舉，如果終端使用者使用udp，那麼隧道的tcp就降低了使用者串連的效率，抵消了他使用udp的結果。
4)    --connect-retry n：配置串連重試的次數，僅僅對於—proto參數為tcp-client時有效。
5)    --connect-timeout n：串連重試的間隔。
6)    --auto-proxy：
7)    –bind：
8)    –nobind：
9)    --link-mtu n：配置四層鏈路的MTU，同時用同樣的數值配置裝置的MTU。
注意：這個配置可能會引起莫名其妙的問題，就其本質是由於OpenVPN不允許通過隧道的資料被任意分段，即使是IP分區也必須妥善處理，OpenVPN用一種規則的方式來收發socket資料。IP層將資料路由到虛擬網卡前如果探索資料報的長度大於虛擬網卡的MTU，那麼就會將資料報分區，如果VPN兩端的虛擬網卡的MTU設定不一致，OpenVPN接收socket資料的時候就會產生問題，因為最一般的情況下OpenVPN調用recv/recvfrom的時候，參數中的len總是設定成自己的link-mtu，假設兩端H1和H2的link-mtu分別為L1 和L2（L1>L2），H1端發送資料給H2，則資料在H2則會接收不完整，因此勢必會產生錯誤，即使解密收到的資料可能正確，由於資料長度不一致，校正時也會出錯，即使在沒有校正的情形下，由OpenVPN發送給虛擬網卡的IP資料報也會不完整。因此最好不要配置link-mtu參數，讓它預設值好了，如果非要配置，保持兩端一致。可以在linux上用strace，tcpdump以及OpenVPN原始碼確認以上問題，具體為何這樣設計還不清楚。如果在不考慮安全因素（程式輸出的意思是防止active attack）可以更合理一些的話，我覺得recv資料時要按照對方的mtu來接收，畢竟recv和send只是一個中間階段，資料從對端虛擬網卡的字元裝置出來後就被send了，然後在本端被recv，之後被write進本端的虛擬網卡字元裝置，如果僅僅按照本端的mtu來接收，勢必會有問題，就好像在物理層上將資料截斷一樣。（在隧道的一端ping另一端，如果mtu不一致並且ping包大於mtu的小者的話，一定不同，可是僅僅將兩端作為中間隧道的話就不一定了，資料從主機A，經由隧道的起始Ts，到達隧道終點Te，最終到達主機B，如果Ts和Te的mtu中小者都比A和B的mtu的大者大，在不考慮複雜的分段情況下是可以通的）因此，一種“幾乎總是正確”的配置方法就是將mtu配置成一個很大的值，要比已知的物理鏈路的mtu都大，這樣一來不會出錯，二來可以不必擔心兩端不一致，三來可以最大限度的發送資料，而不會因為隧道太窄的緣故而降低資料發送速率，如果不理解以上這些或者為了保險起見，還是將mtu留預設比較好。
10)    –tun-mtu：注意事項同上，但是要強調和link-mtu之不同，此二者配置一個即可且只能配置一個，此中之緣由在於其關聯性，tun-mtu為虛擬網卡之mtu，而link-mtu則為鏈路的mtu，其大小相差一個固定長度，二者區別等同於TCP的MSS和物理鏈路的MTU之區別。
11)    –shaper：該參數對隧道的頻寬進行了限制，主要用於建立多個通道時在各個通道進行策略化頻寬分配，如果只建立一個通道，也就是說僅僅運行一個OpenVPN執行個體的話，這個參數就目前版本而言意義不大，因為本身單進程單線程的OpenVPN速度就很慢，再限速更沒有意義了。
12)    –txqueuelen：該參數設定虛擬網卡的最大排隊包的數量，也就是隊列長度，預設為100，對於OpenVPN這樣很慢的VPN來說，100就夠了，即使你設得再大，使用者空間的OpenVPN進程處理不過來還是白搭。
2.1.3    路由參數：
1)    --route network [netmask] [gateway] [metric]：增加一條路由。
2)    --max-routes n：
3)    --route-gateway gw|'dhcp'：
4)    --route-metric m：配置路由的傳輸開銷
5)    --route-delay n [w]：配置路由添加的延遲，這是為瞭解決一IP地址自動設定的問題，有時候OpenVPN要添加路由了，可是OS還沒有準備好，所以要給與一定的延遲。具體來說就是，client和server的串連建立以後，server需要往client端push一些資訊，包括虛擬網卡ip地址，子網路遮罩等必須的資訊以及路由等可選資訊，client接收到以後需要在本機做相應的配置，比如配置虛擬網卡的ip/子網路遮罩，添加路由等，並且OpenVPN對虛擬網卡的管理採取了一種懶惰的方式，也就是對於server只有在OpenVPN起來，對於client只有在和server的串連建立的時候才會建立虛擬網卡對象並初始化，這個初始化過程就包括了設定ip地址/子網路遮罩，這個過程完成之前，添加路由是失敗的，因此必須提供一些延遲保證虛擬網卡初始化完畢之後再添加路由。這個選項主要針對某些虛擬網卡驅動設計不友好的系統，比如基於NDIS驅動的windows系統，虛擬網卡的ip地址“看起來”是通過DHCP來分配，而DHCP分配是需要花費時間的，此間添加路由的請求必須等待。

2.1.4    SSL及安全參數：
1)    –genkey：產生一個對稱金鑰，該參數只能單獨使用，該對稱金鑰的產生是為了使OpenVPN兩端共用，從而不再使用SSL握手協議進行密鑰協商。
2)    --secret file：使用共用的對稱金鑰。這實際上省去了SSL的握手，用於通訊雙方確信已擁有絕對保密絕對安全的對稱金鑰的情況，實際上SSL的握手也是為了這個保證，二者殊途同歸，因此問題的難度就在於一端用—genkey產生的密鑰如何傳輸至另一端。這其實就是另一個大問題了，可以用數位信封傳過去，甚至可以冒險用明文直接發過去，這些都不是OpenVPN要考慮的。一般地在都是通過scp程式傳遞的，方便又安全。
3)    --reneg-XXX：這一族參數用來重新協商session key。OpenVPN基於SSL協議，然則其用法另有說法，SSL協議內建認證和加密功能，對於OpenVPN來說此二者是分開的，如果不考慮認證，密鑰協商的過程很容易受到中間人攻擊，因此不管是基於IPSec這種修改或掛鈎協議棧實現的VPN還是OpenVPN都提供了認證機制。OpenVPN使用認證來進行認證，使用DH來進行密鑰協商。使用DH而不是別的是由於建立的隧道安全參數要每隔一段時間進行一次重新協商，預設時間為1個小時，而DH的效率很高，它不像RSA產生密鑰那麼耗時（由於美國出限制或者認證中沒有可用於加密的公開金鑰，在SSL握手時就需要臨時產生一對RSA密鑰），如此在server key exchange message訊息中傳輸的就是DH參數了。
4)    –ca file：CA認證，用以驗證對端的使用者認證，這個參數可以包含多個認證，也就是一條憑證鏈結，在Unix/Linux中可以用cat命令將多個認證追加成一個檔案。
5)    --cert file：自己的認證，用於傳遞給對端以表明自己的身份或者實現其它的准入性驗證。
6)    --key file：對應—cert參數的key檔案。
7)    --cryptoapicert select-string：用於從Windows的認證Store中擷取認證，如此就不再需要—cert和—key參數了，select-string是一個字串，可以認為是一個尋找“索引值”，以”名稱:值”的形式存在，比如使用頒發給名字是“老李”的個人的認證，那麼select-string就是：”SUBJ:老李”。這個參數多數用於key或者認證無法單獨匯出的環境下，比如一些裝置。
2.1.5    事件參數：
1)    --route-up cmd：cmd是一個shell指令碼，並且可以攜帶參數，該指令碼在所有路由被添加之後被執行。
2)    --route-noexec：
3)    --route-nopull：用於client端，如果client端配置了—pull，那麼該參數保證client不會pull過來server端push的路由。
4)    --allow-pull-fqdn：
5)    --ping n：每n秒鐘ping一次對端。
6)    --ping-restart n：如果n秒收不到對端的ping報文，那麼就重啟。
7)    --ping-exit n：如果n秒收不到對端的ping報文，那麼就退出。
8)    --keepalive n m：該參數項為5)和6)的封裝，展開後有下面的形式：
if mode server:
ping n
ping-restart 2*m
push "ping n"
push "ping-restart m"
else
ping n
ping-restart m
注意：ping/ping-restart實現了一個心跳保活機制，這個機制在tcp協議構建的隧道和udp協議構建的隧道中表現是不同的，使用tcp建立的隧道本身就是有串連的，如果一端進程異常退出，那麼OS必然會發送reset報文，這種情況其實keepalive的意義並不大，但是如果是諸如網線被拔掉或者斷電之類的問題，keepalive就有必要了，因為tcp沒有機會在事前發送任何報文，此時tcp隧道的keepablive配置就和udp一樣了，如果ping-restart配置的過於大，對於tcp，將有更多的機會依靠tcp本身的逾時重發機制使串連保持（前提是機器啟動了或者網線又插上了），而對於udp，只能依靠這個ping-restart，否則它永遠不知道對端已經斷開過了，如果對端在ping-restart配置的時間內重新啟動了，本端將不會知道對端已經斷開過又重新啟動了。反過來如果ping/ping-restart配置過小，將會有大量的ping包出現在網路，並且會引起大量的重連，有時由於網路擁塞導致的ping接收逾時這種根本就不需要重連的情況也會重連。到底配置成多少需要根據自己網路的規模，使用的協議等因素來權衡。
9)    --persist-tun：在由於接收到SIGUSR1訊號或者由於keepalive逾時（--ping-restart）原因而重建立立串連的時候，並不關閉並且重新開啟虛擬網卡裝置。該參數會對網路行為造成影響，如下一例：client端由於某種原因休眠或者待機了，或者在任何可能的原因下重設了網路而沒有結束OpenVPN進程，VPN的路由隨著網路的重設可能就被刪除了，此時如果不重新開啟虛擬網卡，待重新連上server之後，server端push過來的路由將不會被添加到client端主機路由表，最終之結果就是client端看到VPN網路仍然連通，然則由於沒有server端推送的路由而無法實際進行通訊，VPN網路仍然連通全系一條協議棧自動探索的鏈路層路由，而該路由只要虛擬網卡up，就會自動添加，如果使用者不檢查路由表或者非技術人員不懂的檢查路由表，這種問題很難被排除。
10)    –persist-XXX族：以上描述了--persist-tun以及它可能造成的問題，但是參數存在的意義並不是為了引起問題的，相反是為瞭解決一系列問題的，之所以存在persisit參數，顧名思義是為了“保持”一些東西，也就是說這些配置在由於接收到SIGUSR1訊號或者由於ping-restart而重設串連時，這些配置不會改變，這才是這一族參數存在的意義，比如管理員由於某種原因想熱重啟一下VPN服務，或者由於網路擁塞而導致keepalive逾時，重新分配IP地址，重新設定路由等動作都是沒有必要的。和該族參數有關聯的一個參數就是—user參數。
11)    --client-connect cmd：只要有client串連，伺服器就會執行cmd。
2.1.6    OpenVPN本身的配置參數：
1)    --nice n：設定VPN進程的nice值，此參數將影響VPN進程的優先順序，數值越小優先順序越高。
2)    –user user：切換OpenVPN啟動並執行UID。User是一個UID。這個參數的目的在於安全性，一旦有攻擊者擷取了OpenVPN進程的控制權，他所能做的也很有限。但是注意這種主動放棄root許可權的行為是無法復原轉的，否則攻擊者也可以逆轉，該參數也就失去了存在的意義。所以要注意的是，如果使用了—user參數，那麼要確保一系列persist參數被設定從而在軟開機OpenVPN的時候避免進行需要root許可權的操作，這是因為很多操作是需要root許可權的，比如ifconfig。
3)    –mlock：該參數的行為和作業系統緊密關聯。配置該參數的結果就是將key等敏感資訊鎖在記憶體而永不被換入磁碟，如果不過度專註於其對效率的提升，則僅從安全性考慮它的意義也是不容忽視的。如果key被換入了磁碟，那麼key就有可能被竊取，攻擊者只需要簡單的從交換分區讀取即可，這裡的key並不是指key檔案，而是動態產生的用語協商密鑰的資料，key檔案一般以映射方式進入記憶體編址空間而不會被換入交換空間，如是可以說，key檔案本身也是不安全的，攻擊者掌握了你的機器，讀取你的磁碟易如反掌，因此key檔案的保護應依賴於你的主機安全，對於鎖在記憶體的資料的保護，更進一步，應依賴於比主機安全更進一步的記憶體管理的安全，即使這樣也還是可以攻破的，比如如果你有root許可權，在很多linux上你都可以讀取/dev/mem來dump當前的記憶體，這和讀取磁碟有何區別呢？dump記憶體真的比dump交換分區更難嗎？實際上一旦你有了root許可權加上你有紮實的功底，整台機器的任何物件都盡在你的掌握之中。（最好的辦法就是永遠不將敏感性資料匯出到“公用”空間，我說磁碟和記憶體都是可以複用的公用空間，公用空間的不安全性在於大家都可以訪問，充其量出示一些證明就能被准入，而這證明之真偽連帶驗證之邏輯本身又是一個極其複雜的體系，因此最好在私密空間完成所有的涉密操作，比如PKCS#11中所描述的，私密空間匯入匯出的僅僅是操作之結果以及操作之把手—控制代碼，正如開動汽車只需鑰匙，按鈕，方向盤而無需瞭解輪軸，氣缸，變速器一致。）
4)    --mode m：配置VPN的mode，有p2p和server兩類，p2p顧名思義就是點對點，也就是說整個虛擬網路只有兩台主機，這兩台主機一台是伺服器另一台是用戶端；server的含義和p2p不同，它可以實現一個一對多的虛擬網路，同時可以有多個用戶端串連入一個伺服器。
5)    --topology t：2.1版本新增參數，指定網路拓撲，選擇性參數為net30，p2p以及subnet。net30拓撲結構主要用於p2p網路，該種網路假設server和client均存在於一個p2p鏈路之上，因此各需要配置一個p2p網關，每對串連要用去4個IP地址，這也正是30的含義，client和server均佔有一個30位的子網路遮罩的網路，每端餘下4個IP地址，然則一個子網中全0號IP表示子網本身，全1號IP表示廣播位址，於是僅留下兩個IP地址可用，net30雖然用於p2p鏈路，在乙太網路這種廣播網路中也是可以使用的，該模式十分浪費IP地址；p2p拓撲用在一種半p2p的網路中，server將分配且只分配一個IP地址給client端，如此一來client端就可以和server端直接建立聯絡，而不必再通過一個p2p網關了，而server端仍然保留p2p網關，類似net30模式；subnet拓撲則是完全實現了虛擬網路從p2p模式向廣播型網路的過渡，server端和client端均使用且只使用一個IP地址，如此一來server和所有的client構成一個可以基於廣播鏈路的虛擬區域網路（注意不是VLAN），大量節省了IP地址並且降低了配置的難度。
注意：net30->p2p->subnet的演化過程有兩層含義，第一層含義代表了OpenVPN本身的版本升級，在2.0之前OpenVPN是不支援multi-clients的，也就是說所有的p2p模式以及c/s模式均是一對一的串連，因此虛擬網卡的配置很簡單，直接配置上對端的ip地址即可，但是到了2.0及之後，OpenVPN的一個server可以對應多個用戶端了，按照前面的思路，只需要將client虛擬網卡的地址p2p地配置成server的虛擬網卡地址即可，可是對於Windows這樣卻不行，於是就引出了第二層含義，為了相容Tap-WIN32驅動，Tap-WIN32驅動不支援在“點對多點/多點對多點”的鏈路上建立p2p串連，於是不得不用net30的方式來“類比”出一條p2p的鏈路，比如對於client來講，tun的地址配置是：
10.8.0.6<-->10.8.0.5
server的配置是：
10.8.0.1<-->10.8.0.2
在這裡，.5和.2地址都是為了類比p2p的，對於client來講，.5就是server，而對於server來講，.2就是client，所以這些類比的地址僅僅是在OpenVPN內部使用，對於外界是不可見的。這樣在不支援真實p2p配置的Tap-WIN32上就可以配置出一條虛擬p2p鏈路了，而類比的地址僅僅作為路由將資料導向真正的server。
6)    --push "option"：推送一個配置到對端，如果對端期望接收並應用該配置，那麼它必須配置—pull參數。
7)    --client-to-client：使能用戶端之間的通訊，僅在—mode配置成server的時候有意義，此時server被眾client串連，server就是這些client之間通訊的“路由器”。
8)    
察看OpenVPN的man手冊或者直接執行—help，你會得到另外一種參數分類的方式，基本上—help顯示出的結果是基於OpenVPN的設施進行分類的，而本文檔則是基於OpenVPN的行為進行分類的。
2.2    OpenVPN的配置執行個體
OpenVPN的使用非常簡單，它有兩種使用方式，這個和*nix的傳統相一致，一般提供眾多命令列參數的程式都會提供一個設定檔，因此如果環境過於複雜，那麼用設定檔要比直接使用命令列更方便。