[Oracle Cloud] Oracle Cloud(DBaaS)とAWS(EC2)をIPSec VPN(Libreswan)で繋いでみた

本文書の目的

IPSec VPNの設定手順を理解するために、IPSecによるVPNプロトコルの標準的なソフトウェアであるlibreswanを利用して、Oracle Cloud(DBaaS)とAWS(EC2)を繋ぐ手順を確認してみました。

業務環境で利用する場合には、オンプレミス側には専用ルーターを用意することが多いと思うので、実際の手順についてはマニュアルおよび該当ルーターの手順などを参考としてください。

IPSec利用時の設定の流れの理解に役立ててもらえればと思います。

 

 

前提/準備

接続に利用するOracle Cloud側のインスタンスはDBaaS(VM)、AWS側のEC2をそれぞれ作成済み。

・Oracle Cloud(DBaaS(VM))
# uname -a
Linux dbvmee02 4.1.12-124.20.3.el6uek.x86_64 #2 SMP Thu Oct 11 17:47:32 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux

・AWS(EC2)
# uname -a
Linux ip-172-31-40-70.us-east-2.compute.internal 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# ipsec –version
Linux Libreswan 3.25 (netkey) on 3.10.0-957.el7.x86_64

 

サポートされるIPSecパラメータ

Oracle Cloudとの接続でサポートされるIPSecパラメータはマニュアルで定義されています。

参考)
https://docs.cloud.oracle.com/iaas/Content/Network/Reference/supportedIPsecparams.htm

Supported IPSec Parameters

This topic lists the supported ISAKMP and IPSec configuration parameters for an IPSec VPN. Oracle chose these values to maximize security and to cover a wide range of CPE devices. For some parameters, Oracle supports multiple values, and the recommended one is highlighted in red italics. If your CPE device is not on the list of verified devices, use the information here to configure your device.

ISAKMP Policy Options

  • ISAKMP Protocol version 1
  • Exchange type: Main mode
  • Authentication method: pre-shared-keys
  • Encryption: AES-256-cbc, AES-192-cbc, AES-128-cbc
  • Authentication algorithm: SHA-384, SHA-256, SHA1 (also called SHA or SHA1-96)
  • Diffie-Hellman group: group 5, group 2, group 1
  • IKE session key lifetime: 28800 seconds (8 hours)

IPSec Policy Options

  • IPSec protocol: ESP, tunnel-mode
  • Encryption: AES-256-cbc, AES-192-cbc, AES-128-cbc
  • Authentication algorithm: HMAC-SHA1-96
  • IPSec session key lifetime: 3600 seconds (1 hour)
  • Perfect Forward Secrecy (PFS): enabled, group 5

さらに、マニュアルには主なルーター機器を利用した際の検証済み設定手順が記載されています。
機器の種類やバージョンの差異がある場合、必ずしもその通りに設定できるとは限らないですが、参考にするとよいと思います。

 

設定手順の概要

libreswanを利用した場合の手順もマニュアルに載っています。

基本的にマニュアルに沿って設定すればよいのですが、載っているlibreswanのバージョンとの差異のせいか、うまくいかない部分がありましたので、実際の設定に利用した設定ファイルの内容を後述します。

構成のイメージ(マニュアルより転記)

手順(タイトルはマニュアルより抜粋)

    1. [共通] Information to Gather
      構成に必要となる情報(例:IPアドレスや仮想ネットワークのCIDR)を集めます。

    2. [AWS] Start the AWS Libreswan Configuration
      yum -y install libreswan
      libreswanをインストールして、VPN接続を許可するためのEC2側の各種設定を行います。

    3. [OCI] Configure Oracle Cloud Infrastructure DRG and CPE
      次にOracle Cloud側でDRGとCPEというVPN接続用のリソースを作成し、それぞれに接続対象の仮想ネットワーク情報の登録や、VPN接続を許可するためのセキュリティリストなどの設定を行います。

    4. [AWS] Set Up Your Configuration File: /etc/ipsec.d/oci-ipsec.conf
      今回接続させたい環境に合わせてIPアドレス情報などを登録します。

    5. [AWS] Set Up Your Secrets File: /etc/ipsec.d/oci-ipsec.secrets
      Oracle Cloud側のDRGにて確認したセキュリティキー情報を登録します。

    6. [AWS] Reload the Libreswan Configuration
      service ipsec restart
      設定が正しければDRGのコネクションがUPとなるはず。

    7. [AWS] Check the Libreswan Statusipsec status
      ipsec status
      ipsec接続のステータスを確認。
      設定が正しければ「established」という文字列が確認できるはず。

    8. [AWS] Check the Tunnel Interface Status
      ifconfig
      ip route show

    9. [AWS] Configure IP Routing
      ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
      ip route show
      OracleCloud側の接続対象インスタンスが所属するVCN用のルーティングを設定

    10. [AWS] Test the Connection
      pingコマンドなどで疎通を確認

 

設定値サンプル

今回の検証で実際に設定した各種ファイルの設定値について紹介します(一部マスク済み)

・/etc/sysctl.conf

 

・/etc/ipsec.conf

⇒マニュアルの記載通りだとエラーが発生したため、最終行はコメントアウト

 

・/etc/ipsec.d/ipsec_oci.secrets

⇒拡張子は指定だが、ファイル名は任意。

 

・/etc/ipsec.d/ipsec_oci.conf

⇒拡張子は指定だが、ファイル名は任意。

markパラメータの設定に関して、マニュアルに記載されていた値(mark=5/0xfffffff1、mark=5/0xfffffff2)を利用した場合、コネクションは有効となるが、疎通がうまくできない(pingできない)状態となったので上記の通りに変更(環境依存?)

 

・ルーティグ設定

