京都大学における IKEv2 サービスの構築
針木 剛 1)
1) 京都大学 企画・情報部
hariki.tsuyoshi.3r@kyoto-u.ac.jp

IKEv2 service construction in Kyoto University
HARIKI Tsuyoshi1)1) Information Dept., Kyoto Univ.

概要
京都大学では新たな VPN サービスとして IKEv2 サービスを開始した。サービス開始にあたり幾つかの VPN 技術を比較検討し IKEv2 の新サービス構築を選択した。本稿では構築時の技術課題とその解決のために得られた知見の情報共有を目的として詳細内容をまとめる。

1 はじめにイベートアドレス「KUINS-III」と、学外への通信や学外公開のためのグローバルアドレス「KUINS-II」を運現在京都大学では学外からの安全な通信経路の提用している。教職員は希望に応じて「KUINS-DB」[2]

供を目的として幾つかの VPN サービスを提供してと呼ばれる Web フォームからそれらを利用申請し、いる。VPN サービスを提供し始めた 2005 年度当時

申請内容を保存したデータベースの内容を適宜ネッ

Windows 端末で安定動作が可能であった PPTP サー

トワーク機器の設定に反映することで運用を行っていビスを選択し、学内限定の事務手続きサイトや接続元る。また大学を地理的に 10 構内に分割し各構内にメが大学の IP アドレスに限定される電子ジャーナルのインの L3 スイッチを配置し大学全体を束ねるルータ

閲覧など多くの教職員や学生など学内関係者に利用さでそれぞれのルーティングを管理する構成となっていれてきた。

る。各構内で利用する VLAN 数が多いため構内メイ一方で PPTP 接続時の GRE プロトコルが利用者環ンの L3 スイッチごとに独立した VLAN 番号を割り境によって制限されている場合もあり、その代替策と当てている。そのため VLAN 番号とは別に学内で一して 2012 年度に TCP のみで利用できる SSTP サー

意の値となる「VLAN 管理番号」を別途割り当ててビス及び OpenVPN サービスを開始した。

「KUINS-DB」で管理している。

その後 PPTP サービスは安定運用を継続しながら、研究室や事務室などの閉じた VLAN(以下研究室VLAN とする) へ直接接続できる機能や国立情報学研究所 (NII) のクライアント証明書による TLS 認証に対応する機能 [1] の追加など適宜改善を行い、2015年度には年間 220 万件を超える接続数があり大学として不可欠な情報サービスに成長した。しかしながら Apple 社が 2016 年 9 月に提供する新しい iOS やmacOS で PPTP を非サポートとする通知があり、これに伴い PPTP に代わる新たな VPN サービスの検討を行った。

図1

京都大学 IP アドレス利用

2 学内ネットワーク環境
京都大学では図 1 にあるように学内関係者が研究室

図 1 に あ る よ う に PPTP サ ー バ は 複 数 の NIC

VLAN でパソコンやプリンタを利用するためのプラで、学外から接続を受け付けるための KUINS-II と

PPTP クライアントに割り当てる KUINS-III、さらには標準非対応だが将来的な対応を期待して IKEv2 を一部の各研究室 VLAN の KUINS-III を持っている。

選択した。

PPTP サーバで研究室 VLAN へ接続したい利用者は「KUINS-DB」から当該 VLAN に接続可能な全学アカ
ウントを登録申請し、その情報を定期的に PPTP サーバに反映している。

3 VPN サービス比較検討

4 システム構築
4.1 システムの動作詳細
新規構築する IKEv2 サービスでのネットワーク利用方法を図 2 に示す。利用者のクライアント PC から IKEv2 サーバの KUINS-II へのアクセスに対し、PPTP 代替サービスを検討するため、現在提供中のIKEv2 サーバは自サーバ内の radius サービスに問いサービス PPTP、SSTP、OpenVPN に加えて新たに合わせ全学アカウントとパスワード認証または NII のL2TP/IPsec、IKEv2 を対象にそれぞれの優位点の比

クライアント証明書認証を行い、承認されるとクライ較を行った。

アント PC に KUINS-III アドレスを割り当てる。

表 1 に利用者のネットワーク環境で通す必要のある

IKEv2 サーバでは予め割当 KUINS-III のセグメンプロトコルやポート番号をまとめた。PPTP は GRE

