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

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

Openswan

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

検証環境

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

Connection diagram of the inspection environment

以前の検証で使用した環境はすでに破棄しており、改めて構築したため「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 コマンドの結果から「FAILED」をなくすには、以下のコマンドを実行して OS の設定を変更する。

先の 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」がなくなったことを確認する。

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

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

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

相互認証に使う事前共有鍵の値は、/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 コマンドでこれを作成する。

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

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

RTX1100 の設定

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

この 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 年前と異なるとは捉えなくても良い。

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

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

Linux 側から IPsec VPN を接続

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

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

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

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

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

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

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 を全て設定して、目一杯出力されるようにしてある。

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

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

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

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

残りの課題

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

コメントを残す