Compnet

仕事とか遊びとか、日々折々

2015-10-28(水)

RTX と Linux を IPsec で接続 (Openswan) - メインモードで成功

Posted by Nakane, R. in technical   

Note

この記事は旧ブログから移行した記事です。 元記事は ここ にあります。

2年近く前に書いた「RTX と Linux を IPsec で接続 (Openswan)」を再検証して、IPsec を使った VPN セッションの確立になんとかこぎ着けたので、それを記す。

Openswan

IPsec を使った VPN セッションを確立したとはいうものの、それは両端を固定 IP アドレスにしたメイン モードのときだけだ。 片側の IP アドレスを不定にできるアグレッシブ モードのときや、NAPT 越えのための NAT Traversal を使ったときの VPN セッションの確立には、未だに至っていない。 これらについては、さらなる検証が追って必要だ。

検証環境

検証に使用した環境は以下の通り。

以前の検証で使用した環境はすでに破棄しており、改めて構築したため「RTX と Linux を IPsec で接続 (Openswan)」のときとは微妙に異なるが、大枠では同一になるようにしたつもりだ。

検証の目標も以前と同様で、Linux と RTX シリーズ ルーターの間に IPsec で VPN セッションを張り、Linux から RTX シリーズ ルーターを越えた先のネットワークにある機器と通信できることだ。 Linux の通信相手には VPN セッションの片側の端点になる RTX シリーズ ルーターも含み、通信のパケットがすべて VPN セッションを通るようにしたい。

使用する Linux のディストリビューションは ubuntu 14.04 LTS だ。Openswan は ubuntu 14.04 LTS の標準パッケージを使うので、そのバージョンは 2.6.38 になる。Linux の LAN インターフェースは eth0 の一枚だけだ。そこに 172.26.0.107 を割り当て、サブネットマスクを 24 bit (255.255.255.0) にする。

RTX シリーズ ルーターには RTX1100 を使う。これよりも新しい検証機として使える機種は、相変わらず筆者の手元には無く、甘んじるしかない。 ファームウェアは最新の Rev.8.03.94 にしてある。RTX1100 の LAN1 に 172.26.200.250 を、LAN2 に 172.26.255.250 を割り当てる。 サブネットマスクはどちらも 24 bit (255.255.255.0) だ。

Linux と RTX1100 の間にはローカル ルーターを置いて、双方のネットワークを分離した。 間に入れたルーターの LAN インターフェース には 172.26.0.1/24 と 172.26.255.2/24 を割り当てた。

IPsec の VPN セッションは、Linux の eth0 (172.26.0.101) と RTX1100 の LAN2 (172.26.255.250) の間に張る。 IPsec VPN セッションを通じた通信は、Linux の eth0 に割り当てた 172.26.0.101 と RTX1100 の LAN2 の 172.26.200.250 とで確認する。

IPsec のパラメータは以下のようにした。

相互認証の方式 共通鍵 (pre-shared-key)
交換モード メイン モード
IKE ハッシュ アルゴリズム SHA1
IKE 暗号アルゴリズム AES128
IPsec モード トンネル モード
IPsec ハッシュ アルゴリズム SHA1
IPsec 暗号アルゴリズム AES128
DH グループ Phase 1: グループ 2 (1024 bit)Phase 2: グループ 2 (1024 bit)
ID のタイプ ID_IPV4_ADDR
PFS の使用 使用しない
ISAKMP SA の寿命 28800 秒 (8 時間)
IPsec SA の寿命 28800 秒 (8 時間)

なお、共通鍵は “IJ9onfrdsCQL0JqIeL64” にする。

Linux の設定

まずは Linux (Ubuntu 14.04LTS) の LAN インターフェース eth0 に IP アドレス等を設定し、IPsec VPN の対向端点を含むネットワーク 172.26.255.0/24 宛ての経路情報を設定しておく。さらに、IPsec の実装である Openswan を sudo apt-get install openswan コマンドでインストールしておく。