トに対し下記のようなルーティング及び NAT を設定が必要となるため利用者環境で制限されている場合がしておく。

あり、そのような利用者の受け皿として TCP だけで動作する SSTP と OpenVPN という位置付けでサービス提供をしている。L2TP/IPsec と IKEv2 は IPsecであるため ESP が必要だがこれは UDP/4500 で代替可能である。
表 1 VPN に必要なプロトコルやポート番号比較
PPTP
SSTP
OpenVPN
L2TP/IPsec
IKEv2• 学外へのアクセスは KUINS-II の NIC を経由しSNAT して接続
• 学内へのアクセスは KUINS-III の NIC を経由してそのまま接続
これにより学外へは KUINS-II、学内へは割当 KUINS-

III からのアクセスとなる。

△ (1703/TCP と GRE)◎ (443/TCP)○ (1194/UDP または TCP)
○ (500/UDP と (ESP または 4500/UDP))○ (500/UDP と (ESP または 4500/UDP))

また表 2 に標準 OS での対応一覧をまとめた。利用者の手間を最小限にするために極力クライアント OS標準対応しているものが望ましい。SSTP と Open-VPN は標準 OS でのサポートが不足しており、メインではなく従来通り補助的なサービスとしての提供すべきと判断した。

図2

一般的なネットワーク利用方法

表 2 VPN クライアント OS 標準対応比較
WindowsmacOSiOS
Android
PPTP
○××
○
SSTP
○×××
OpenVPN
△*1
△*1
△*1
△*1
2
L2TP/IPsec○○△*○
IKEv2○○○△*1*1 別途アプリが必要 *2 クライアント証明書認証不可また macOS と iOS では標準が IKEv2 に変わり一また図 3 に IKEv2 サービスで研究室 VLAN への接続を試みた場合のネットワーク利用方法を示す。利用者は全学アカウントに VLAN 管理番号を付与した IDにより認証を行う。radius サービスで承認され、なおかつ KUINS-DB から定期的に取得している ID とVLAN 許可リストに符合した場合には、当該クライア
ント KUINS-III に限り以下のようなルーティングに変更する。

方で L2TP/IPsec は iOS でクライアント証明書非対応のままである点から、今後は IKEv2 を推奨するように見える。比較的新しいプロトコルのため Android• 学内へのアクセスは研究室 VLAN の KUINS-IIIの NIC を経由して SNAT して接続

ルアドレスとして、ens2 はクライアント用 KUINS-III、VLAN 番号が付与された ens3 は研究室 VLANの KUINS-III アドレスとしている。研究室 VLAN のルーティング名には VLAN 管理番号を使用した。
表4

ネットワークインターフェース例示

デバイス

図3

研究室 VLAN 接続のネットワーク利用方法

IP アドレス
192.0.2.1
10.1.0.251
10.2.0.253
10.2.1.253

ゲートウェイ

ルーティング

ens1
ens2
ens3.1ens3.2

192.0.2.254
10.1.0.254
10.2.0.254
10.2.1.254

gwk2
gwk3
gw123456
gw123457：：：：

デフォルトゲートウェイは KUINS-II のゲートウェ
イアドレスとしているが各 NIC のゲートウェイも同様にルーティングテーブルに設定する。具体的には設ここで利用者に対し各研究室 VLAN の KUINS-III
ではゲートウェイアドレスを含む幾つかの IP アドレスが利用不可である旨通知済みである。研究室 VLANのブロードキャストアドレスの 2 つ前も利用不可としたアドレスの 1 つで、このアドレスを事前に IKEv2サーバに割り当てておく。予め送信元アドレスが割当

KUINS-III でこのインターフェースから出力されるパケットは SNAT するような設定としておく。これにより学外へは一般利用と同様の KUINS-II だが、学内定 1 による。
設定 1

ルーティング設定- -/ etc / sysconfig / network - scripts / route - ens2 - 10.1.0.0/24 dev ens2 src 10.1.0.251 table gwk3
default via 10.1.0.254 table gwk3
- -/ etc / sysconfig / network - scripts / route - ens3 .1 - 10.2.0.0/24 dev ens3 .1 src 10.2.0.253 table gw123456
default via 10.2.0.254 table gw123456- -/ etc / sysconfig / network - scripts / route - ens3 .2 - 10.2.1.0/24 dev ens3 .2 src 10.2.1.253 table gw123457
default via 10.2.1.254 table gw123456- -/ etc / iproute2 / rt_tables - 200
gwk3
123456 gw123456
123457 gw123457