⇒OCIのVCN用のルーティングを設定

 

・ipsecプロセス起動

 

・ping確認(AWS->OCI)

設定が正しければお互いのprivate IPアドレス同士で以下のようにping応答可能となる。

 

・ping確認(OCI->AWS)

 

ステータス確認例

疎通成功時の各種ステータス確認結果。

・ipsec verify

⇒全てOKとなることを確認する。

 

・ifconfig

⇒ipsec.confで指定した仮想インターフェースが表示されていればOK

 

・ip link show

⇒ipsec.confで指定した仮想インターフェースが、OCI DRGを対向としてアップしていることを確認

 

・systemctl status ipsec

⇒establishedとなっていることを確認。

 

・ipsec auto –status |grep “===”

⇒ipsec.confのアドレス指定ミスはこのコマンド使うと分かりやすい。
有効時はステータスは「erouted」となった。

 

参考文書

・Access to Other Clouds with Libreswan

Oracle Cloud:Oracle Cloud と AWS を IPSec VPN(Libreswan)でつないでみた

libreswan.org

authby
how the two security gateways should authenticate each other; acceptable values are rsasig (the default) for RSA digital signatures based authentication, secret for shared secrets (PSK) authentication, secret|rsasig for either, never if negotiation is never to be attempted or accepted (useful for shunt-only conns), and null for null-authentication. If asymmetric authentication is requested, IKEv2 must be enabled, and the options leftauth= and rightauth= should be used instead of authby. Digital signatures are superior in every way to shared secrets. Especially IKEv1 in Aggressive Mode is vulnerable to offline dictionary attacks and is performed routinely by at least the NSA on monitored internet traffic globally. The never option is only used for connections that do not actually start an IKE negotiation, such as type=passthrough connections. The auth method null is used for “anonymous opportunistic IPsec” and should not be used for regular pre-configured IPsec VPNs.

pfs
whether Perfect Forward Secrecy of keys is desired on the connection*(Aqs keying channel (with PFS, penetration of the key-exchange protocol does not compromise keys negotiated earlier); Since there is no reason to ever refuse PFS, Libreswan will allow a connection defined with pfs=no to use PFS anyway. Acceptable values are yes (the default) and no.

mark If set, the MARK to set for the IPsec SA of this connection. The format of a CONNMARK is mark/mask. If the mask is left out, a default mask of 0xffffffff is used. A mark value of -1 means to assign a new global unique mark number for each instance of the connection. Global marks start at 1001. This option is only available on linux NETKEY/XFRM kernels. It can be used with iptables to create custom iptables rules using CONNMARK. It can also be used with Virtual Tunnel Interfaces (“VTI”) to direct marked traffic to specific vtiXX devices.

vti-interface
This option is used to create “Routing based VPNs” (as opposed to “Policy based VPNs”). It will create a new interface that can be used to route traffic in for encryption/decryption. The Virtual Tunnel Interface (“VTI”) interface name is used to for all IPsec SA*(Aqs created by this connection. This requires that the connection also enables either the mark= or mark-in= / mark-out- option(s). All traffic marked with the proper MARKs will be automatically encrypted if there is an IPsec SA policy covering the source/destination traffic. Tools such as tcpdump and iptables can be used on all cleartext pre-encrypt and post-decrypt traffic on the device. See the libreswan wiki for example configurations that use VTI. VTI interfaces are currently only supported on Linux with XFRM/NETKEY. The _updown script handles certain Linux specific interfaces settings required for proper functioning (disable_policy, rp_filter, forwarding, etc). Interface names are limited to 16 characters and may not allow all characters to be used. If marking and vti-routing=yes is used, no manual iptables should be required. However, administrators can use the iptables mangle table to mark traffic manually if desired.

vti-routing
Whether or not to add network rules or routes for IPsec SA*(Aqs to the respective VTI devices. Valid values are yes (the default) or no. When using “routing based VPNs” with a subnets policy of 0.0.0.0/0, this setting needs to set to no to prevent imploding the tunnel, and the administrator is expected to manually add ip rules and ip routes to configure what traffic must be encrypted. When set to yes, the _updown script will automatically route the leftsubnet/rightsubnet traffic into the VTI device specified with vti-interface

encapsulation
In some cases, for example when ESP packets are filtered or when a broken IPsec peer does not properly recognise NAT, it can be useful to force RFC-3948 encapsulation. In other cases, where IKE is NAT*(Aqed but ESP packets can or should flow without encapsulation, it can be useful to ignore the NAT-Traversal auto-detection. encapsulation=yes forces the NAT detection code to lie and tell the remote peer that RFC-3948 encapsulation (ESP in port 4500 packets) is required. encapsulation=no ignores the NAT detection causing ESP packets to send send without encapsulation. The default value of encapsulation=auto follows the regular outcome of the NAT auto-detection code performed in IKE. This option replaced the obsoleted forceencaps option.

nat-keepalive
whether to send any NAT-T keep-alives. These one byte packets are send to prevent the NAT router from closing its port when there is not enough traffic on the IPsec connection. Acceptable values are: yes (the default) and no.

 

 

IPSec本をいくつか読んでみようかな(メモ)

 

 

スポンサードリンク

1 Comment

  1. Howdy,

    Must say your website looks quite ok. Good job.
    However, if you want your website to be really successful, then make sure you use the best tools to optimize your online content.
    Otherwise it won’t be on the top of Google search results and no-one will know about it. I’m sure you didn’t create this website to just be online, but to attract new people/customers.

    Few months ago my friend convinced me to use tools from below article and I have to say it helped me soo much:
    https://janzac.com/resources/

    I hope it will help you as well.
    Keep up the good work and you will eventually build a big online business.
    //Lucy

Leave a Reply

Your email address will not be published.


*