Juniper SRX VPN (Virtual Private Network)虛擬私人網路設定
Juniper
SRX VPN (Virtual Private Network)虛擬私人網路設定
在開始閱讀本篇文章之前，若您是沒有VPN設定經驗的初學者，建議您可以先閱讀下列的文章後再繼續本篇文章，這樣您會對VPN設定有比較好的概念。
什麼是VPN ?
下圖為網際網路VPN拓墣圖。
IPsec
VPN有兩種設定方式，分別是Route-Based IPsec VPN 和 Policy-Based IPsec
VPN。
而到底何時要用Route-Based VPN，何時該用Policy-Based
VPN呢?
以下為Juniper官方網站對IPsec VPN的介紹與描述：
瞭解基於策略(policy-based)的IPsec
VPN
對於基於策略的IPsec
VPN，安全性原則將其操作指定為用於傳輸通信並符合策略的匹配條件的VPN隧道。VPN是獨立於策略語句配置的。策略敘述語句通過引用VPN的名稱來指定允許訪問隧道的通信量。
對於基於策略的VPN，每個策略都與遠端對等方建立一個的單獨的IPsec
SA，每個IPsec
SA都是一個單獨的VPN隧道。例如，如果策略包含來源位址群組(group source
address)和目標位址群組(group destination
address)，則每當屬於該位址集的使用者之一嘗試與指定為目標位址的任何一個主機通信時，就會協商並建立新的隧道，由於每個隧道都需要自己的協商過程和獨立的一對SA，因此，使用基於策略的IPsec
VPN可能比使用基於路由的VPN更耗費資源。
瞭解基於路由(Route-Based)的IPsec VPN
對於基於路由的VPN，您可以配置數十種安全性原則(security
policies)並透過兩個網站之間的單個VPN隧道來調節交通流量，並且在工作時只有一組 IKE 和 IPsec SA。與基於策略的VPN不同，對於基於路由的VPN，策略參考(refers to)的是目標位址(destination
address)，而不是VPN隧道(VPN
tunnel)。當JUNOS
OS查找路由以找到用於向資料包的目標位址發送通信的介面時，它通過安全的隧道介面(st0.x)來找到路由。而這個隧道介面會和特定的VPN隧道綁定，並且如果策略允許的話則會將通信傳送到隧道。
瞭解基於路由和基於策略VPN的差異
使用基於策略的 vpn
隧道，隧道被視為與來源、目標、應用程式和操作(ource，destination，application，and action)一起使用的物件，它包括允許 vpn
通信的隧道策略。在基於策略的 vpn 配置中，隧道策略通過隧道名稱來引用 vpn 隧道。
使用基於路由的vpn，策略不專門引用 vpn
隧道。相反，該策略引用目標位址。當安全設備進行路由查找以找到必須通過其發送通信以到達該位址的介面時，它通過安全隧道介面(st0.x)來查找路由，並綁定到特定的
VPN 隧道。
因此，使用基於策略的VPN隧道，您可以將隧道視為構建策略的元素。使用基於路由的VPN隧道，您可以將隧道視為提供通信的一種方法，而該策略可作為允許或拒絕傳輸該通信量的方法。
以下是實施基於路由的VPN的原因:
·
在通過VPN傳輸時需要啟用來源或目標nat(nat-src或nat) 時。
·
兩個lan之間存在重疊的子網(overlapping
subnets)或 IP 位址時。
·
在網路中使用了中心和分支(Hub-and-spoke - 集中星型)的VPN拓撲。
·
當需要主要VPN和備援VPN存在時(VPN備援機制)。
·
在VPN
中運行動態路由式(dynamic routing)通訊協定
(例如，OSPF、RIP 或 BGP) 時。
·
需要使用VPN來訪問跨越多個子網或網路的遠端站臺時。
以下是實施基於策略的VPN的原因:
·
當遠端VPN設備是一種非瞻博(non-Juniper)設備且每個遠端子網都需要單獨的SA時。
·
您正在實施撥號 VPN(dial-up
VPN)。
·
在VPN上的遠端站臺上只需要訪問一個子網或一個網路時。
在偵測決定要將哪些通信流量發送到隧道內，您需要的細微性(granularity)比路由所能提供的功能要多時(例如，您需要指定只有當通信來自特定來源才能通過隧道來進行通信時)。
注意: 我們建議您在需要在多個遠端站臺之間配置VPN時使用基於路由的VPN。基於路由的VPN允許在多個遠端站臺相互彼此之間進行路由；它更易於被配置、監控和故障排除。
當拓撲具有其他廠牌(third-party)的設備，並且每個遠端子網都需要單獨的SA時，請使用基於策略的VPN。
注意: 不支援在一對多VPN介面上配置 RIP 需求電路。
注意: 安全隧道(st0)介面同時只支援一個IPv4位址和一個IPv6位址。這適用於所有基於路由的VPN。st0介面不支援禁用選項(The
disable option)，也就是st0介面無法被禁用。
IPsec VPN
拓撲
以下是JUNOS
作業系統支援的部分IPsec VPN 拓撲：
l
網站到網站VPN—將組織中的兩個網站連接起來，並允許網站間安全通信。
l
集中星型VPN—在企業網路中將分支機搆連接到公司辦公室。還可以利用此拓撲通過經集線器發送資訊流來將末端連接起來。
l
遠端存取VPN—允許在家工作或差旅途中的用戶連接至公司辦公室及其資源。此拓撲有時稱為end-to-site
tunnel。
IPSec是如何工作的?
IPSec 涉及許多元件技術和加密方法。然而，IPSec
的操作可以分解為五主要步驟:
1.
"有趣的流量interesting
traffic " 啟動 IPSec
進程。當 ipsec 對等方中配置的 ipsec
安全性原則啟動 IKE 進程時，通信被認為是有趣的。
2.
IKE
階段1。IKE (Internet Key Exchange)在這一階段對ipsec對等方進行身份驗證並協商IKE SA (ISAKMP SA)，為在階段2中協商的ipsec sa建立一個秘密頻道，簡單的說Phase 1 的工作就是為 Phase 2 準備一條加密管道，讓 Phase 2 用這條管道去交換資訊。
3.
IKE
階段2。IKE 協商 ipsec SA 參數，並在對等方中設置匹配的 ipsec sa。
4.
資料傳輸。根據存儲在 SA 資料庫中的 ipsec 參數和金鑰，在 ipsec 對等方之間傳輸資料。
5.
IPSec
隧道終止。IPSec SA
通過刪除或超時來終止。
IPsec 連接的建立在兩個階段發生，稱為
IKE 階段:
步驟 2-IKE
階段1(IKE Phase 1)
IKE 階段1的基本目的是對 IPSec 對等方進行身份驗證，並在對等方之間設置秘密頻道以啟用 IKE
交換。
什麼是身份驗證呢？很簡單，我是 Site A
的 Router，您說您是 Site B
的 Router 想和我建立
VPN，我怎知道您真的是 Site B 而不是其他公司呢？其中一個常用的方法是用 Share Secret 來認證，即是說 Site A 和 Site B 的 Router
都知道同一組密碼，證明是自己人，就通過認證了。
另外，Phase 1 還會用透過 Diffie-Hellman 來建立一組 Key，這組 Key 是用來為 Phase 2 的資訊進行加密。
ike 階段1建立了一個
ISAKMP SA (通常稱為 ike sa)。如果 IKE
階段1協商成功，則建立 ISAKMP
SA。ISAKMP SA 實質上包含了協商的
"中標方案" 中的資訊，記錄了成功協商的安全加密和金鑰材料。這將創建一個安全的 "控制通道"，其中保留了用於保護2階段協商的金鑰和其他資訊。ISAKMP SA 只加密階段 2 ESP SA協商，以及兩個端點之間的任何 IKE 消息。
以下敘述為原廠 "ScreenOS參考指南"
中節錄下來的內容：
階段
1
「自動金鑰 IKE」通道交涉的「階段
1」由如何驗證和保護通道的提議(Proposal)交換組成。
交換可以在兩種模式的其中一種中進行:
挑釁式模式或主要模式。使用任一種模式時，參與者會交換可接受的安全性服務提議，例如:
加密演算法 (DES
和
3DES)
和驗證演算法
(MD5
和
SHA-1)。
Diffie-Hellman
群組。
預先共用金鑰或
RSA/DSA
認證。
當通道的兩端都同意接受所提出的至少一組「階段
1」安全參數，並處理參數時，就結束一個成功的「階段
1」交涉。Juniper
Networks 安全性裝置最多支援四個「階段
1」交涉的提議(Proposal)，讓您可以定義對一系列安全性參數的限制程度，以便接受金鑰交涉。
ScreenOS(Netscreen、SSG系列) 提供的預先定義「階段
1」提議如下(在JUNOS上也相同)：
標準:
pre-g2-aes128-sha
和 pre-g2-3des-sha
相容:
pre-g2-3des-sha、pre-g2-3des-md5、pre-g2-des-sha
和 pre-g2-des-md5
基本:
pre-g1-des-sha
和 pre-g1-des-md5
也可以定義自訂的「階段
1」提議。
ps：從上述內容我們可以看出，預先定義的提議"標準"加密演算法使用aes128-sha，而"相容"則不包含aes128-sha(某些網路設備不支援)，可是為了安全上的考量，所以需要四組提議才行。
而JUNOS(SRX、J系列)除了上述三種ScreenOS預先定義的「階段
1」提議之外，還另外多了四種預先定義的「階段
1」提議，全部列示如下：
proposal-set (standard | compatible | basic |
prime-128 | prime-256 | suiteb-gcm-128 | suiteb-gcm-256)；
主要模式和挑釁式模式
「階段 1」可能發生在主要模式或挑釁式模式中。這兩種模式的描述如下。
主要模式(Main Mode):
初始程式和接受方傳送三個雙向交換
(
總共六條訊息)
以完成下列服務:
第一次交換 (
訊息
1
和
2):
提議並接受加密和驗證演算法。
第二次交換 (
訊息
3
和
4):
執行
Diffie-Hellman
交換，初始程式和接受方各提供一個偽隨機號碼。
第三次交換 (
訊息
5
和
6):
傳送並確認身份。
在第三次交換訊息時傳輸的資訊由在前兩次交換中建立的加密演算法保護。因此，在純文字中沒有傳輸參與者的身份。
挑釁式模式(Aggressive Mode):
又稱做挑戰模式，初始程式和接受方到達相同的物件，但僅進行兩次交換，總共有三條訊息:
第 1
條訊息:
初始程式提議
SA、初始化 Diffie-Hellman
交換，並傳送一個偽隨機號碼及其
IKE
身份。
第 2
條訊息:
接受方接受
SA、驗證初始程式，並傳送一個偽隨機號碼及其
IKE身份，以及傳送接受方的認證
(
如果使用認證)。
第 3
條訊息:
初始程式驗證接受方、確認交換，並傳送初始程式的認證
(如果使用認證)。
由於參與者的身份是在純文字中交換的
(
在前兩條訊息中)，所以挑釁式模式不提供身份保護。
注意:
當撥接 VPN
使用者使用預先定義的金鑰交涉「自動金鑰 IKE」通道時，必需使用挑釁式模式。也請注意撥接 VPN
使用者也可以使用電子郵件位址、完全合格的網功能變數名稱稱 (FQDN)
或
IP
位址作為其
IKE
ID。動態對等方可以使用電子郵件位址或FQDN，但不可以使用
IP
位址。
Diffie-Hellman
交換
Diffie-Hellman
(DH) 交換允許參與者產生一個共用的秘密值。該技術的優點在於它允許參與者在未保全的媒體上建立秘密值，而不把此秘密值透過網線傳遞。有五個Diffie-Hellman
群組；ScreenOS
支援群組
1、2
和
5。在各群組的計算中所使用主要模數的大小都有差異，如下所述:
DH
群組
1:
768
位元模數
DH
群組
2:
1024
位元模數
DH
群組
5:
1536
位元模數
注意:
「DH
組
1」安全性的強度已經降低，我們不建議使用。一般認為模數越大，產生的金鑰就越安全；但是，模數越大，金鑰產生過程就越長。由於每個 DH
群組的模數大小都不同，因此參與者必需同意使用相同的群組。
注意:
如果組態多個
(
最多四個)
「階段
1」交涉提議(Proposals)，請在所有的提議中使用相同的Diffie-Hellman
群組。同樣的準則可套用到「階段
2」交涉的多個提議。
而Juniper SRX (Junos OS)支援的Diffie-Hellman群組較多，總共以下七組：
l
DH Group 1—768-bit modulus
l
DH Group 2—1024-bit modulus
l
DH Group 5—1536-bit modulus
l
DH Group 14—2048-bit modulus
l
DH Group 19—256-bit modulus elliptic
curve
l
DH Group 20—384-bit modulus elliptic
curve
l
DH Group 24—2048-bit modulus with 256-bit
prime order subgroup
注意:
如我們不建議使用DH groups 1、2、5，因為它的安全性的強度已經降低。
步驟 3-IKE
階段2(IKE Phase 2)
IKE 階段2的目的是協商
ipsec SA 以設置 ipsec 隧道。
在 IKE 階段2中，兩個端點使用在1階段中創建的安全隧道來協商 ESP sa。ESP SA
是用來對兩個端點之間傳遞的實際使用者資料進行加密的。
ike 階段2的協商也由
ike 協定管理。使用SA提供的加密，安全性原則用於嘗試和協商階段2
SA。安全性原則包括有關通信主機和子網的資訊，以及用於為連接提供安全服務的 ESP
資訊，如加密密碼和雜湊演算法。如果 IKE 階段2協商過程成功，則會在兩個端點之間建立一對 ESP SA
(通常稱為 IPsec sa)，即一個入站和一個出站。這是兩個端點之間的加密 VPN "隧道"。此時，使用者資料可以通過加密的隧道進行交換。
以下敘述為原廠"ScreenOS參考指南"
中節錄下來的內容：
階段
2
當參與者建立了一個已驗證的秘密頻道後，會繼續執行「階段
2」，在此階段中，他們將交涉 SA 以保護要透過 IPSec
通道傳輸的資料。
與「階段 1」的過程相似，參與者交換提議以確定要在 SA 中應用的安全參數。
「階段 2」提議也包括一個安全性通訊協定
(「封裝安全性負載
(ESP)」或「驗證標頭
(AH)」)
和選擇的加密和驗證演算法。如果需要「完美轉送安全性
(PFS)」，提議中還可以指定一個
Diffie-Hellman
群組。
不管在「階段 1」中使用何種模式，「階段
2」總是在「快速」模式中執行，並且包括三條訊息的交換。
Juniper
Networks 安全性裝置最多支援四個「階段
2」交涉的提議，讓您可以定義對一系列通道參數的限制程度，以便接受它們。ScreenOS
也提供重播保護功能。
使用此功能不需要交涉，因為封包一定會和序號一起傳送。您只能選擇要不要檢查序號。(
有關重播保護的詳細資訊，請參閱第10
頁上的「重播保護」。)
ScreenOS
提供的預先定義「階段
2」提議如下(在JUNOS上也相同):
l
標準:
g2-esp-3des-sha
和 g2-esp-aes128-sha
l
相容:
nopfs-esp-3des-sha、nopfs-esp-3des-md5、nopfs-esp-des-sha
和nopfs-esp-des-md5
l
基本:
nopfs-esp-des-sha
和 nopfs-esp-des-md5
我們也可以定義自訂的「階段
2」提議。
ps：從上述內容我們可以看出，預先定義的提議"標準"包含有DH Group，而"相容"則不包含DH Group(某些網路設備不支援)，可是為了安全上的考量，所以需要四組提議才行。
而Juniper JUNOS除了上述三種預先定義「階段
2」提議之外，還有其他四種預先定義的「階段
2」提議，全部列示如下：
proposal-set (standard | compatible | basic |
prime-128 | prime-256 | suiteb-gcm-128 | suiteb-gcm-256)；
Proxy IDs
在「階段 2」中，對等方也交換 proxy
ID。proxy ID
是一個三部份組合，由本機 IP位址、遠端 IP
位址和服務組成。兩個對等方的
proxy ID
必需配對，這意味著兩個對等方的
proxy ID
中指定的服務必需相同，並且為一個對等方指定的本機
IP
位址必需與為另一個對等方指定的遠端
IP
位址相同。
完美轉送安全性(PFS - Perfect Forward
Secrecy)
「完美轉送安全性
(PFS)」是一種用於衍生「階段
2」金鑰的方法，與前述金鑰無關。此外，「階段 1」提議會建立金鑰 (SKEYID_d
金鑰)，從其中將衍生所有的「階段
2」金鑰。SKEYID_d
金鑰可以用最低的 CPU
處理產生「階段
2」金鑰。
不巧的是，如果某個未授權方得到
SKEYID_d
金鑰的存取權，將洩漏所有的加密金鑰。
PFS
透過對每個「階段 2」通道強制產生新的
Diffie-Hellman
金鑰交換來解決此安全風險。雖然在啟用 PFS
後，「階段
2」中的重新建立金鑰過程可能需要稍微更長的時間，但使用 PFS
比較安全。
重播保護(Replay Protection)
當有人截取一系列封包並稍後使用封包大量攻擊系統、導致服務中斷 (DoS)
或進入受信任的網路時會發生重播攻擊。重播保護功能會讓安全性裝置檢查每一個
IPSec封包，以檢視以前是否接收過此封包。如果封包到達時在指定的序列範圍外，安全性裝置會拒絕封包。
步驟 4-IPSec
加密隧道
IKE 階段2完成後，快速模式建立了 ipsec sa，資訊通過 ipsec 隧道進行交換。使用 IPSec SA 中指定的加密對資料包進行加密和解密。
通常配置VPN的前提有兩個：
一、兩端的設備都能夠分別訪問到遠端的外網介面。
最簡單的方式就是PING遠端的外網介面，若對方關閉了對PING回應的功能，則只能在連線時根據LOG紀錄來判斷了。
二、對於IPSec的VPN而言，兩端設備之間的防火牆要開放讓UDP埠為500的資料包通過。
vpn會使用到的port numbers
l
網際網路安全協定（IPSec - Internet Protocol
Security）：
使用IP協議50(IP protocol 50)用於封裝安全協議（ESP -
Encapsulated Security Protocol），IP協議51用於認證頭（AH - Authentication Header），以及UDP端口500用於IKE階段1協商和階段2協商。如果NAT-T用於IKE階段1協商和階段2協商，則使用UDP端口500和4500
l
安全通訊協定（SSL - Secure Sockets
Layer）：
使用TCP端口443，並通過使用私鑰來加密通過SSL連接傳輸的數據。
SSL還使用465安全SMTP，993安全IMAP和995安全POP。
l
第二層隧道協議（L2TP -
Layer Two Tunneling
Protocol）： 使用TCP端口1701，是點對點隧道協議的擴展。 L2TP通常與IPSec一起用於建立虛擬專用網絡（VPN）。
l
點對點隧道協議（PPTP -
Point-to-Point
Tunneling Protocol）： 使用TCP端口1723和IP端口47通用路由封裝（GRE）。
PPTP通過Internet提供與企業網絡的低成本私有連接。
PPTP適用於在家或旅行中工作並需要訪問其公司網絡的人員。它通常用於訪問Microsoft遠程訪問服務器（RAS）
上述內容為各種vpn會使用到的port numbers，其中關於L2TP的部分要補充說明，由於L2TP 協定使用時常常會跟IPSec一起使用(L2TP Over
IPSec)，所以我們就要將L2TP的Ports與IPSec的Ports一併開放才行。
在我們開始設定VPN之前，請先讓兩端設備做好網路對時的作業，以避免兩台設備的LOG日誌記錄產生時間差的問題，這樣會增加除錯的困擾。
而點到點的vpn設置一般分為二種情況：
一、兩端都有固定的IP位址(通常我們所討論的就是這種)。
二、一端是固定的IP位址，另一端則為動態的IP位址(這種就是所謂的Dynamic
VPN)。
以下我們根據第一種情況來對Route-Based VPN做設定上的說明：
下圖為VPN設定拓樸圖：
JUNOS OS 基於路由VPN設定範例
為內網界面、外網界面以及VPN安全通道(st0)介面設定IP位址
set
interfaces ge-0/0/0 unit 0 family inet address
172.16.200.11/24
set
interfaces vlan unit 0 family inet address
192.168.1.1/30
set
interfaces st0 unit 0 family inet address 10.11.11 .11/24
一般一對一的vpn通道可以不需要指定ip位元元址，所以我們可以將vpn通道設定成unnumbered(當然您想要設定ip位址也是可以的)；您可以在CLI命令列如此設定：
set
interfaces st0 unit 0 family inet
但是若使用一對多的vpn通道，例如NHTB
VPN的設定，我們就必須要幫st0.0通道設定ip位址了，這樣我們才能將網路流量明確的送達不同目的地。
設定預設路由以及VPN通道路由
set
routing-options static route 0.0.0 .0/0
next-hop 172.16.200.253
set
routing-options static route 192.168.2.0/24 next-hop
st0.0
在路由表中明確指明要去192.168.2.0/24網段必須走VPN通道之st0.0介面。
路由表(Routing
Table)：存放了許多網段資訊或是主機ip位址等資訊，這些資訊會告訴您您要去的主機要經由哪個介面，介面下一個節點的ip為何?而您能快速正確的找到目的主機，可以說是因為路由表設定正確的原因。若路由表設錯，則您就無法與其他電腦連線溝通了。而如果路由表中沒有我們要訪問的主機資訊，我們又該怎麼辦?通常我們可以這麼做：
set
routing-options static route 0.0.0 .0/0
next-hop 172.16.200.253
其中0.0.0 .0/0代表的是所有的ip，而這個命令代表的意思是：所有沒有在路由表中找到目的路由資訊的流量，通通送往wan介面，並傳送到下一個躍點172.16.200.253。這就表示尋找目的主機路由資訊的工作轉交給下一台連接的網路設備了(172.16.200.253)。而若始終沒有找到，就會導致愈時而無法連線。
設定安全區以及將介面綁定到安全區上
set
security zones security-zone trust interfaces vlan.0
set
security zones security-zone untrust interfaces
ge-0/0/0.0
set
security zones security-zone vpn interfaces st0.0
不同的介面有不同的用途，VPN通道在SSG與NETSCREEN系列的ScreenOS使用tunnel介面，而在SRX或是J系列的JUNOS則使用st0介面，第一個VPN通道為st0.0，第二個VPN通道為st0.1，以此類推，當然，您也可以直接將VPN通道設定成st0.168等等，而tunnel介面也相同。
關於將vpn通道(st0.0)加入到安全區(zone)，我們在網路上可以看到幾種不同的方式：
◎將st0.0通道加入vpn區域
這是我們在這裡所採用的標準的做法：單獨創建一個vpn安全區然後將st0.0通道加入。這是較為安全與易於管理的一種方式。對vpn區域所做的設定只會影響到vpn通道，若是策略(policy)不開放，則無法跟其他安全區溝通。
◎將st0.0通道加入untrust區域
設定較為簡單些，但是由於untrust區域通常還有wan介面存在，並且為不信任區域，對untrust區域所做的設定會同時影響到wan介面以及vpn通道，這會增加管理上以及安全上的負擔，所以另外建立一個vpn
zone來提供給vpn通道使用是易於管理、且較為安全的方式，故個人強烈建議大家必須另外建立一個vpn
zone來提供給vpn通道使用。
◎將st0.0通道加入trust區域
這是我們在做vpn測試時的一種取巧的方法，而這麼做又有甚麼好處呢?
由於vpn通道與本地網段都綁定在trust區域之中，而同一個區域內是可以彼此任意互相訪問的，也就是在複雜環境測試時我們可以忽略策略(policy)設定方面的因素，而能專注在vpn通道連線的部分，一旦測試成功後，我們再將vpn通道之設定套用在標準做法上，但將st0.0通道加入trust
zone是非常不安全的做法，除了測試用途之外，請勿這麼做!
為每個安全區設定host-inbound-traffic
set
security zones security-zone trust host-inbound-traffic system-services
all
set
security zones security-zone untrust host-inbound-traffic system-services
ike
host-inbound-traffic乃是管制開放允許進入安全區內的系統服務(system-services)流量。
另一個管制進入安全區內的流量的方法是透過設定安全策略(policy)來達成。
要查詢有哪些系統服務可開放，我們可以輸入下列的命令：
set
security zones security-zone untrust host-inbound-traffic system-services
?
trust
zone為內部區域，在防火牆之內，所以通常開放所有的服務進入，除非是像研發部門或是財務部門等高安全需求單位才需要個別管制。
Untrust
zone則為外部區域，會跟外網有實體接觸，所以只開放必要的服務即可，例如ike服務(vpn協商傳輸用)。
為每個安全區設定地址集區
set
security zones security-zone trust address-book address local-net
192.168.1.0/24
set
security zones security-zone vpn address-book address remote-net
192.168.2.0/24
建立本地端與遠端主機或網段的地址集區，並分別綁定在各自所屬之安全區，地址集區會在策略設定中使用到。
設定IKE策略參數成主要模式、使用標準的預先定義提案、和設定預先共享金鑰
set
security ike policy ike-phase1-policy mode main
set
security ike policy ike-phase1-policy proposal-set
standard
set
security ike policy ike-phase1-policy pre-shared-key ascii-text
"JUNIPER"
其內容包含，設定主要模式， Preshare Key與Phase 1提案proposal。
Preshare
Key在這裡我們使用"JUNIPER"方便測試使用，但我們可以改得更複雜些，以提高安全性，最重要的是：Preshare
Key與Phase 1 proposal的設定是要跟對端設備的設定完全相同的。
關於階段一的訊息協商分成主要模式或挑釁式模式：一般我們設定vpn都是選擇主要模式。當撥接 VPN
使用者使用預先定義的金鑰交涉「自動金鑰 IKE」通道時，就必需要使用挑釁式模式，由於參與者的身份是在純文字中交換的(未經加密程序)，所以挑釁式模式不提供身份保護。
設定階段一IKE遠端閘道IP地址、套用的IKE策略、以及聯外界面
set
security ike gateway ike-phase1-gateway ike-policy
ike-phase1-policy
set
security ike gateway ike-phase1-gateway address
172.16.200.12
set
security ike gateway ike-phase1-gateway external-interface
fe-0/0/0.0
其內容包含設定閘道名稱，指定套用的IKE策略，設定遠端閘道IP地址，好讓設備知道要跟誰建立vpn通道；以及設定本地聯外介面。
設定IPsec策略參數使用預先定義的標準提案組合
set
security ipsec policy ipsec-phase2-policy proposal-set
standard
Phase2 proposal的設定必須跟對端設備的設定相同，而關於proposal的內容後面會說明。
我們可以使用下列命令來查詢有哪些提案可用：
set
security ipsec policy ipsec-phase2-policy proposal-set
?
設定IPSec
VPN
set
security ipsec vpn To-Site_B-vpn ike gateway ike-phase1-gateway
set
security ipsec vpn To-Site_B-vpn ike ipsec-policy ipsec-phase2-policy
set
security ipsec vpn To-Site_B-vpn bind-interface st0.0
set
security ipsec vpn To-Site_B-vpn establish-tunnels immediately
set
security ipsec vpn To-Site_B-vpn ike proxy-identity local 192.168.1.0/24 remote 192.168.2.0/24
其內容包含連結IKE閘道和策略，綁定vpn通道介面，以及設定proxy-id。
每個vpn都必須綁定一個通道(tunnel)。
proxy ID
是一個三部份組合，由本機 IP位址、遠端 IP
位址和服務組成。兩個對等方的
proxy ID
必需配對，兩個對等方的
proxy ID
中指定的服務也必需相同，並且本機
IP
位址必需與遠端vpn設備指定的遠端IP位址相同。
而又有哪些流量可以通過VPN通道呢?
在route-based VPN之中網路流量除了受到策略(POLICY)的控制之外，您還必須在靜態路由表中指定流量傳輸路徑，以及在VPN兩端VPN PROXY之中分別表列出近端與遠端要相互溝通端網段資料，三者缺一不可。也就是說當您的vpn通道建立起來後(ike phase1、phase2協議成功)，而您卻無法跟vpn遠端網段溝通，那您就必須檢查上述三者的設定是否正確。這也就說明瞭到底有哪些流量能夠使用vpn通道了。
IPSec
VPN的進階設定
set
security ike gateway ike-phase1-gateway dead-peer-detection optimized
set
security ike gateway ike-phase1-gateway dead-peer-detection interval 10
set
security ike gateway ike-phase1-gateway dead-peer-detection threshold 5
dead-peer-detection會在ike-phase1階段發出回應請求，以確認對端設備存在。
Optimized選項讓dead-peer-detection只會在我方有通訊流量，對方沒有通訊流量時才動作發出回應請求。
Interval
10 選項表示每10秒發送一次(預設值)dead-peer-detection請求。
Threshold 5
選項表示當連續五次發送dead-peer-detection請求都失敗時，判定對方斷線，並清除與對方建立的階段一與階段二SA。
set
security ipsec vpn To-Site_B-vpn vpn-monitor optimized
set
security ipsec vpn-monitor-options interval 10
set
security ipsec vpn-monitor-options threshold 10
vpn-monitor會在ipsec-phase2階段發出icmp請求，以確認對端設備存在。
Optimized選項讓vpn-monitor只會在我方有通訊流量，對方沒有通訊流量時才動作發出icmp請求。
Interval
10 (間隔)選項表示每10秒發送一次(預設值) icmp請求。
Threshold 10
(臨界值)選項表示當連續10次發送icmp請求都失敗時，判定對方斷線，並清除與對方建立的SA。
為VPN通道設定雙向的交通安全策略
edit
security policies from-zone trust to-zone vpn
set
policy trust-to-vpn match source-address local-net
set
policy trust-to-vpn match destination-address
remote-net
set
policy trust-to-vpn match application any
set
policy trust-to-vpn then permit
exit
edit
security policies from-zone vpn to-zone trust
set
policy vpn-to-trust match source-address remote-net
set
policy vpn-to-trust match destination-address
local-net
set
policy vpn-to-trust match application any
set
policy vpn-to-trust then permit
exit
因為預設策略(default policy)預設為全部拒絕(deny
all)，也就是沒有被允許的通通會被禁止通行，所以我們就要為vpn通道建立允許雙向互通的策略(policy)。而建立地址簿則可讓策略設定更簡潔、易懂、明瞭與容易維護。
policy的命令說明：凡是本地端網段local-net
192.168.2.0/24要從trust安全區到vpn安全區去訪問vpn遠端的網段remote-net
192.168.1.0/24的網路流量，一律允許。從vpn安全區到trust安全區的網路流量也類推。
為網際網路流量設定安全策略
edit
security policies from-zone trust to-zone untrust
set
policy trust-to-untrust match source-address any
set
policy trust-to-untrust match destination-address any
set
policy trust-to-untrust match application any
set
policy trust-to-untrust then permit source-nat
interface
exit
設定開放內網可以任意訪問外網的安全策略，這也是出廠預設配置中唯一的一條安全策略。
設定Tcp-mss來避免通過VPN通道的TCP流量產生數據包分段(Fragmentation)
set
security flow tcp-mss ipsec-vpn mss 1350
TCP-MSS，全稱TCP maximum segment
size。翻譯過來是TCP最大報文尺寸。它的值代表TCP傳輸層期望對端發送給自己單個TCP報文的最大尺寸。
通俗來說，當TCP協議兩端在初始協商進行TCP三次握手協定的時候，主機兩端會把自己當前所在鏈路的MSS值告知對方。當一端主機收到另外一端的MSS值候，它會評估其MSS值並與自己的MSS值做對比，取最小的值來決定TCP發送的最大報文尺寸。
如何計算本地MSS值？
本地MSS=MTU-20位元組的標準IP頭-20位元組的標準TCP頭（換個角度看其實就是TCP負載）
TCP-MSS
作為TCP 三方握手的一部分進行協商，限制TCP
片段的最大大小以更好地匹配網路中的MTU 限制。
對於VPN 資訊流，IPsec 封裝開銷與IP
和幀開銷可導致生成的ESP
資料包超出物理介面的MTU，從而導致分段。分段會造成頻寬浪費和增加設備資源開銷。
注意: 對於大多數MTU 為1500 或以上、基於乙太網的網路，建議使用1350 作為起點。可能需要嘗試不同的TCP-MSS
值來獲取最佳性能。例如，如果路徑中的任何設備具有較低的MUT，或者如果存在其他開銷（如PPP 或框架轉送），則可能需要更改相關值。
root@srx100# set
security flow tcp-mss ?
Possible
completions:
> all-tcp
Enable MSS override for all
packets
+ apply-groups Groups from which to inherit configuration
data
+ apply-groups-except Don't inherit
configuration data from these groups
> gre-in
Enable MSS override for all GRE packets coming out of an IPSec
tunnel
> gre-out
Enable MSS override for all GRE packets entering an Ipsec
tunnel
> ipsec-vpn
Enable MSS override for all packets entering IPSec
tunnel
[edit]
root@srx100#
關於介面的MTU數值
以下這條命令非必要(因為已經設定了tcp-mss)，只是用來說明其觀念與用途而已。SRX
st0.0通道預設mtu 9192，而SSG5
tunnel.1通道預設mtu 1500，所以當兩者互相建立vpn通道成功時，您會發現從SRX到SSG5的流量是正常的，而從SSG5到SRX的流量則是不通，原因是當對方的mtu小於您時，您能接受，但是當對方的mtu大於您時，您就無法接受了。所以當SRX設備與非JUNOS設備建立vpn通道時，建議要加上這條命令，而若能清楚知道對端設備的mtu值，那就更完美了。
set
interfaces st0 unit 0 family inet mtu 1500
(SRX的設定命令)
set
interface tunnel.1 mtu 1500
(SSG的設定命令)
SSG5-serial->
set
interface tunnel.1 mtu ?
<number> mtu size，<1280-1500>
SSG5-serial->
關於MTU方面相關的資料，請參考下列的網路連結：
IMPORTANT NOTE: This
tool does not perform error checking against your existing
configuration.
If a misspelled or
incorrect zone，interface
or network address is specified，it may
report errors when youcopy the configuration onto your
device
## Begin
- VPN Configuration Generator Output
##
Interface IP and route for tunnel traffic
set
interfaces st0.0 family inet address 10.2.2 .2/24
set
routing-options static route 192.168.12.0/24 next-hop
st0.0
##
Security zones，assign
interfaces to the zones & host-inbound services for
each zone
set security
zones security-zone VPN interfaces st0.0
set security
zones security-zone imtrist host-inbound-traffic system-services
ike
##
Address book entries for each zone
set security
zones security-zone trust address-book address net-cfgr_192-168-11-0--24
192.168.11.0/24
set security
zones security-zone VPN address-book address net-cfgr_192-168-12-0--24
192.168.12.0/24
## IKE
policy
set security
ike policy ike-policy-cfgr mode main
set security
ike policy ike-policy-cfgr pre-shared-key ascii-text
"SRX100"
## IKE
gateway with peer IP address，IKE
policy and outgoing interface
set security
ike gateway ike-gate-cfgr ike-policy ike-policy-cfgr
set security
ike gateway ike-gate-cfgr address 2.2.2 .2
set security
ike gateway ike-gate-cfgr external-interface
fe-0/0/0.0
set security
ike gateway ike-gate-cfgr version v1-only
## IKE
authentication，encryption，DH
group，and
Lifetime
set security
ike proposal ike-proposal-cfgr authentication-method
pre-shared-keys
set security
ike policy ike-policy-cfgr proposals
ike-proposal-cfgr
set security
ike proposal ike-proposal-cfgr encryption-algorithm
3des-cbc
set security
ike proposal ike-proposal-cfgr authentication-algorithm
sha-256
set security
ike proposal ike-proposal-cfgr dh-group group19
set security
ike proposal ike-proposal-cfgr lifetime-seconds
3600
## IPsec
policy
set security
ipsec policy ipsec-policy-cfgr proposal-set
userDefined
## IPsec
vpn
set security
ipsec vpn ipsec-vpn-cfgr ike gateway ike-gate-cfgr
set security
ipsec vpn ipsec-vpn-cfgr ike ipsec-policy
ipsec-policy-cfgr
set security
ipsec vpn ipsec-vpn-cfgr bind-interface st0.0
##
Advance Settings
set security
ipsec vpn ipsec-vpn-cfgr vpn-monitor optimized
set security
ipsec vpn-monitor-options interval 10
set security
ipsec vpn-monitor-options threshold 10
set security
ike gateway ike-gate-cfgr dead-peer-detection
optimized
set security
ike gateway ike-gate-cfgr dead-peer-detection interval
10
set security
ike gateway ike-gate-cfgr dead-peer-detection threshold
5
set security
ipsec vpn ipsec-vpn-cfgr establish-tunnels
immediately
set security
ipsec vpn ipsec-vpn-cfgr ike proxy-identity local 192.168.11.0/24 remote
192.168.12.0/24
## IPsec
authentication and encryption
set security
ipsec proposal ipsec-proposal-cfgr protocol esp
set security
ipsec policy ipsec-policy-cfgr proposals
ipsec-proposal-cfgr
set security
ipsec policy ipsec-policy-cfgr perfect-forward-secrecy keys
group19
set security
ipsec proposal ipsec-proposal-cfgr encryption-algorithm
aes-256-cbc
set security
ipsec proposal ipsec-proposal-cfgr authentication-algorithm
hmac-sha-256-128
set security
ipsec proposal ipsec-proposal-cfgr lifetime-seconds
3600
##
Security policies for tunnel traffic in outbound direction
set security
policies from-zone trust to-zone VPN policy trust-VPN-cfgr match
source-address net-cfgr_192-168-11-0--24
set security
policies from-zone trust to-zone VPN policy trust-VPN-cfgr match
destination-address net-cfgr_192-168-12-0--24
set security
policies from-zone trust to-zone VPN policy trust-VPN-cfgr match
application any
set security
policies from-zone trust to-zone VPN policy trust-VPN-cfgr then
permit
##
Security policies for tunnel traffic in inbound direction
set security
policies from-zone VPN to-zone trust policy VPN-trust-cfgr match
source-address net-cfgr_192-168-12-0--24
set security
policies from-zone VPN to-zone trust policy VPN-trust-cfgr match
destination-address net-cfgr_192-168-11-0--24
set security
policies from-zone VPN to-zone trust policy VPN-trust-cfgr match
application any
set security
policies from-zone VPN to-zone trust policy VPN-trust-cfgr then
permit
## End -
VPN Configuration Generator Output
Copy and
paste the output above onto your SRX series or J Series device in configuration
mode.
IMPORTANT
NOTE: This tool does not perform error checking against your existing
configuration.
If a
misspelled or incorrect zone，interface
or network address is specified，it may
report errors when you copy the configuration onto your device
以下敘述為原廠ScreenOS參考指南
中節錄下來的關於加密選項的內容：
站臺到站臺加密選項
組態基本的站臺到站臺
VPN
通道時，在圖19
中所示的加密選項中進行選擇。圖後會介紹每個選項的優點。
1.
金鑰方法:
自動金鑰(AutoKey
IKE)或手動金鑰(Manual
Key)?
自動金鑰 IKE
◎建議
◎提供自動金鑰更新和金鑰重新整理，因而增強了安全性
手動金鑰
◎用於除錯 IKE
◎消除建立通道時的
IKE
交涉延遲
2.
模式：挑釁式模式或主要模式?
挑釁式模式Aggressive
動態分配其中一個
IPSec
對等方的
IP
位址及使用預先共用金鑰時，需使用此模式
主要模式Main
◎建議
◎提供身份保護
◎撥接使用者擁有靜態
IP
位址時或如果認證用於驗證時，可以使用此模式
3.
驗證類型：預先共用金鑰或認證?
認證Certificates
◎建議
◎由於可以驗證具有認證授權機構
(CA-certificate authority)
的認證，因此提供比預先共用金鑰更高的安全級別。
預先共用的金鑰
由於不需要「公開金鑰基礎結構」(PKI)，因此使用更方便，設定更快速
4.
認證類型：RSA
或
DSA?
具體取決於從其獲得認證的
CA。兩種認證類型沒有優點。
5.
位元長度：512
或
768
或
1024
或
2048?
512位元
使處理開支最少
768位元
◎提供比 512
位元更高的安全等級
◎使處理開支比 1024
和
2048
位元的更少
1024位元
◎建議
◎提供比 512
和
768
位元更高的安全等級
◎使處理開支比 2048
位元的更少
2048位元
提供最高的安全等級
6.
IKE Diffie-Hellman 群組:
1 或
2
或
5?
Diffie-Hellman
群組 1
◎使處理開支比 Diffie-Hellman
群組
2
和
5
的更少
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
Diffie-Hellman
Group 2
◎建議
◎使處理開支比 Diffie-Hellman
群組
5
的更少
◎提供比 Diffie-Hellman
群組
1
更高的安全等級
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
Diffie-Hellman
群組 5
提供最高的安全等級
7.
IKE 加密和
Auth
演算法:
AES 或
DES
或
3DES
及
MD5
或
SHA-1?
AES
◎建議
◎如果金鑰長度全部相等，則比 DES
和
3DES
的加密性更強
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
◎用於「聯邦資訊處理標準」(FIPS)
和「通用準則
EAL4」標準的經核准加密演演算法
DES
◎使處理開支比 3DES
和
AES
的更少
◎在遠端對等方不支援
AES
時非常有用
3DES
◎提供比 DES
更高的加密安全等級
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
MD5
使處理開支比 SHA-1
的更少
SHA-1
◎建議
◎提供比 MD5
更高的加密安全等級
◎FIPS
接受的唯一驗證演算法
8.
本機
IKE
ID：IP
位址
(
預設)
或
U-FQDN
或
FQDN
或
ASN1-DN?
IP
Address
◎建議
◎本機安全性裝置具有靜態
IP
位址時才能使用
◎使用預先共用金鑰驗證時的預設 IKE
ID
◎如果 IP
位址出現在
SubjectAltName
欄位中，則可與認證配合使用
U-FQDN
使用者完全合格的網功能變數名稱稱 (U-FQDN -
電子郵件位址):
如果
U-FQDN
出現在SubjectAltName
欄位中，則可與預先共用金鑰或認證配合使用FQDN
◎完全合格的網功能變數名稱稱 (FQDN):
如果
FQDN
出現在
SubjectAltName
欄位中，則可與預先共用金鑰或認證配合使用
◎對於具有動態 IP
位址的
VPN
閘道很有用
◎使用 RSA
或
DSA
認證驗證時的預設
IKE
ID
ASN1-DN
◎只能與認證配合使用
◎在 CA
不支援其發佈的認證中的
SubjectAltName
欄位時很有用
9.
遠端
IKE
ID：IP
位址
(
預設)
或
U-FQDN
或
FQDN
或
ASN1-DN?
IP
Address
◎建議
◎使用預先共用金鑰驗證並且對等方是安全性裝置時，不需要輸入靜態 IP
位址處對等方的遠端 IKE
ID
◎可用於具有靜態
IP
位址的裝置
◎如果 IP
位址出現在
SubjectAltName
欄位中，則可與預先共用金鑰或認證配合使用
U-FQDN
使用者完全合格的網功能變數名稱稱 (U-FQDN -
電子郵件位址):
如果
U-FQDN
出現在SubjectAltName
欄位中，則可與預先共用金鑰或認證配合使用
FQDN
◎完全合格的網功能變數名稱稱 (FQDN):
如果
FQDN
出現在
SubjectAltName
欄位中，則可與預先共用金鑰或認證配合使用
◎對於具有動態 IP
位址的
VPN
閘道很有用
◎使用認證驗證並且對等方是安全性裝置時，不需要輸入遠端
IKE
ID
ASN1-DN
◎只能與認證配合使用
◎在 CA
不支援其發佈的認證中的
SubjectAltName
欄位時很有用
10.
反重播檢查(Anti-Replay
Checking)：否或是?
是
◎建議
◎允許收件人檢查封包標頭中的序號，以防止用心不良者重新傳送截取的 IPSec封包時導致的「服務中斷」(DoS)
攻擊
否
停用此項可能會解決與協力廠商對等方的相容性問題
11.
完美轉送安全性：否或是?
是
◎建議
◎完美轉送安全性
(PFS-Perfect
Forward Secrecy):
由於對等方執行第二個 Diffie-Hellman
交換生成用於IPSec
加密/
解密的金鑰，因此提供增強的安全性
否
◎提供更快的通道設定
◎使「階段 2」IPSec
交涉期間處理開支更少
12.
IPSec Diffie-Hellman 群組:
1 或
2
或
5?
Diffie-Hellman
群組 1
◎使處理開支比 Diffie-Hellman
群組
2
和
5
的更少
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
Diffie-Hellman
Group 2
◎建議
◎使處理開支比 Diffie-Hellman
群組
5
的更少
◎提供比 Diffie-Hellman
群組
1
更高的安全等級
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
Diffie-Hellman
群組 5
提供最高的安全等級
13.
IPSec 通訊協定:
ESP 或
AH?
ESP
(Encapsulating Security Payload)
◎建議
◎封裝安全性負載
(ESP):
透過加密和封裝原始
IP
封包可提供機密性，同時透過驗證提供完整性
◎可提供單獨加密或單獨驗證
AH
(AH-Authentication Header)
驗證標頭 (AH):
提供整個
IP
封包的驗證，包括
IPSec
標頭和外部
IP
標頭
14.
模式：通道模式或傳輸模式?
通道模式(Tunnel)
◎建議
◎由於隱藏了初始
IP
標頭，因此增加了私密性
傳輸模式(Transport)
對於 IPSec
上的
L2TP
通道支援，此模式是必需的
15.
ESP 選項:
加密
或 加密/Auth
或
Auth?
加密(Encrypt)
◎提供比使用加密/驗證
更快的效能並使處理開支更少
◎用於要求機密性但不要求驗證(authentication)的情況
Encrypt /Auth
(加密/驗證)
◎建議
◎用於需要機密性和驗證的情況
Auth
(驗證)
用於需要驗證但不要求機密性的情況。也許資訊不是保密時，但確定此資訊確實來自聲稱傳送它的人，以及在傳輸過程中沒有任何人篡改內容是很重要的。
16.
加密演算法：AES
或
DES
或
3DES?
AES
◎建議
◎如果金鑰長度全部相等，則比 DES
和
3DES
的加密性更強
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
◎用於 (FIPS)
和「通用準則
EAL4」標準的核准加密演算法
DES
◎使處理開支比 3DES
和
AES
的更少
◎在遠端對等方不支援
AES
時非常有用
3DES
◎提供比 DES
更高的加密安全等級
◎加快 Juniper
Networks 安全性硬體中提供的處理速度
17.
Auth 演算法：MD5
或
SHA-1?
MD5
使處理開支比 SHA-1
的更少
SHA-1
◎建議
◎提供比 MD5
更高的加密安全等級
使用上述清單中建議的選項，具有靜態
IP
位址的兩台安全性裝置間的通用站臺到站臺 VPN
組態將由以下元件組成:
以下連結為Juniper官方在SRX Junos方面關於VPN設定的相關網頁：
關於VPN整體概念方面：
關於VPN設定方面：
關於VPN問題排除方面：