へは研究室 VLAN のブロードキャストアドレスの 2

さらにデフォルトのルーティングルールを追加設定

つ前の KUINS-III に変換されアクセスするようになしておく。VPN クライアントから学内へのルーティり、当該研究室 VLAN への接続が可能となる。また

ング VPN クライアントのセグメントのゲートウェイ

当該研究室 VLAN のネットワークアドレスに制限さに向かうように設定しておく。ここで優先順位はデれた各種電子リソースへのアクセスも可能となる。

フォルトのルーティング (32766) よりは高い値に設定

4.2 サーバのシステム構成と各種設定

するが、新しいルールが上位に追加しやすいようにな構築した IKEv2 サーバのシステム構成を表 3 に示るべく低い値 (30001) とする。

す。全て RHEL7 標準または EPEL 拡張パッケージ
設定 2を用いて構成している。

ルーティングルール設定- -/ etc / sysconfig / network - scripts / rule - ens2 - from 10.1.0.0/24 to [ 全 学 内 ] table gwk3 priority 30001

表3

IKEv2 サーバのシステム構成

また SNAT の設定も事前に設定しておく。設定 3機能

ソフトウェア名バージョン

OSIKEv2
radiusLinuxstrongswan
freeradiusiproute2iptablesfirewalld

3.10.05.4.0
3.0.4
3.10.01.4.21
0.3.9

ルーティングSNAT とIP フォワード

サーバは仮想マシンで構築し KUINS-II、クライアント用 KUINS-III 及び各構内のメインスイッチにより QinQ に集約された研究室 VLAN を引き込み NICに適切な IP アドレスを設定する。ここで仮の設定
例を表 4 にまとめる。ens1 は KUINS-II のグローバの 4 行目最初の設定は VPN クライアントが学外接続するための KUINS-II への変換であり、それ以下は各研究室 VLAN へ接続するための研究室 KUINS-III への変換となっている。
設定 3 SNAT 設定- -/ etc / firewalld / direct . xml - <? xml version = " 1.0 " encoding = " utf -8 " ? >< direct >< rule priority = " 0 " table = " nat " ipv = " ipv4 " chain = " POSTROUTING ">-s 10.1.0.0/24 -o ens1 -j SNAT --to - source 192.0.2.1 </rule >< rule priority = " 0 " table = " nat " ipv = " ipv4 " chain = " POSTROUTING ">-s 10.1.0.0/24 -o ens3 .1 -j SNAT --to - source
10.2.0.253 </ rule >< rule priority = " 0 " table = " nat " ipv = " ipv4 " chain = " POSTROUTING ">-s 10.1.0.0/24 -o ens3 .2 -j SNAT --to - source
10.2.1.253 </ rule >:</ direct >次に strongswan を動作させるためのカーネルパラメータを設定 4 のように設定する。
設定 4

カーネルパラメータ設定- -/ etc / sysctl . conf - net . ipv4 . ip_forward = 1
net . ipv4 . i p_ no _ pmtu_disc = 1
net . ipv4 . conf . all . a ccept_redirects = 0
net . ipv4 . conf . default . accept_redirects = 0
net . ipv4 . conf . all . send_redirects = 0
net . ipv4 . conf . default . send_redirects = 0
net . ipv4 . conf . all . rp_filter = 0
net . ipv4 . conf . default . rp_filter = 0strongswan の設定を設定 5 にまとめる。クライアントの認証は同じサーバ内の radius サービスで行う。freeradius の設定は割愛するが全学アカウントへ設定 6 updown スクリプトへの追加## VLAN gateway setup
if expr " $P L UT O_ X AU T H_ ID " : ’ ^.\+ @ [0 -9]\+ $ ’ > / dev / null
thenVLANGW = ‘ grep " ^ $ P L U T O _ X A U T H _ I D $ " $USERLIST | cut - d@ -f2 ‘
if [ $VLANGW ]thenip rule add from $ P L U T O _ P E E R _ C L I E N T to [ 全 学 内 ] lookup
gw$VLANGWlogger -t $TAG -p $FAC_PRIO \" added ip rule gw$VLANGW from $ P L U T O _ P E E R _ C L I E N T by
$P LU T O_ X AU TH _ ID "elselogger -t $TAG -p $FAC_PRIO \" $ PL UT O _X A UT H_ I D VLAN and ID pair is not valid "fifi