Openswan は、パッケージをインストールした後に OS 周りを適切に設定する必要がある。OS 周りの設定を確認するには sudo ipsec verify コマンドを実行する。Openswan パッケージをインストールした直後に sudo ipsec verify コマンドを実行すると、以下のように FAILED が出る。

sudo ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.2.0-58-generic (netkey)
Checking for IPsec support in kernel                            [OK]
SAref kernel support                                           [N/A]
NETKEY:  Testing XFRM related proc values                      [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

        [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

        [OK]
Checking that pluto is running                                  [OK]
Pluto listening for IKE on udp 500                             [OK]
Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

この sudo ipsec verify コマンドの結果から「FAILED」をなくすには、以下のコマンドを実行して OS の設定を変更する。

for f in /proc/sys/net/ipv4/conf/*/{send,accept}_redirects; do if [ `cat $f` -eq 1 ]; then echo 0 | sudo tee $f; fi; done

先の sudo ipsec verify コマンドの実行結果では /proc/sys/net/ipv4/conf/*/send_redirects に関する項目が FAILED で、/proc/sys/net/ipv4/conf/*/accespt_redirects に関する項目が OK になっている。 単純にメッセージに従って /proc/sys/net/ipv4/conf/*/send_redirects を disable (0) に変更して、再度 sudo ipsec verify コマンドを実行すると、今度は /proc/sys/net/ipv4/conf/*/accespt_redirects に関する項目が FAILED になる。 これが分かっていたので、上記では /proc/sys/net/ipv4/conf/*/send_redirects と /proc/sys/net/ipv4/conf/*/accespt_redirects の両方をまとめて disable (0) にするコマンドを実行した。

上記のコマンドを実行をした後に、再度 sudo ipsec verify コマンドを実行して「FAILED」がなくなったことを確認する。

sudo ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.37/K3.2.0-58-generic (netkey)
Checking for IPsec support in kernel                            [OK]
SAref kernel support                                           [N/A]
NETKEY:  Testing XFRM related proc values                      [OK]
        [OK]
        [OK]
Checking that pluto is running                                  [OK]
Pluto listening for IKE on udp 500                             [OK]
Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

これだけではシステムを再起動すると元に戻ってしまうので、以下のように /etc/sysctl.d/ ディレクトリに 60-icmp-redirect.conf ファイルを作り、起動時にシステムの設定が変更されるようにする。

for f in /proc/sys/net/ipv4/conf/{all,default}/{send,accept}_redirects; do echo "${f#/proc/sys/} = 0"; done | sed -e 's#/#.#g' | sudo tee /etc/sysctl.d/60-icmp-redirect.conf >/dev/null

念のために、ここで再起動をしてから sudo ipsec verify コマンドの結果を確認してもいいだろう。

次に、Openswan に IPsec VPN セッションの設定をする。Openswan に IPsec VPN セッションを追加するために、/etc/ipsec.conf に以下の内容を追記する。

conn vpn_session1
    auto=add
    type=tunnel
    aggrmode=no
    authby=secret
    keyexchange=ike
    ike=aes128-sha1;modp1024
    phase2=esp
    phase2alg=aes128-sha1;modp1024
    pfs=no
    left=172.26.0.107
    leftid=172.26.0.107
    leftsubnet=172.26.0.107/32
    right=172.26.255.250
    rightid=172.26.255.250
    rightsubnet=172.26.250.0/24
   :

相互認証に使う事前共有鍵の値は、/var/lib/openswan/ipsec.secrets.inc ファイルに以下のように記述する。もしこのファイルが無いならば sudo touch /var/lib/openswan/ipsec.secrets.inc; sudo chmod u=rw,go= /var/lib/openswan/ipsec.secrets.inc コマンドでこれを作成する。

   :
172.26.0.101 172.26.255.250: PSK "IJ9onfrdsCQL0JqIeL64"
   :

以上で Linux 側の設定ができた。

最後に sudo service ipsec reload コマンド (または sudo ipsec reload コマンド) を実行して、追記した設定を読み込ませておく。/etc/ipsec.conf ファイルに追記した vpn_session1 セクションは auto=add のため、対向から接続してくるか、sudo ipsec auto --up vpn_session1:bash: コマンドで接続を開始しなければ、IPsec VPN セッションは動作しない。VPN セッションの確立を確認できた後は、auto=addauto=start に修正して、自動的に接続するようにする。

RTX1100 の設定

RTX1100 は以下のように設定した (必要な部分だけを抜粋)。

   :
ip route 172.26.0.0/24 gateway 172.26.255.2
ip route 172.26.0.107 gateway tunnel 1 filter 999

ip lan1 address 172.26.200.250/24
ip lan2 address 172.26.255.250/24

tunnel select 1
tunnel encapsulation ipsec
ipsec tunnel 1001
  ipsec sa policy 1001 1 esp aes-cbc sha-hmac
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike local address 1 172.26.255.250
  ipsec ike local id 1 172.26.200.0/24
  ipsec ike pre-shared-key 1 text IJ9onfrdsCQL0JqIeL64
  ipsec ike remote address 1 172.26.0.107
  ipsec ike remote id 1 172.26.0.107/32
  ipsec auto refresh 1 off
tunnel enable 1

ip filter 999 pass 172.26.200.0/24 * * * *

ipsec auto refresh on
   :

この RTX1100 の設定では、IPsec VPN に使う IKE の鍵交換を起動しないように ipsec auto refresh 1 off としてあるため、RTX1100 から IPsec VPN セッションを接続し始めることはない。VPN セッションの確立を確認できた後は、ipsec auto refresh 1 offipsec auto refresh 1 on に修正して、自動的に接続するようにする。

2年前との比較

これらの設定は「RTX と Linux を IPsec で接続 (Openswan)」のときと何が異なるのか。検証環境が若干異なるため、IP アドレスが異なっている。事前共有鍵の値も異なっている。

それら以外に Linux の Openswan の設定では、以下の箇所が削除されている。しかし削除されたこの箇所は、IPsec VPN セッションの確立に影響しないので、2 年前と異なるとは捉えなくても良い。

:
 compress=no
 ikelifetime=8h
 salifetime=8h
:

RTX1100 の設定では、IP アドレスと事前共有鍵以外に以下の箇所が 2年前と異なる。

   :
tunnel select 1
  ipsec ike local id 1 172.26.200.0/24
  ipsec ike remote id 1 172.26.0.107/32
   :

RTX1100 で変更したこの 2行が、IPsec VPN セッション確立の肝だったようだ。

Linux 側から IPsec VPN を接続

それでは実際に IPsec VPN セッションを確立してみよう。まずは Linux 側からセッションを確立する。

sudo ipsec auto --up vpn_session1
104 "to_rtx" #1238: STATE_MAIN_I1: initiate
106 "to_rtx" #1238: STATE_MAIN_I2: sent MI2, expecting MR2
108 "to_rtx" #1238: STATE_MAIN_I3: sent MI3, expecting MR3
004 "to_rtx" #1238: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
117 "to_rtx" #1239: STATE_QUICK_I1: initiate
004 "to_rtx" #1239: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x3d567a00 <0xabdfa79d xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none}

セッションの確立を確認するため、traceroute -n 172.26.200.250 コマンドを実行する。

traceroute -n 172.26.200.250
traceroute to 172.26.200.250 (172.26.200.250), 30 hops max, 60 byte packets
 1  172.26.200.250  3.854 ms  4.250 ms  4.977 ms

途中経路にあたる機器の反応無しに VPN セッション端点の先にある IP アドレスからの返事があり、VPN セッションを通じて通信していると判断できる。もし、VPN セッションが確立できていないなら、到達しないか、途中のルーター (172.26.0.1) が経路に表示されるはずだ。

VPN セッションの端点に宛てた traceroute の結果は以下の通りだ。セッション内を通らない経路で通信していることが分かる。

traceroute -n 172.26.255.250
traceroute to 172.26.255.250 (172.26.255.250), 30 hops max, 60 byte packets
 1  172.26.0.1  0.792 ms  0.586 ms  1.013 ms
 2  172.26.255.250  2.698 ms  2.930 ms  3.119 ms

RTX1100 からも traceroute 172.26.0.107 noresolv -sa 172.26.200.250traceroute 172.26.0.107 noresolv コマンドを実行する。

traceroute 172.26.0.107 noresolv -sa 172.26.200.250
1  172.26.0.107        1.756 ms        1.968 ms        1.585 ms
traceroute 172.26.0.107 noresolv
1  172.26.255.2        1.003 ms        1.144 ms        0.910 ms
2  172.26.0.107        1.450 ms        1.359 ms        1.228 ms

さらに、RTX1100 で show ipsec sa コマンドで SA の状態を見ておこう。

show ipsec sa
sa   sgw connection   dir  life[s] remote-id
--------------------------------------------------------------------------
1    11  isakmp       -    2592    172.26.0.107
2    11  tun[001]esp  send 27792   172.26.0.107
3    11  tun[001]esp  recv 27262   172.26.0.107

SA[1] 寿命: 2592秒
自分側の識別子: 172.26.255.250
相手側の識別子: 172.26.0.107
プロトコル: IKE
SPI: 28 74 4b dd 39 f0 1e e1 1b 78 2e b3 eb b4 77 c3
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[2] 寿命: 27792秒
自分側の識別子: 172.26.255.250
相手側の識別子: 172.26.0.107
送受信方向: 送信
プロトコル: ESP (モード: tunnel)
アルゴリズム: AES-CBC (認証: HMAC-SHA)
SPI: e1 fc 6a 78
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[3] 寿命: 27262秒
自分側の識別子: 172.26.255.250
相手側の識別子: 172.26.0.107
送受信方向: 受信
プロトコル: ESP (モード: tunnel)
アルゴリズム: AES-CBC (認証: HMAC-SHA)
SPI: 3d 56 7a 00
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------

VPN セッションの確立とそれを通じた接続を確認できたところで、今度は RTX 側からセッションの確立を試す。その前にすでに確立しているセッションを sudo ipsec auto --down vpn_session1 コマンドで切断する。Linux 側で VPN セッションを切断しても、IKE の生存時間中は RTX 側に SA が残るので、RTX1100 で ipsec delete sa all コマンドを実行して SA を削除する。

RTX 側から IPsec VPN を接続

RTX1100 側から IPsec VPN セッションを確立させるために ipsec auto refresh 1 on を設定する。するとすぐに VPN セッションが確立する。

show ipsec sashow log コマンドを実行して、確立の状況を確認する。ログは syslog info onsyslog notice onsyslog debug on を全て設定して、目一杯出力されるようにしてある。

show ipsec sa
sa   sgw connection   dir  life[s] remote-id
--------------------------------------------------------------------------
1    11  isakmp       -    28780   172.26.0.107
2    11  tun[001]esp  send 28782   172.26.0.107
3    11  tun[001]esp  recv 28782   172.26.0.107

SA[1] 寿命: 28780秒
自分側の識別子: 172.26.255.250
相手側の識別子: 172.26.0.107
プロトコル: IKE
NATトラバーサル: なし
SPI: d2 13 90 8f e8 ce 2e 86 b9 80 33 1b e7 7e 1d 68
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[2] 寿命: 28782秒
自分側の識別子: 172.26.255.250
相手側の識別子: 172.26.0.107
送受信方向: 送信
プロトコル: ESP (モード: tunnel)
アルゴリズム: AES-CBC (認証: HMAC-SHA)
SPI: 07 eb d3 bc
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[3] 寿命: 28782秒
自分側の識別子: 172.26.255.250
相手側の識別子: 172.26.0.107
送受信方向: 受信
プロトコル: ESP (モード: tunnel)
アルゴリズム: AES-CBC (認証: HMAC-SHA)
SPI: 36 38 13 f2
鍵 : ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
show log
2015/10/27 16:31:30: [IKE] initiate ISAKMP phase to 172.26.0.107 (local address
 172.26.255.250)
2015/10/27 16:31:30: [IKE] add ISAKMP context [6286] d213908fe8ce2e86 00000000
2015/10/27 16:31:32: [IKE] add ISAKMP SA[1] (gateway[11])
2015/10/27 16:31:32: [IKE] activate ISAKMP socket[11]
2015/10/27 16:31:32: [IKE] initiate IPsec phase to 172.26.0.107
2015/10/27 16:31:32: [IKE] add IPsec context [6287] d213908fe8ce2e86 64d1b08a
2015/10/27 16:31:33: [IKE] setup IPsec SAs (gateway[11], ISAKMP SA[1])
2015/10/27 16:31:33: [IKE] add IPsec SA[2]
2015/10/27 16:31:33: [IKE] add IPsec SA[3]
2015/10/27 16:31:33: [IKE] activate IPsec socket[tunnel:1](inbound)
2015/10/27 16:31:33: [IKE] activate IPsec socket[tunnel:1](outbound)
2015/10/27 16:31:33: IP Tunnel[1] Up
2015/10/27 16:31:48: [IKE] inactivate context [6287] d213908fe8ce2e86 64d1b08a
2015/10/27 16:31:49: [IKE] delete IPsec context [6287] d213908fe8ce2e86 64d1b08
a

Linux 側からのときと同様にして、IPsec VPN セッションの確立を確認する。まずは、RTX1100 で traceroute 172.26.0.107 noresolv -sa 172.26.200.250 コマンドを実行する。traceroute コマンドに -sa オプションを付けたので、この通信パケットのソース アドレスは 172.26.200.250 になる。

traceroute 172.26.0.107 noresolv -sa 172.26.200.250
1  172.26.0.107        2.165 ms        1.495 ms        1.491 ms

途中経路にあたる機器の反応が無いので、172.26.200.250 から 172.26.0.107 への通信は、VPN セッションを通じていると判断できる。念のために -sa オプションを外しても試す。今度はソース アドレスが宛先に最も近いインターフェースのアドレスである 172.26.255.250 になる。

traceroute 172.26.0.107 noresolv
1  172.26.255.2        0.992 ms        0.863 ms        0.948 ms
2  172.26.0.107        1.609 ms        1.351 ms        1.168 ms

見ての通り途中経路にある 172.26.255.2 が表示され、セッション内を通らない経路だと確認できた。

ついで、Linux で traceroute -n 172.26.200.250traceroute -n 172.26.255.250 コマンドを実行する。

traceroute -n 172.26.200.250
traceroute to 172.26.200.250 (172.26.200.250), 30 hops max, 60 byte packets
 1  172.26.200.250  3.555 ms  3.790 ms  4.450 ms
traceroute -n 172.26.255.250
traceroute to 172.26.255.250 (172.26.255.250), 30 hops max, 60 byte packets
 1  172.26.0.1  0.387 ms  0.617 ms  0.632 ms
 2  172.26.255.250  2.507 ms  2.747 ms  3.007 ms

残りの課題

Linux の Openswan と YAMAHA RTX シリーズ ルーターで、両端固定 IP アドレスのメイン モードでの IPsec VPN が構築できるようになった。しかし、アグレッシブ モードや、NAT Traversal を有効にした IPsec VPN セッションは、未だ確立に至っていない。残念ながら気力が尽きたので、とりあえず検証作業はこれで一区切りとする。

Comments