EdgeRouter - EdgeRouter와 Azure VPN 게이트웨이 사이의 IPsec 정책 기반 사이트 투 사이트 VPN (IKEv1/IPsec)

download at 2017-09-26T18:37:50Z origin

 Overview

이 문서는 Azure VPN 게이트웨이와 EdgeRouter 사이에서 정책 기반 사이트 투 사이트 IPsec VPN을 설정하는 방법에 대하여 서술합니다.

정책기반 VPN은 로컬, 원격지 서브넷과 Azure에 연결할 때 IKEv1의 사용도에 따라서 정의됩니다. 정책 기반 VPN타입과 다르게 경로 기반 VPN의 가상 터널 인터페이스(VTI) 사용과 라우팅 엔트리에 따라 달라집니다. Azure Route-Based (BGP over IKEv2/IPsec) , Azure Route-Based (VTI over IKEv2/IPsec) 문서를 참조하십시오.

book_25x25.png NOTES & REQUIREMENTS: EdgeOS 1.9.7 이상의 펌웨어가 설치된 모든 EdgeRouter 모델에서 적용 가능합니다. 커맨드라인 인터페이스와 Azure 포탈, 고급 네트워킹에 대한 지식이 요구됩니다. 해당 주제에 대한 내용은 관련 문서 섹션의 문서를 확인하시기 바랍니다.

이 문서에서 사용한 장비:

  • EdgeRouter-X (ER-X)
  • Azure VPN 게이트웨이
  • 피어의 테스트 클라이언트 (Host1 and Server1)

추가 Azure 요구사항:

  • EdgeRouter의 퍼블릭 IP (NAT 구성을 받지 않아야 합니다)
  • 활성화된 Azure 구독 정보

더 많은 Azure VPN과 요구사항은 About VPN Devices 문서를 참조하세요.

Table of Contents

  1. 네트워크 다이어그램
  2. Steps - 정책기반 VPN
  3. Steps - Azure 게이트웨이
  4. Steps - 테스팅 및 검증
  5. 관련 문서

네트워크 다이어그램

맨위로 가기

네트워크 토폴로지는 아래와 같습니다. EdgeRouter (ER)와 Azure VPN 게이트웨이 (GW)의 인터페이스와 IP 주소는 다음과 같습니다:

ER-X

  • eth0 (WAN) - 203.0.113.1
  • eth1 (LAN) - 192.168.1.1/24

Azure GW

  • Virtual Gateway - 192.0.2.1
  • Virtual Network - 172.16.0.0/22
  • Default Subnet - 172.16.1.0/24

image1

Steps - 정책 기반 VPN

맨위로 가기

라우팅과 인터페이스 설정은 이미 완료했으며, 서로 통신이 가능하다고 가정합니다.

IPsec과 관련있는 UDP 포트와 프로토콜은 다음과 같습니다:

  1. UDP 500 (IKE)
  2. ESP (프로토콜 50)
  3. UDP 4500 (NAT-T)

생성할 VPN 타입은 정책 기반 VPN이며, 원격지, 로컬 서브넷을 사용하며 해당 서브넷 정보가 없으면 프록시 ID를 사용합니다. 이 값들은 정확하게 두 피어간에 일치해야하며, 서로 동일한 내용을 가지고 있어야합니다. 터널을 통해서 미리 정해진 프록시 ID에서 전송 가능합니다. ER 예제에서는 192.168.1.0/24 가 LAN에서 존재하며, Azure에서는 172.16.1.0/24를 사용합니다.

처음에는 ER의 환경설정에 대하여 설명하고 이후에는 Azure의 게이트웨이에 대하여 설정합니다. Azure IPsec 피어 IP 주소는 Dashboard > All Resources > Public IP address에서 찾아 볼 수 있습니다.

www.png  GUI STEPS: 라우터의 웹 관리 포털 (GUI)에 접속합니다.

  1. ER의 IPsec 피어와 보안 설정을 정의합니다. (<secret>을 원하는 패스워드로 설정합니다.)

VPN > IPsec Site-to-Site > +Add Peer

  • 고급 옵션을 확인
  • 자동 방화벽 개방과 NAT부터 얻는 트래픽을 제외