5 構築時の問題の LDAP でのパスワード認証と NII クライアント証

今回の構築時に下記の問題が発生し対応した。

明書を用いた TLS 認証を設定しておく。TLS 認証• VPN 接続後に特定の学内サイトだけ閲覧不可との際の注意点として Subject から他大学で発行されなる現象が発生し、これは設定 4 のカーネルパラた証明書は拒否するような設定が必要となる。また

メータ net.ipv4.ip no pmtu disc で Path MTU

strongswan の追加ルーティングは利用しない設定とDiscovery を有効にすることで解決できた。特定し、未使用で空となったルールの優先順位も新しく追サイトからのパケットは IKEv2 サーバまで届く

加するルールのために値を下げておく (30000)。

ことは確認できたため、最後に UDP にのせてク

設定 5 strongswan の設定- -/ etc / strongswan / ipsec . conf - conn % default
keyexchange = ikev2
conn kuins
auto = add
left =192.0.2.1
leftsubnet =0.0.0.0/0
leftauth = pubkey
leftcert =[ 証 明 書 フ ァ イ ル 名 ]leftfirewall = yes
leftid =[ サ ー バ FQDN ]leftsendcert = always
right =% any
rightsourceip =10.1.0.10 -10.1.0.250
rightauth = eap - radiusrightsendcert = never
eap_identity =% any- -/ etc / strongswan / ipsec . secrets - : RSA [ 秘 密 鍵 フ ァ イ ル 名 ]- -/ etc / strongswan / strongswan . d / charon . conf - charon {dns1 = [ D N S キ ャ ッ シ ュ サ ー バ ア ド レ ス 1 ]dns2 = [ D N S キ ャ ッ シ ュ サ ー バ ア ド レ ス 2 ]insta ll_routes = nor o u t i n g _ t a b le _ pr i o = 30000}- -/ etc / strongswan / strongswan . d / charon / eap - radius . conf - eap - radius {load = yes
servers {server1 {address = 127.0.0.1
secret = [ secret ]}}}ライアントへ届ける際にフレームサイズが大きく届かなかったことが原因かと思われる。

• macOS や iOS クライアントで接続すると 8 分で接続断となってしまう現象が発生したが、これは暗号強度を別途指定していたことが原因で、より強度の高い strongswan のデフォルト値に戻すことで解決できた。

6 まとめ• VPN サービスを比較検討した結果、新たに IKEv2サービスを選択しシステム構築を行った。

• パスワード認証とクライアント証明書認証の両者をサポートし、更に各研究室 VLAN へ直接接続できる機能も実装した。

• Apple 社の新 OS での PPTP 停止時期にあわせて 2016 年 9 月よりサービスの提供を開始した。

最後に接続時と切断時に動作する strongswan のupdown スクリプトの up-client にルーティングルー参考文献

ル追加の設定 6 を追加する。ここで$USERLIST の[1] NII 学術情報基盤オープンフォーラム 2016

ファイル内には KUINS-DB で申請された全学アカウ「京都大学でのクライアント証明書の利用サービス

ント＠ VLAN 管理番号の一覧が記述されており、定と学内申請受付システムの紹介」古村隆明 2016 年

期的に更新している。これにより$USERLIST に登録[2] 第 34 回全国共同利用情報基盤センター研究開発連済みの ID で認証があった場合は VPN クライアント合発表会

IP アドレスに対しルーティングルールが新たに追加「京都大学学術情報ネットワークシステム接続機器されその VLAN 管理番号の研究室への接続が可能に管理システム（KUINS-DB）の更新」高見好男, 平なる。また down-client には反対にルールを削除する

田光英, 富浦雅雄, 西村知子, 四方敏明, 宮崎修一,

スクリプトを追加しておく。

古村隆明, 岡部寿男 2012 年