|
|
楼主 |
发表于 2019-4-26 10:17:48
|
显示全部楼层
Installation5 R! s2 `, }( j( Q, I' @! s! \. P
In order to use Neutron-VPNaaS with devstack (http://devstack.org) a single node setup, you'll need the following settings in your local.conf (NEW: neutron-vpnaas plugin is added).
7 C# y. ?9 X7 P% B# t, ^% D3 C. f' Y0 G3 W
[[local|localrc]]
" |0 q% h# m' u. l" T, z+ H& `1 h4 V O
enable_plugin neutron-vpnaas https://git.openstack.org/openstack/neutron-vpnaas4 f- d+ j9 c! I' v. G* J9 |
& }" h) w+ e& ^5 Udisable_service n-net
* M0 l( P% h" N* S9 Renable_service q-svc" Y2 G. t9 s" V: l2 i, d% o
enable_service q-agt. o3 }9 g8 m- O* }' k. _4 }8 d
enable_service q-dhcp- u( B0 @9 K+ G; r
enable_service q-l3' x0 [* A1 W' U- `) w# f: y3 t- D
enable_service q-meta5 x+ w- q- m: M
# Optional, to enable tempest configuration as part of devstack
/ g" j3 @. D5 P5 J- b! oenable_service tempest
" {& N- t5 `+ u( `" z, p: o& q4 P, `% S+ A" P3 j( o) v
# IPSec driver to use. Optional, defaults to OpenSwan.1 ?6 E' B5 h( u' b& ?4 Y9 \5 Q5 y2 l
IPSEC_PACKAGE="openswan"3 g. E0 A! p9 L0 R# @2 K! Q
Quick Test Script
- M6 M. y+ \$ u$ ^0 uhttp://paste.openstack.org/raw/44702/0 f2 k/ i5 L0 t. Z8 y3 I
; p( W! h3 J. s6 q0 E
This quick test script create two site with a router,a network and a subnet connected with public network. Then, connect both site via VPN.
+ [3 X3 a; O* H! l5 k
4 a% j3 g* u4 ~Using Two DevStack Nodes for Testing
! q) l' J# W9 `+ c4 TYou can use two DevStack nodes connected by a common "public" network to test VPNaaS. The second node can be set up with the same public network as the first node, except it will use a different gateway IP (and hence router IP). In this example, we'll assume we have two DevStack nodes (East and West), each running on hardware (you can do the same thing with multiple VM guests, if desired). (Note: you can also create similar topology using two virtual routers with one devstack)
' ]$ N2 `' B- ~9 z7 y. ~
, s; \3 R7 l1 N: }8 XExample Topology; ^' g) {2 y) A6 B% [* t
8 K/ i8 }1 F/ e$ X# _7 ]$ P1 I
A dedicated physical port can be used for the "public" network connection (e.g. eth2) interconnected by a physical switch. You'll need to add the port to the OVS bridge on each DevStack node (e.g. sudo ovs-vsctl add-port br-ex eth2).
0 a% s: t' y. A; O, s- C0 o% ]% V( u+ t( ^
(10.1.0.0/24 - DevStack East)
+ }' Q u- _2 j |8 n2 k/ `: U& x" ^
| 10.1.0.1' y2 a5 k# O& L+ _9 P: B8 r1 B" M
[Neutron Router]
$ h8 B4 \% l+ S4 _ | 172.24.4.226$ i6 G; i, w: Z
|6 \; |! l9 K4 ?4 F m
| 172.24.4.225' R8 U% w7 C1 y$ g# k, V, j, V
[Internet GW]4 e& I5 x, R7 h$ e2 @; \( @3 n
| ( o9 e8 T) \ j2 Y7 v
|
/ B- ~! @8 } I+ k# p# { [Internet GW]7 H" H8 }2 ^ w0 @) `
| 172.24.4.2321 l" U0 {0 V2 s2 ~# W& x H
|
; l' @1 b( [ Z1 D" O; c" n- C | 172.24.4.233
: s# N" r) M# I [Neutron Router]
# Z+ H/ S7 Z$ b! |! _; c | 10.2.0.1' J$ R/ x1 Z C. M; \, a
|' T/ T: z6 l' I
(10.2.0.0/24 DevStack West): |. H4 W# L% A1 M. o! L
DevStack Configuration
/ l* o3 c" E9 v3 K6 D4 i" { ]3 b
$ M1 K: R; N7 ~9 d$ K3 J, _For East you can append these lines to the localrc, which will give you a private net of 10.1.0.0/24 and public network of 172.24.4.0/24; v2 P( n K2 X0 m
4 ?8 g1 a* y/ E+ z5 FPUBLIC_SUBNET_NAME=yoursubnet2 z8 h6 W2 G$ a' X) P [8 ~
PRIVATE_SUBNET_NAME=mysubnet& l" T6 L& d8 U" a( D# z) L; V) i
FIXED_RANGE=10.1.0.0/249 N. i S! a0 z9 S
NETWORK_GATEWAY=10.1.0.1; g4 y! F9 b' t- ?8 b# a
PUBLIC_NETWORK_GATEWAY=172.24.4.225
% p# _% X4 C( P% Z; I: F7 iQ_FLOATING_ALLOCATION_POOL=start=172.24.4.226,end=172.24.4.2319 ~' A! [/ h+ y0 [" j
For West you can add these lines to localrc to use a different local network, public GW (and implicitly router) IP:
' p3 U D8 I, S4 ~( }1 A+ D3 \2 A, f# R2 U; w
PUBLIC_SUBNET_NAME=yoursubnet1 o) e: Z8 @% {9 E1 [7 H1 E& c
PRIVATE_SUBNET_NAME=mysubnet, X1 V8 s! F6 g. c- h8 Q* ^
FIXED_RANGE=10.2.0.0/24& D5 ^' s' R! y% U
NETWORK_GATEWAY=10.2.0.1, Q) N* D# n9 v1 ? x+ n
PUBLIC_NETWORK_GATEWAY=172.24.4.232+ G$ u7 o$ \" P- V$ e9 Z7 R2 S- Z
Q_FLOATING_ALLOCATION_POOL=start=172.24.4.233,end=172.24.4.238
/ w* U4 H8 U# R r9 E7 x0 V; S% f+ CVPNaaS Configuration' ]* K0 A0 ]1 J8 h+ S
$ X s& @# ^4 D( ^; [0 z/ l0 S( [With DevStack running on East and West and connectivity confirmed (make sure you can ping one router/GW from the other), you can perform these VPNaaS CLI commands.
3 i0 V4 Y* G4 D# }, _0 `! J( _/ {2 F) v5 f0 N5 n' I( W- J5 ~/ o7 R+ u
On East
0 |8 S3 W8 n6 g5 w9 y# ]4 {: p% e2 o
neutron vpn-ikepolicy-create ikepolicy1! g3 |5 l5 q* d* [ a, I
neutron vpn-ipsecpolicy-create ipsecpolicy1. i4 I4 m& S2 M9 T3 o' @8 y
neutron vpn-service-create --name myvpn --description "My vpn service" router1 mysubnet8 R" q! o; Z1 `
neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.233 --peer-id 172.24.4.233 --peer-cidr 10.2.0.0/24 --psk secret" v( c# r. K1 l. m+ _" I
On West
% \# s4 P3 E' ^6 A- _
% S) ~3 {2 p! y0 e& i& tneutron vpn-ikepolicy-create ikepolicy1
2 @) A: u/ f' g% n1 K6 o' v, Hneutron vpn-ipsecpolicy-create ipsecpolicy1/ [0 s/ H; l7 o' R1 i( e
neutron vpn-service-create --name myvpn --description "My vpn service" router1 mysubnet
' X7 l& V( j W! X( U9 Q6 f, Nneutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.226 --peer-id 172.24.4.226 --peer-cidr 10.1.0.0/24 --psk secret3 W3 b! a5 h; c6 M
Note: Please make sure setup security group (open icmp for vpn subnet etc)
H5 B' m) \& q" U! E$ D. f8 y1 r
6 I5 S& S1 i! F q7 p1 w; E6 N3 _$ fVerification% o# n3 h' E& s& Y& M, G
7 ]' {$ t. M1 I! _' HYou can spin up VMs on each node, and then from the VM ping the far end router's public IP. With tcpdump running on one of the nodes, you can see that pings appear as encrypted packets (ESP). Note that BOOTP, IGMP, and the keepalive packets between the two nodes are not encrypted (nor are pings between the two external IP addresses). A6 I" P% M+ I4 s$ J9 z! r
, e; Y' ?9 S7 }) a0 r8 }5 W
Kilo Update& c" A2 K& h* o9 e. Y9 B8 X9 W
+ O) Y" f; O$ p: m# K1 ~+ oFor Kilo, the localrc contents was moved into local.conf. With (VirtualBox) VMs used as hosts, where eth0 was set up as NAT, and eth1 set up as Internal Network, the following configurations were used in local.conf:' Z4 D7 c6 e& Q1 t5 T
( W+ O& i5 N7 _& l5 ^) l
OVS_PHYSICAL_BRIDGE=br-ex8 t* K* e U# ]* Z
PUBLIC_INTERFACE=eth1
- | P/ o5 U8 M, OOnce stacked, VMs were created for testing, VPN IPSec commands used to establish connections between the nodes, and security group rules added to allow ICMP and SSH.' | x: T3 F& W. G+ V' F$ {* R
2 l" h( O( _" b1 J$ x% D
VPNaaS with Single DevStack and Two Routers
0 s; ?, v6 |& R4 ?9 ?* }Simple instructions on how to setup a test environment where a VPNaaS IPSec connection can be established using the reference implementation (OpenSwan). This example uses VIrtualBox running on laptop to provide a VM for running DevStack. It assumes a Kilo release (post Juno).
8 A0 \" f* y1 ?1 H6 o' t6 j( S0 q7 m9 }& H
The idea here is to have a single OpenStack cloud created using DevStack, two routers (one created automatically), two private networks (one created automatically) -10.1.0.0/24 and 10.2.0.0/24, a VM in each private network, and establish a VPN connection between the two private nets, using the public network (172.24.4.0/24).# p9 P( U/ U& U8 I% _: y
% w4 P& J8 A9 j& v5 Q( }Preparation; `8 v/ X& Q5 T0 J/ C
Create a VM (e.g. 7 GB RAM, 2 CPUs) running Ubuntu 14.04, with NAT I/F for access to the Internet. Clone a DevStack repo with latest (Kilo-1 used for this example).3 J6 T# V( z/ @' O/ E$ T8 l
+ F( F0 Z/ M7 W1 C4 {" O0 z2 m
DevStack Configuration
$ V* b! |$ ?# K0 T! X. S2 WFor this example, the following local.conf is used:5 |3 D7 N' F8 ^" r4 I% O
- S$ j8 F6 A f localrc# H7 U! N. p# y& m( M
GIT_BASE=https://github.com! n9 ?+ ^* j! m+ n% L3 U) R( \; q, f
DEST=/opt/stack
2 V, b$ u: l$ Q3 \4 J 8 ]: A& X4 {, T& N& K9 A
disable_service n-net
# z. ^% {* g; P# t; u2 S4 V enable_service q-svc g" k3 L' `7 B- L. G
enable_service q-agt' }/ D2 A0 B2 ^ e e( g9 u- L, X
enable_service q-dhcp
- S. I5 ]& |7 y2 J/ [ enable_service q-l3% h, ]' Y1 f+ X" N% W; w
enable_service q-meta) h: Z' ~6 i- G4 h
enable_service neutron$ t& r; ~7 D) [" L! v
enable_plugin neutron-vpnaas https://git.openstack.org/openstack/neutron-vpnaas
5 ^% w2 g* [3 F b$ {, P ! H; g {, \+ E5 Z
FIXED_RANGE=10.1.0.0/24& b/ Z! s: V2 d6 L7 N* f
FIXED_NETWORK_SIZE=256
: Z) f8 N* ^/ T( N NETWORK_GATEWAY=10.1.0.1
* e& F: }4 @" k8 a0 E4 ~7 Z PRIVATE_SUBNET_NAME=privateA$ \) u5 B2 E8 x& R
5 G* [- Z V( e PUBLIC_SUBNET_NAME=public-subnet' F2 C: _$ R* \
FLOATING_RANGE=172.24.4.0/24+ p8 Q; K0 w8 e5 q% o2 B R- t7 B
PUBLIC_NETWORK_GATEWAY=172.24.4.10
w+ I% O1 R/ }$ Y Q_FLOATING_ALLOCATION_POOL="start=172.24.4.11,end=172.24.4.29"7 N. r F( c6 m) X
: s. C8 O% M" [% K# r7 k, W& F. d8 w
LIBVIRT_TYPE=qemu- @5 Q, L, r$ M
\; k" N$ Q: v$ p0 w! F IMAGE_URLS="http://cloud-images.ubuntu.com/releases/14.04.1/release/ubuntu-14.04-server-cloudimg-amd64.tar.gz,http://download.cirros-cloud.net ... 3-x86_64-uec.tar.gz": w+ y* {7 R$ j- V' D1 O3 H
3 e* Z5 v" H3 U
SCREEN_LOGDIR=/opt/stack/screen-logs
% s7 |) I9 m" N8 U0 ]+ j7 Y SYSLOG=True$ j) C( z- X- L2 N \& N: X
LOGFILE=~/devstack/stack.sh.log* c, x9 p" W0 Y. @5 x4 c6 Q W% P- _
* S: |: c/ z: {) ~- `7 t- \$ q
ADMIN_PASSWORD=password
; s9 l8 u! d: B% `3 U MYSQL_PASSWORD=password
& y6 h+ |, [% ^, G/ O/ [ RABBIT_PASSWORD=password& ]) Y4 O+ j3 D6 i# i
SERVICE_PASSWORD=password
4 U5 _8 _9 u1 ?- p6 J8 t SERVICE_TOKEN=tokentoken
) m1 J* h5 H* z 1 M' \ i: O0 y7 }9 o1 `, U
Q_USE_DEBUG_COMMAND=True
& p3 }* d9 j0 T4 r ) [2 E( e1 b9 Q2 I( V! y
# RECLONE=No$ C( G E" ]2 a/ D% O$ @. X: s
RECLONE=yes+ A# w% q+ q% e- {5 p, J8 r2 P) o
OFFLINE=False
' p, g* D% m5 C/ PStart up the cloud using ./stack.sh and ensure it completes successfully. Once stacked, you can change RECLONE to No.# Y1 j4 D! w" G! W8 F5 l
& P: ?! G) V5 z5 b& d( z+ y( KCloud Configuration
7 C4 `: D" u5 l% Z' B% f( SOnce stacking is completed, you'll have a private network (10.1.0.0/24), and a router (router1). To prepare for establishing a VPN connection, a second network, subnet, and router needs to be created, and a VM spun up in each private network.1 e$ l3 D# U5 y6 x: J' f5 g
% F3 p8 r* J: c j9 f
# Create second net, subnet, router2 C- r$ B- e0 t" b$ `# ?0 \# ]) C
source ~/devstack/openrc admin demo
9 K! m8 t2 {! k0 c( l neutron net-create privateB
( G7 H/ d: m* N: i neutron subnet-create --name subB privateB 10.2.0.0/24 --gateway 10.2.0.1* d# T# u3 T8 n3 q1 f" p$ o
neutron router-create router2* B4 f8 s+ R9 T8 J- B
neutron router-interface-add router2 subB
: _7 u4 U( j) Q% U: u neutron router-gateway-set router2 public4 B. ?4 S$ |( E
! ^8 N& w6 o9 s: Q k5 r$ [: ?: Z7 h
# Start up a VM in the privateA subnet.( T+ d! E6 a6 S0 x4 \
PRIVATE_NET=`neutron net-list | grep 'private ' | cut -f 2 -d' '`' A: v3 u# B8 b$ q& d
nova boot --flavor 1 --image cirros-0.3.3-x86_64-uec --nic net-id=$PRIVATE_NET peter
; _6 O) j) M* P& K4 F4 [; u0 Q
5 h2 h! d% C! d* u4 Q # Start up a VM in the privateB subnet
8 d& P! D" A, D- Y! x PRIVATE_NETB=`neutron net-list | grep privateB | cut -f 2 -d' '`
: f4 d+ L/ m$ L: j! i7 e3 T! K0 U, p. I& f nova boot --flavor 1 --image cirros-0.3.3-x86_64-uec --nic net-id=$PRIVATE_NETB paul5 d, X: L6 m# c9 C# j G
At this point, you can verify that you have basic connectivity. Note, DevStack will create a static route that will allow you to ping the private I/F IP of router1 from privateB network. You can remove the route, if desired.7 N8 c5 T6 X7 s
5 r9 V5 h) n+ U+ s/ Y
IPSec Site-to-site Connection Creation7 R6 ^$ Y1 y6 ^& L$ i$ Q" x" n9 D1 l
The following commands will create the IPSec connection:5 q; C( U6 n' t1 [: i) E7 }+ i
/ Q( h( T4 a. l. `/ F # Create VPN connections! D. C0 g6 W) D4 a0 u+ K, I9 N
neutron vpn-ikepolicy-create ikepolicy
& i! D8 a4 j+ r, r: K( i neutron vpn-ipsecpolicy-create ipsecpolicy0 z) T) s% T1 ~' |# x( `! u+ g0 C
neutron vpn-service-create --name myvpn --description "My vpn service" router1 privateA3 @6 s# y5 D1 h" n# }: L
! _; j# ]$ }+ Y
neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn \7 p* }* l6 f1 |6 o0 b8 M' o
--ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.24.4.13 \
% x( Y3 c/ f0 @0 x --peer-id 172.24.4.13 --peer-cidr 10.2.0.0/24 --psk secret
: ^, X) w0 t/ |6 H4 C/ p( V ' ^9 q; q9 Q2 f. K0 F% T8 g' X; M
neutron vpn-service-create --name myvpnB --description "My vpn serviceB" router2 subB6 c8 M1 }! y. Y: m3 { z8 K; V! K
" S8 X9 F# D# }5 ~
neutron ipsec-site-connection-create --name vpnconnection2 --vpnservice-id myvpnB \
3 Y- r7 T4 Z- A! y! N --ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.24.4.11 \
- |; r& L* G% q4 q --peer-id 172.24.4.11 --peer-cidr 10.1.0.0/24 --psk secret) ^+ ]! O. R* S4 n6 V
At this point (once the connections become active - which can take up to 30 seconds or so), you should be able to ping from the VM in the privateA network, to the VM in the privateB network. You'll see encrypted packets, if you tcpdump using the qg-# interface from one of the router namespaces. If you delete one of the connections, you'll see that the pings fail (if all works out correctly :).( W1 U V- I- X# Z: y1 t
# D% m' h- K* w8 Y# NMultiple Local Subnets& i* v1 v( L0 n
Early in Mitaka, IPSec site-to-site connections will support multiple local subnets, in addition to the current multiple peer CIDRs. The multiple local subnet feature is triggered by not specifying a local subnet, when creating a VPN service. Backwards compatibility is maintained with single local subnets, by providing the subnet in the VPN service creation.$ b. d3 L L3 G3 i2 L* o
. p3 R/ ^; b) t1 X: f, S9 }
To support multiple local subnets, a new capability has been provided (in Liberty), called "Endpoint Groups". Each endpoint group will define one or more endpoints of a specific type, and can be used to specify both local and peer endpoints for IPSec Connections. The Endpoint Groups separate the "what gets connected" from the "how to connect" for a VPN service, and can be used for different flavors of VPN, in the future. An example:
c) M5 j7 r* m" a9 G1 S/ b t
3 }' v& N; {& y& e/ a+ T! w1 j/ e # Create VPN connections
% v) n0 A8 y6 |2 ~ v neutron vpn-ikepolicy-create ikepolicy
* @% D" x' K; J) c* O neutron vpn-ipsecpolicy-create ipsecpolicy
% E" h8 \, C# O; c neutron vpn-service-create --name myvpnC --description "My vpn service" router13 C" Z3 @* j3 f" U0 u
To prepare for an IPSec site-to-site, one would create an endpoint group for the local subnets, and an endpoint group for the peer CIDRs, like so:
5 C: Y* J4 Q; N1 i8 R% z# K# x g: F: G7 q3 D6 p# A! O
neutron vpn-endpoint-group-create --name my-locals --type subnet --value privateA --value privateA2
% S6 d2 S; U+ x3 U6 K3 { neutron vpn-endpoint-group-create --name my-peers --type cidr --value 10.2.0.0/24 --value 20.2.0.0/24# u7 M0 h5 j7 _2 o2 X( A- }% ?
where privateA and privateA2 are two local (private) subnets, and 10.2.0.0/24 and 20.2.0.0/24 are two CIDRs representing peer (private) subnets that will be used by a connection. Then, when creating the IPSec site-to-site connection, these endpoint group IDs would be specified, instead of the peer-cidrs attribute:
' F! ]/ M( F- e) g4 D
d( r" W W6 A: v' G; j' U neutron ipsec-site-connection-create --name vpnconnection3 --vpnservice-id myvpnC \2 {. L, G) p- F6 N: c
--ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.24.4.11 \2 B! c( V$ C6 n
--peer-id 172.24.4.11 --local-ep-group my-locals --peer-ep-group my-peers --psk secret
/ N6 _6 ~7 w3 p% G5 A8 C$ o8 w7 oNotes:
7 b* c0 R8 x- o# l3 o, |+ v
) @& x/ c3 F9 B- D0 K E- RThe validation logic makes sure that endpoint groups and peer CIDRs are not intermixed.- i0 v7 b% C! ~) N2 f
Endpoint group types are subnet, cidr, network, router, and vlan. However, only subnet and cidr are implemented (for IPSec use).
0 e: c3 C2 ^3 ~" PThe endpoints in a group must be of the same type, although can mix IP versions.; I6 [- D( L1 x ~; W+ K- t
For IPSec connections, validation currently enforces that the local and peer endpoints all use the same IP version.
3 K; W# |7 I/ r$ GIPSec connection validation requires that local endpoints are subnets, and peer endpoints are CIDRs.
5 N% k6 J, g( W% iMigration will convert information for any existing VPN services and connections to endpoint groups.
$ z3 f3 ]3 B8 I' wThe original APIs will work for backward compatibility.
9 {: L& A5 i5 z! H, f# x1 Y2 Z5 |Horizon Support% @5 |2 | r# |' i5 j
Checkout Test branch
* o; n' ?- `; x; r( J/ _3 }Horizon support has been merged. i# z0 I4 Q. ?6 X% Y! _7 s
6 U) V+ n# s& k5 q# z
Enable VPN section in Horizon1 a4 H) D4 u( D0 g5 o+ ]
Note that ff q-vpn is enabled Horizon VPN support is enabled automatically.- [: z' V! W7 U9 A7 X
2 F8 P8 Q/ J$ |! yOpen4 d% y9 U7 n- q& {# A/ ]5 i
/opt/stack/horizon/openstack_dashboard/local/local_settings.py
+ d; O# [/ W! p0 J$ x. s1 Kand replace# l/ _6 B2 F: P5 M) l2 s
2 j; L1 s. j) r* O* N7 Q6 S8 p7 l
OPENSTACK_NEUTRON_NETWORK = {9 G0 S! X) a- h1 R
'enable_vpn': False,' h# R' M; k# ^+ W9 l
}
1 ?1 \9 p/ H/ c# hwith
# C, \ Y8 T% d$ X* |1 T5 K+ }5 _5 e
OPENSTACK_NEUTRON_NETWORK = {2 f( J; c8 P9 w- T6 o+ |* I
'enable_vpn': True,
2 l% F# w E o- V& M% q( r} |
|
发表于 2019-4-26 10:09:31