Peer: 192.0.2.1
Description: IPsecAzure
Local IP: 203.0.113.1
Encryption: AES-256
Hash: SHA1
DH Group: 2
Pre-shared Secret: <secret>
Local subnet: 192.168.1.0/24
Remote subnet: 172.16.0.0/22

info_i_25x25.png

Note

원격지 서브넷 (프록시 ID)는 가상 네트워크에서 'address space'로 대응됩니다. 원격 서브넷은 기본 (172.16.1.0/24)과 게이트웨이 서브넷 (172.16.0.0/24)를 아래의 Azure 설정에 따라서 생성합니다.

image4

CLI_circle.png  CLI STEPS: 커맨드라인 인터페이스에 접속합니다. GUI의 CLI 버튼을 사용하던가, PuTTY와 같은 프로그램을 사용합니다.

  1. 환경설정 모드로 진입합니다.
configure
  1. 현재 VPN 피어 환경설정을 확인합니다. (관련 정보만 아래에 출력됩니다.)
show vpn
ipsec {
   esp-group FOO0 {
       lifetime 3600
       pfs enable
       proposal 1 {
           encryption aes256
           hash sha1
       }
   }
   ike-group FOO0 {
       key-exchange ikev1
       lifetime 28800
       proposal 1 {
           dh-group 2
           encryption aes256
           hash sha1
       }
   }
...

info_i_25x25.png

Note

Azure VPN 게이트웨이는 다른 암호화, 해싱 기법도 사용할 수 있습니다. 보안 설정으로는 AES256, SHA1을 선택할 수 있습니다. 지원하는 보안 설정은 About VPN Devices 를 참조하십시오.

  1. 완전 순방향 비밀성(PFS)을 비활성화합니다.
set vpn ipsec esp-group FOO0 pfs disable
  1. IPsec 커넥션 타입을 변경합니다.
set vpn ipsec site-to-site peer 192.0.2.1 connection-type respond

info_i_25x25.png

Note

VPN 커넥션 타입은 주로 비 기능 연결이 재협상 (키링)하는 횟수에 영향을 줍니다. respond 값은 1 으로 설정되어 재시도를 수행하며, initiate 옵션으로 커넥션을 계속해서 재시도 할 수 있습니다.

  1. (선택사항) 로컬 IPsec 인터페이스 주소를 변경합니다.

다음 명령어를 사용하여 IPsec 패킷이 원격지 피어로 향할 소스의 로컬 IP 주소를 특정합니다. dhcp-interface 와 local-address명령어는 동시에 사용할 수 없습니다. 어떤 명령어가 가장 적합한가는 본인의 상황에 맞추어 결정해야합니다:

  1. 다중 WAN 인터페이스를 사용하고 다중 인터페이스에 VPN이 응답해야한다.

이 명령어는 IPv4 주소는 VPN의 소스로 사용할 수 있습니다. PPPoE를 통해서 WAN 인터페이스가 주소를 전달는다면 이 명령어를 사용할 수 있습니다.

set vpn ipsec site-to-site peer 192.0.2.1 local-address 0.0.0.0

info_i_25x25.png

Note

현재는 local-address 0.0.0.0 와 local-address any 를 사용하는 것을 권장합니다.

  1. WAN 인터페이스가 주소를 DHCP를 통해서 전달받는 경우
delete vpn ipsec site-to-site peer 192.0.2.1 local-address
set vpn ipsec site-to-site peer 192.0.2.1 dhcp-interface eth0
  1. (선택사항) IPsec 오프로딩 기능을 활성화하여 ESP 성능을 향상시킵니다.
set system offload ipsec enable (this requires a reboot to become active)
  1. 변경내역을 커밋합니다.
commit
  1. 환경설정을 저장합니다.
save

Steps - Azure 게이트웨이

맨위로 가기

Microsoft Azure 의 사이트 투 사이트 커넥션은 Azure 포탈에서 'new' 기능을 사용한 것을 바탕으로 진행합니다. 아래의 문서를 참조하세요:

Create a Site-to-Site connection in the Azure portal

info_i_25x25.png

Note

VPN 게이트웨이를 이전의 방법을 통해서 설정할 수도 있습니다. 이 문서의 예제는 자원 관리 매니저 배포 모델인 새로운 방법을 사용합니다.

www.png  GUI STEPS: Azure 관리 포탈 (GUI)에 접속합니다.

  1. 가상 네트워크를 생성합니다.

Dashboard > New > Networking > Virtual Network

Name: ServerNetwork
Address Space: 172.16.0.0/22
Subnet name: default
Subnet Address Space: 172.16.1.0/24
Resource Group: ServerNetwork
  1. 게이트웨이 서브넷을 생성합니다.

Dashboard > Virtual Networks > ServerNetwork > Subnets > + Gateway subnet

Name: GatewaySubnet (Required / cannot be changed)
Address Range: 172.16.0.0/24 (Cannot be the same as the default subnet address space)

image6

  1. 가상 네트워크 게이트웨이를 생성합니다.

Dashboard > New > Networking > Virtual Network Gateway

Name: VirtualGateway
Gateway Type: VPN
VPN Type: Policy-Based
SKU: Basic (depends on usage)
Virtual Network: ServerNetwork
Public IP Address: Create new > VirtualGateway

info_i_25x25.png

Note

가상 게이트웨이 프로비저닝은 시간이 소요됩니다. 게이트웨이 스톡 키핑 유닛 (SKU)는 VPN 커넥션의 출력량을 정의합니다. 더 많은 SKU 정보는 About VPN Gateway 에서 찾아볼 수 있습니다.

  1. 로컬 네트워크 게이트웨이를 생성합니다.

Dashboard > New > Networking > Local Network Gateway

Name: LocalGateway
IP Address: 203.0.113.1
Address Space: 192.168.1.0/24

info_i_25x25.png

Note

'address space'는 원격 서브넷으로 정의되며 ER이 사용하는 서브넷에 대응됩니다. 로컬 서브넷은 가상 네트워크의 'address space'이며, 이 문서에서는 172.16.0.0/22를 사용합니다. 프록시 ID와 정확하게 일치해야하며, 그렇지 않은 경우에는 VPN 연결이 이루어지지않습니다.

image7

  1. 로컬 게이트웨이와 가상 게이트웨이를 연결하는 VPN 커넥션을 생성합니다.

Daskboard >Virtual Network Gateways > VirtualGateway > Connections > + Add

Name: IPsecER
Connection Type: Site-to-Site (IPsec)
Virtual Network Gateway: VirtualGateway
Local Network Gateway: LocalGateway
Shared Key: <secret>

image8

image9

Steps - 테스팅 및 검증

맨위로 가기

IPsec VPN을 설정하고 난 이후에는 커넥션/상태를 다음 명령어를 통해서 검증할 수 있습니다.

  1. IPsec 보안 옵션을 검증하고 ER의 상태를 확인합니다:
show vpn ipsec sa
peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 88f1089a87512385:ba7111edb4e0680e
 local  '203.0.113.1' @ 203.0.113.1
 remote '192.0.2.1' @ 192.0.2.1
 AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
 established 674s ago, reauth in 27486s
 peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA1_96
   installed 14 ago, rekeying in 2517s, expires in 3586s
   in  cc545afa,   1989 bytes,    11 packets,     6s ago
   out 74d8dfc0,   3042 bytes,    16 packets,     7s ago
   local  192.168.1.0/24
   remote 172.16.0.0/22

sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
 uptime: 13 minutes, since Jul 14 09:27:42 2017
 malloc: sbrk 376832, mmap 0, used 267656, free 109176
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
Listening IP addresses:
 192.16.1.1
 203.0.113.1
Connections:
peer-192.0.2.1-tunnel-1:  203.0.113.1...192.0.2.1  IKEv1
peer-192.0.2.1-tunnel-1:   local:  [203.0.113.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1:   remote: [192.0.2.1] uses pre-shared key authentication
peer-192.0.2.1-tunnel-1:   child:  192.168.1.0/24 === 172.16.0.0/22 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-1{1}:  ROUTED, TUNNEL
peer-192.0.2.1-tunnel-1{1}:   192.168.1.0/24 === 172.16.0.0/22
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-1[1]: ESTABLISHED 13 minutes ago, 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
peer-192.0.2.1-tunnel-1[1]: IKEv1 SPIs: 88f1089a87512385_i ba7111edb4e0680e_r*, pre-shared key reauthentication in 7 hours
peer-192.0.2.1-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
peer-192.0.2.1-tunnel-1{1}:  INSTALLED, TUNNEL, ESP SPIs: cc545afa_i 74d8dfc0_o
peer-192.0.2.1-tunnel-1{1}:  AES_CBC_256/HMAC_SHA1_96, 2053 bytes_i (13 pkts, 13s ago), 3042 bytes_o (16 pkts, 125s ago)
peer-192.0.2.1-tunnel-1{1}:   192.168.1.0/24 === 172.16.0.0/22

2. ER IPsec strongSwan 환경설정을 검증합니다:

sudo cat /etc/ipsec.conf
# generated by /opt/vyatta/sbin/vpn-config.pl

config setup

conn %default
       keyexchange=ikev1

conn peer-192.0.2.1-tunnel-1
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.0.0/22
       ike=aes256-sha1-modp1024!
       keyexchange=ikev1
       ikelifetime=28800s
       esp=aes256-sha1!
       keylife=3600s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       auto=route
       keyingtries=1
#conn peer-192.0.2.1-tunnel-10

3. ER 외부 WAN 인터페이스를 통해서 수신하는 IKE 트래픽을 캡쳐합니다:

sudo tcpdump -i eth0 -n udp dst port 500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident[E]
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick[E]
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick[E]

info_i_25x25.png

Note

실시간 캡쳐의 결과이므로 아무런 결과가 발견되지 않는다면 클라이언트가 트래픽을 생성하지 않거나 트래픽 업스트림이 차단당한 것일수도 있습니다.

4. ER IPsec VPN 로그를 확인합니다:

sudo swanctl --log
[KNL] creating acquire job for policy 192.168.1.10/32[icmp/8] === 172.16.1.10/32[icmp/8] with reqid {1}
[IKE] initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1[1] to 192.0.2.1
[ENC] generating ID_PROT request 0 [ SA V V V V ]
[NET] sending packet: from 203.0.113.1[500] to 192.0.2.1[500] (160 bytes)
[NET] received packet: from 192.0.2.1[500] to 203.0.113.1[500] (108 bytes)
[ENC] parsed ID_PROT response 0 [ SA V ]
[IKE] received NAT-T (RFC 3947) vendor ID
[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
[ENC] parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
[ENC] parsed ID_PROT response 0 [ ID HASH ]
[IKE] IKE_SA peer-192.0.2.1-tunnel-1[1] established between 203.0.113.1[203.0.113.1]...192.0.2.1[192.0.2.1]
[ENC] generating QUICK_MODE request 561157166 [ HASH SA No ID ID ]
[ENC] parsed QUICK_MODE response 561157166 [ HASH SA No ID ID N((24576)) ]
[IKE] CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb321982_i 5d4174b1_o and TS 192.168.1.0/24 === 172.16.0.0/22

info_i_25x25.png

Note

실시간 캡쳐 결과이므로 출력이 보이지 않는다면, 트래픽이 방화벽을 통해서 허용되었는지 확인하십시오. 다른 방법으로는 show vpn log | no-more명령어를 통해서 전체 IPsec 로그 히스토리를 확인할 수 있습니다.

  1. Server1 과 Host1사이에 터널을 통해 트래픽을 전송해봅니다:
ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=63 time=45.5 ms

ping 172.16.1.10
PING 172.16.1.10 (172.16.1.10) 56(84) bytes of data.
64 bytes from 172.16.1.10: icmp_seq=1 ttl=63 time=45.9 ms
64 bytes from 172.16.1.10: icmp_seq=2 ttl=63 time=45.2 ms
64 bytes from 172.16.1.10: icmp_seq=3 ttl=63 time=45.5 ms
  1. Azure 게이트웨이 연결을 검증합니다. (관련 결과만 아래에 출력합니다.)
Get-AzureRmVirtualNetworkGatewayConnection -Name "IPsecER" -ResourceGroupName "ServerNetwork"

Name                    : IPsecER
ResourceGroupName       : ServerNetwork
Location                : eastus
ProvisioningState       : Succeeded
ConnectionStatus        : Connected
EgressBytesTransferred  : 3854
IngressBytesTransferred : 3104

info_i_25x25.png

Note

검증 명령어는 Azure 파워셸을 필요로 합니다. 윈도우 파워셸을 사용하여 Azure를 관리하는 방법은 Microsoft에서 제공하는 Getting started with Azure PowerShell 문서를 참조하세요.

관련 문서

맨위로 가기