カテゴリー別アーカイブ: Ubuntu

Ubuntu に関すること

X.509 証明書による IPsec 認証 (libreswan)

libreswan を使って、IPsec の X.509 証明書認証を検証する。

検証環境は前回記事と同様で、以下の図の通りである。

vpn1、vpn2、host1、host2、router1 OS は全て Ubuntu 18.04 である。

1. 証明書の用意

libreswan で証明書を扱う場合、NSS Tools の流儀に従って管理しなければならない。strongswan のようにファイルベースでの証明書管理はできないようなので、少し不便である。

vpn1 側の NSS Tools でオレオレ CA を作って、vpn1・vpn2 両方の証明書をここで作成することにする。あとでエクスポートして vpn2 へ持っていく。

1.1 初期化

最初に、NSS ライブラリの証明書ストアを両サーバで初期化する。Ubuntu の場合は標準のパスが /var/lib/ipsec/nss になっている。

user@vpn1:~$ sudo rm -f /var/lib/ipsec/nss/*.db
user@vpn1:~$ sudo ipsec initnss
user@vpn2:~$ sudo rm -f /var/lib/ipsec/nss/*.db
user@vpn2:~$ sudo ipsec initnss

1.2 CA鍵・証明書の作成

次に、vpn1 上で CA 鍵と証明書のセットを作成する。以下のように certutil コマンドを使用する。
user@vpn1:~$ sudo certutil -S -k rsa -n ca -s "CN=ca.example.com" -v 120 -t "CT,C,C" -x -d sql:/var/lib/ipsec/nss

A random seed must be generated that will be used in the
creation of your key. One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full. DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!

Continue typing until the progress meter is full:

|************************************************************|

Finished. Press enter to continue:

Generating key. This may take a few moments...
途中で、乱数の種としてキーボードからの入力を求められるので、適当にランダム入力する。

コマンドラインオプションについては、それぞれ以下のような意味がある。
-S は鍵・証明書の生成とデータベース登録を指示する。
-k は鍵のタイプを指定する。ここでは RSA を使う。
-n は、この鍵/証明書の NSS ストア内でのニックネームを指定する。
-s は、CA の CN (コモンネーム) を指定する。適当に決めてよい。
-v は、証明書の有効期限を指定する。(単位: 月)
-t "CT,C,C" は、証明書の信頼属性を指定する。
3つのフィールドの最初は SSL、2番目はメール、3番目はオブジェクト署名の用途を表す。
C は CA、T はクライアント認証証明書発行のための CA を表す。
IPsec の認証以外にこの CA を使うことがなければ、C,, だけでも良い。
-x は、自己署名証明書にすることを指定する。
-d sql:/var/lib/ipsec/nss は、証明書ストアのパスを表す。sql: を付けておかないと libreswan から利用できないので注意。

1.3 ホスト鍵・証明書の作成

次に、vpn1 のホスト鍵/証明書セットを作る。途中でキーボードからの入力を求められるのは先ほどと同様である。
user@vpn1:~$ sudo certutil -S -k rsa -c ca -n vpn1 -s "CN=vpn1.example.com" -v 60 -t "u,u,u" -d sql:/var/lib/ipsec/nss

コマンドラインオプションについては以下の通り。
-c で、先ほど作成した CA 鍵 (ニックネームが “ca”) での署名を指定する。
-n は、この鍵/証明書の NSS ストア内でのニックネームを指定する。あとでこれを利用する。
-s は、証明書の CN (コモンネーム) を指定する。ここでは vpn1 の FQDN にしておく。
-t "u,u,u" は、証明書の信頼属性を指定する。u はユーザ証明書を表す。

さらに、同じ作り方で vpn2 用の鍵・証明書を作る。同様に、ランダムキー入力が求められる。
user@vpn1:~$ sudo certutil -S -k rsa -c ca -n vpn2 -s "CN=vpn2.example.com" -v 60 -t "u,u,u" -d sql:/var/lib/ipsec/nss

ここまでで CA と vpn1 と vpn2 の 3セットの鍵・証明書が作成できた。

1.4 vpn2 用の鍵と証明書をエクスポート・インポート

vpn2 の鍵・証明書と、CA 証明書をファイルへエクスポートして、vpn2 へ持っていく。鍵を含むファイルは PEM 形式でエクスポートする方法が無いので、PKCS#12 形式でエクスポートする。
user@vpn1:~$ sudo certutil -L -n ca -a -d sql:/var/lib/ipsec/nss > ca.pem
user@vpn1:~$ sudo pk12util -n vpn2 -o vpn2.p12 -d sql:/var/lib/ipsec/nss
Enter password for PKCS12 file: password (適当に決めた PKCS#12 ファイル用パスワード)
Re-enter password: password (再度入力)
pk12util: PKCS12 EXPORT SUCCESSFUL
user@vpn1:~$ sudo chown user vpn2.p12

エクスポートしたファイルを vpn2 へネットワークコピーする。
user@vpn1:~$ scp ca.pem vpn2.p12 vpn2:
user@vpn1:~$ rm ca.pem vpn2.p12

vpn2 側でインポートする。
user@vpn2:~$ sudo certutil -A -a -i ca.pem -n ca -t 'CT,,' -d sql:/var/lib/ipsec/nss
user@vpn2:~$ sudo pk12util -i vpn2.p12 -d sql:/var/lib/ipsec/nss
Enter password for PKCS12 file: password (先ほど決めたパスワード)
pk12util: PKCS12 IMPORT SUCCESSFUL
user@vpn2:~$ rm ca.pem vpn2.p12

2. libreswan の設定

2.1 vpn1 側

vpn1 の libreswan 設定を編集する。

user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
	authby=rsasig
	auto=add
	dpdaction=clear
	leftcert=vpn1
	leftid="CN=vpn1.example.com"
	left=198.51.100.100
	leftsubnet=10.0.1.0/24
	rightid="CN=vpn2.example.com"
	right=203.0.113.100
	rightsubnet=10.0.2.0/24

leftcert に vpn1 を指定する。これは vpn1 証明書を作成した時のニックネームを指定している。

leftid、rightid は、それぞれの端点の Peer ID である。証明書の CN フィールドをダブルクォーテーションで囲って指定する。

2.2 vpn2 側

vpn2 の方も同様に設定する。

user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
	authby=rsasig
	auto=start
	dpdaction=restart
	leftcert=vpn2
	leftid="CN=vpn2.example.com"
	left=203.0.113.100
	leftsubnet=10.0.2.0/24
	rightid="CN=vpn1.example.com"
	right=198.51.100.100
	rightsubnet=10.0.1.0/24

2.3 再起動

デーモンを再起動する。
user@vpn1:~$ sudo systemctl restart ipsec
user@vpn2:~$ sudo systemctl restart ipsec

2.4 確認

接続状態を確認する。

user@vpn1:~$ sudo ip xfrm state
src 203.0.113.100 dst 198.51.100.100
        proto esp spi 0xc8f7a785 reqid 16389 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xed85061c48c4fbc2dcce034191fb5a5a7c12d9e3 96
        enc cbc(aes) 0x7e39a613f56f3cb06b022561c0a8e65b
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 198.51.100.100 dst 203.0.113.100
        proto esp spi 0x90027aeb reqid 16389 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xf3fa1c2609590b83e4c9c95b1ad38d80492f267a 96
        enc cbc(aes) 0x9e039bf741f7a4c7a9e1920d241fae65
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

参考:
HOWTO: Using NSS with libreswan
certutilによる証明書管理 [Fedora14]

Linux サーバ間 IPsec 接続 (libreswan)

Linux サーバ同士の間で libreswan を使って IPsec を接続してみる。strongswan を使ったやり方は別記事にて。

I. 前提

環境は以下の通り。

vpn1、vpn2、host1、host2、router1 OSは全てUbuntu 18.04である。

vpn1←→vpn2の間で、libreswanでトンネルモードIPsec接続をする。10.0.1.0/24 から 10.0.2.0/24 へのパケット、またその逆方向のパケットはトンネルへ入るようにする。つまり、例えばhost1からhost2へpingを打つとトンネルを通ることになる。10.0.1.0/24や10.0.2.0/24へのスタティックルートはrouter1に追加しないようにしておくので、VPNトンネルが出来なければhost1からhost2へのpingは到達できない。

vpn2側に自動接続開始の設定を入れることで、VPNトンネルを自動的に張ることにする。

II. 設定

以下、設定を記述する(IPアドレス設定など基本的なところは省略)

1. router1 の設定:

通過パケットを転送できるように、カーネルパラメータを変更する。
user@router1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@router1:~$ sudo sysctl -p /etc/sysctl.conf

2. vpn1の設定:

libreswan をインストールする。このネットワーク構成ではインターネットからの apt install 不可なので、インターネット接続可能なネットワークに一時的に接続しておく。
user@vpn1:~$ sudo apt install libreswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。以下のように netplan 設定ファイルを編集する。
user@vpn1:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [198.51.100.100/24]
            gateway4: 198.51.100.1
        ens192:
            addresses: [10.0.1.1/24]

編集したら適用する。
user@vpn1:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn1:~$ sudo sysctl -p /etc/sysctl.conf

IPsecの事前共有鍵を設定する。
user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.secrets

: PSK "mypresharedkey"

一般ユーザで読めないようパーミッションを変えておく。
user@vpn1:~$ sudo chmod 600 /etc/ipsec.d/linux-to-linux.secrets

IPsecの接続設定を記述する。
user@vpn1:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
        authby=secret		# 共有鍵認証とする
        auto=add		# こちら側からはVPN接続を自動開始しない
        dpdaction=clear
        left=198.51.100.100	# 自ホストのIPアドレス
        leftsubnet=10.0.1.0/24	# 自分側のプライベートネットワーク
        right=203.0.113.100	# 対向側ホストのIPアドレス
        rightsubnet=10.0.2.0/24	# 対向側のプライベートネットワーク

デーモンを起動する。
user@vpn1:~$ sudo systemctl enable ipsec
user@vpn1:~$ sudo systemctl start ipsec

3. vpn2 の設定:

vpn1 と同様に、libreswan をインストールする。検証構成ではインターネットからの apt install 不可なのも vpn1 と同様である。一時的にインターネット接続可能なネットワークに接続しておく。
user@vpn2:~$ sudo apt install libreswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。
user@vpn2:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [203.0.113.100/24]
            gateway4: 203.0.113.1
        ens192:
            addresses: [10.0.2.1/24]

編集したら適用する。
user@vpn2:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn2:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn2:~$ sudo sysctl -p /etc/sysctl.conf

IPsec 事前共有鍵を設定する。
user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.secrets

: PSK "mypresharedkey"

一般ユーザで読めないようパーミッションを変えておく。
user@vpn2:~$ sudo chmod 600 /etc/ipsec.d/linux-to-linux.secrets

IPsec の設定を記述する。right/left を vpn1 側とは入れ換える。
user@vpn2:~$ sudo vi /etc/ipsec.d/linux-to-linux.conf

conn linux-to-linux
        authby=secret
        auto=start		# こちら側から VPN 接続を自動開始する
        dpdaction=restart
        left=203.0.113.100
        leftsubnet=10.0.2.0/24
        right=198.51.100.100
        rightsubnet=10.0.1.0/24

デーモンを起動する。
user@vpn2:~$ sudo systemctl enable ipsec
user@vpn2:~$ sudo systemctl start ipsec

これで完成。

III. 確認

ipsec status コマンドで、接続状況を確認できる。

user@vpn1:~$ sudo ipsec status
(snip)
000 #3: "linux-to-linux":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3326s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
000 #4: "linux-to-linux":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28526s; newest IPSEC; eroute owner; isakmp#3; idle; import:not set
000 #4: "linux-to-linux" esp.a61da06f@203.0.113.100 esp.53ec235d@198.51.100.100 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B

router1 で tcpdump を仕掛けておき、host1 から host2 あてに ping を打ってみる。
user@host1:~$ ping 10.0.2.100
user@router1:~$ sudo tcpdump -n -i ens192 not tcp port 22
15:27:34.103230 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xa61da06f,seq=0x1), length 132
15:27:34.103475 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0x53ec235d,seq=0x1), length 132
15:27:35.131026 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xa61da06f,seq=0x2), length 132
15:27:35.131271 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0x53ec235d,seq=0x2), length 132

ESPにカプセル化されてパケットが通過していることが確認できた。

※パケットがトンネルに入るか入らないかは、IP ルーティングではなく xfrm ポリシーによって決まっている。
ip xfrm policy コマンドで確認できる。

user@vpn1:~$ sudo ip xfrm policy
src 10.0.1.0/24 dst 10.0.2.0/24
        dir out priority 2344
        tmpl src 198.51.100.100 dst 203.0.113.100
                proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir fwd priority 2344
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir in priority 2344
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 16389 mode tunnel
(snip)

Ubuntu 18.04 + MariaDB

Ubuntu 標準パッケージの MariaDB を使うにあたってハマりそうな箇所を記述してみる。

DB root ユーザでの接続に失敗する

MariaDB/MySQL データベースを使い始めるときは、まず mysql_secure_installation コマンドで状態を初期化して root パスワードを設定するのが一般的だろう。そして、設定したパスワードを使って DB root 接続し、アプリケーション等に必要なデータベースや DB 一般ユーザを作成する。この手順を実行しようとすると、DB に root ログインできない (パスワード認証が通らない) という事象にぶち当たる。

user@bionic$ sudo mysql_secure_installation (初期化してrootパスワードを設定)
Set root password? [Y/n]y
New password: testpass01
Re-enter new password: testpass01
Remove anonymous users? [Y/n]y
Disallow root login remotely? [Y/n]y
Remove test database and access to it? [Y/n]y
Reload privilege tables now? [Y/n]y

user@bionic$ mysql -u root -p
Enter password: testpass01
ERROR 1698 (28000): Access denied for user 'root'@'localhost' ←認証エラー!

上記動作の原因は、初期状態の DB root ユーザ認証に unix_socket 認証プラグインが使われていることである。この状態では、DB root として接続するために OS の root 権限にならなければならない (sudo または su コマンドを使う)。OS root になっていれば、以下のようにパスワードなしで DB root として接続可能である。

user@bionic:~$ sudo mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 35
Server version: 10.1.29-MariaDB-6 Ubuntu 18.04

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

DB root でログインすると、認証プラグインの状態も確認できる。

MariaDB [(none)]> SELECT user,host,plugin from mysql.user;
+------+-----------+-------------+
| user | host      | plugin      |
+------+-----------+-------------+
| root | localhost | unix_socket | ← unix_socket 認証プラグインが使われている
+------+-----------+-------------+
1 row in set (0.00 sec)

さて、この認証方式をそのまま使うか?それとも昔ながらのパスワード認証に戻すか?

初期状態の認証設定でそのまま利用する

初期設定に乗っかっていくなら、DB の root パスワードを設定する必要がない。

また一般ユーザでも同一の仕組みを使う場合は、UNIX ユーザと DB ユーザを同名で作成すればよい。

(ただし、この認証方式では外部ホストから TCP/3306 経由でログインできないことになる。必ずローカルの UNIX ドメインソケット経由でなければならない)

以下はブログエンジン WordPress を「wordpress」というユーザ名で利用する場合の例。OS の wordpress ユーザを作り、DB の wordpress ユーザも作成する。

user@bionic:~$ sudo useradd -m -s /bin/bash wordpress
user@bionic:~$ sudo mysql
MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED VIA unix_socket;

wordpress ユーザで接続できるかどうか確認する。

user@bionic:~$ sudo -i -u wordpress
wordpress@bionic:~$ mysql -u wordpress
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 57
Server version: 10.1.29-MariaDB-6 Ubuntu 18.04

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> \q
Bye

このやり方では、WordPress のファイル群を実行する PHP の実行ユーザが wordpress ユーザである必要がある。例えば PHP 実行環境に php-fpm を使っている場合は、/etc/php/7.2/fpm/pool.d/www.confを編集して php-fpm 実行ユーザを wordpress に変更する。

/etc/php/7.2/fpm/pool.d/www.conf 抜粋

user = wordpress
group = wordpress

wordpressデータベースの作成

user@bionic:~$ sudo mysql
MariaDB [(none)]> CREATE DATABASE wordpress;
MariaDB [(none)]> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,INDEX,ALTER ON wordpress.* TO wordpress@localhost;

wordpress 側の設定 (wp-config.php) では、パスワードを空にしておく。

define('DB_NAME', 'wordpress');
define('DB_USER', 'wordpress');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');

従来のパスワード認証を使っていく場合

DB の root ユーザを従来のパスワード認証に変更する (以前の方式に戻す) 。私自身は、こちらの手法で行くことにする。

user@bionic:~$ sudo mysql
MariaDB [(none)]> set password for 'root'@'localhost'=password('testpass02');
MariaDB [(none)]> use mysql;
MariaDB [mysql]> update user set plugin='' where user='root';
MariaDB [mysql]> flush privileges;
MariaDB [mysql]> \q

root ユーザの認証プラグインを外し、通常のパスワードを設定している。

一般ユーザについても、通常のパスワードを設定して作成する。

user@bionic:~$ mysql -u root -p
Enter password: testpass02
MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED BY 'testpass03';

この場合、ログローテートの処理 (/etc/logrotate.d/mysql-server の16行目) にrootパスワードが必要になる。/etc/mysql/debian.cnf の password 行に平文パスワードを記述しておくこと。
user@bionic:~$ sudo vi /etc/mysql/debian.cnf

5行目、10行目
password = testpass02

Ubuntu 16.04 + MariaDB

※これは古い記事です。Ubuntu 18.04 の場合はこちら

※以下のサイトを参考に全面改訂しました(2017/09/12)
Ubunt 16.04でMariaDBをインストールするとパスワードが変

MySQL から MariaDB に移行するにあたって、パッケージが前提とする流儀が違ったり、罠があったりするので手当てをする。

1. DB root ユーザでの接続に失敗する

通常は最初に DB root ユーザで DB エンジンに接続して、Web アプリケーションの要求するデータベースやDBユーザを作成するだろう。これを実行しようとすると、OS の一般ユーザのコマンドラインから DB に root ログインできないという事象にぶち当たる。

user@xenial:~$ mysql -u root -p
Enter password:
ERROR 1698 (28000): Access denied for user 'root'@'localhost'

mysql_secure_installationで初期化を実行しても効果がない。

上記動作の原因は、初期状態の DB root ユーザ認証に UNIX ソケット認証プラグインが使われているためである。この状態では、DB root として接続するために OS root 権限にならなければならない (sudo または su コマンドを使う)。OS root になっていれば、以下のようにユーザ名指定なし・パスワードなしで DB root として接続可能である。

user@xenial:~$ sudo mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 42
Server version: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

DB root でログインすると、認証プラグインの状態も確認できる。

MariaDB [(none)]> SELECT user,host,plugin from mysql.user;
+------+-----------+-------------+
| user | host      | plugin      |
+------+-----------+-------------+
| root | localhost | unix_socket | ←unix_socket認証プラグインが使われている
+------+-----------+-------------+
1 row in set (0.00 sec)

2. 初期状態の認証設定でそのまま利用する

この初期設定に乗っかっていくなら、DB の root パスワードを設定する必要がない。

また一般ユーザでも同一の仕組みを使う場合は、UNIX ユーザと DB ユーザを同名で作成すればよい。

例) wordpress を「wordpress」というユーザ名で利用する場合

user@xenial:~$ sudo useradd -m -s /bin/bash wordpress (OS ユーザの作成)
user@xenial:~$ sudo mysql
MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED VIA unix_socket; (DB ユーザの作成)

wordpress ユーザで接続できるかどうか確認する。

user@xenial:~$ sudo -i -u wordpress
wordpress@xenial:~$ mysql -u wordpress
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 46
Server version: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> \q
Bye

※上記の方式でwordpressを動かす場合は、PHP の実行ユーザが wordpress ユーザである必要がある。例えば PHP 実行環境に php-fpm を使っている場合は、/etc/php/7.0/fpm/pool.d/www.confを編集して php-fpm 実行ユーザを wordpress に変更する。

※この認証方式では、TCP/3306 経由ではログインできないことになる。必ずローカルの UNIX ドメインソケット経由でなければならない。

3. 従来のパスワード認証を使っていく場合

DB の root ユーザを従来のパスワード認証に変更したい (以前の方式に戻す) 場合は、以下の手順を実行する。

user@xenial:~$ sudo mysql
MariaDB [(none)]> set password for 'root'@'localhost'=password('パスワード文字列');
MariaDB [(none)]> use mysql;
MariaDB [mysql]> update user set plugin='' where user='root';
MariaDB [mysql]> flush privileges;
MariaDB [mysql]> \q

root ユーザの認証プラグインを外し、通常のパスワードを設定している。この対処を実施した場合は、/etc/mysql/debian.cnf に平文パスワードを記述してやらないと systemctl での起動・停止が動作しなくなる。

user@xenial:~$ sudo vi /etc/mysql/debian.cnf
[client]
host     = localhost
user     = root
password = rootのパスワード文字列
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = root
password = rootのパスワード文字列
socket   = /var/run/mysqld/mysqld.sock

一般ユーザについても、通常のパスワードを設定して作成する。

MariaDB [(none)]> CREATE USER wordpress@localhost IDENTIFIED BY 'パスワード文字列';

4. localhost の 3306/tcp に接続できない

アプリケーションから localhost あてに接続すると、システム上 IPv6 (::1) が優先される。しかし MariaDB デフォルト設定の bind-address は 127.0.0.1 になっている。

このせいで、アプリケーションの設定で、DB サーバのホスト名 / IP アドレス指定を “localhost” にしてあると接続できない。アプリケーション側での DB サーバ指定を 127.0.0.1 とするか、MariaDB 側の設定ファイル /etc/mysql/mariadb.conf.d/50-server.cnf で bind-address を ::1 にする必要がある。

Ubuntu 14.04 + nginx で HTTP/2 サーバ

※以下は Ubuntu 14.04 用の内容です。Ubuntu 16.04 であれば、標準パッケージでHTTP/2が使えて、様々な機能が追加された nginx-extras が利用可能です。そちらを使いましょう。

nginx公式で配布されているmainlineバイナリを使えばHTTP/2は利用できるのだが、nginx-dav-ext-moduleが同時にコンパイルされておらずWebDAVが使い物にならないため、リビルドを実行する。

1. ビルド環境を準備する

開発環境をインストールする。

sudo apt-get install build-essential debhelper

nginxのビルドに必要なライブラリ・ヘッダをインストールする。

sudo apt-get install libpcre3-dev libxml2-dev libxslt1-dev libgd-dev libssl-dev libgeoip-dev

2. nginx公式のパッケージをapt-getで利用できるようにする

apt sourceとして登録する。

curl http://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo vi /etc/apt/sources.list.d/nginx.list

/etc/apt/sources.list.d/nginx.listファイル:

deb http://nginx.org/packages/mainline/ubuntu/ trusty nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ trusty nginx

3. ソースパッケージを取得してビルドする

sudo apt-get update
apt-get source nginx
cd nginx-1.9.12
git clone https://github.com/arut/nginx-dav-ext-module.git
vi debian/rules

nginx-1.9.12/debian/rulesファイル:

    --add-module=./nginx-dav-ext-module \ この行を追加

実際にビルドする。

dpkg-buildpackage -us -uc -b -d
cd ..

4. ビルドしたパッケージをapt-getでインストールする

ローカルのdebレポジトリを作成する。

sudo mkdir -p /usr/src/deb
sudo mv *.deb /usr/src/deb/
sudo bash
# cd /usr/src/deb
# apt-ftparchive packages . | gzip -c9 > Packages.gz
# apt-ftparchive sources . | gzip -c9 > Sources.gz
# exit
sudo vi /etc/apt/sources.list.d/local.list

/etc/apt/sources.list.d/local.listファイル:

deb file:/usr/src/deb/ ./

インストールを実行する。

sudo apt-get update
sudo apt-get install nginx

参考URL:
Ubuntu (Debian) で nginx に WebDAV拡張モジュール(ngx-dav-ext-module)を組み込むで使ってみる
Nginx で WebDAV 環境構築、PROPFIND 405 が使えなかったのでソースからコンパイルしてみた
ローカルに置いたdebファイルをapt-get installでインストールする
Nginxセキュリティ設定
Ubuntu+php5-fpm+mysql で LEMP 環境に WordPress をインストール
Let’s EncryptとnginxでHTTP/2サーバを立てる

AirPrint非対応のプリンタをUbuntuサーバ経由でAirPrint対応に

avahi-daemon (Apple Bonjour互換) を使ってプリンタ名を広告してやることによって、AirPrint非対応の旧世代プリンタをAirPrint対応にできるらしいので、実験してみた。

そのためには、Linux プリンタサーバ上に、iOS デバイスへプリンタ情報を教えるための avahi 設定が必要になる。

前の記事の内容で、既にUbuntu環境でプリンタの設定はできているものとする。

1. インストール

必要なパッケージをUbuntuデスクトップにインストールする。

desktop$ sudo apt-get install avahi-discover

2. 情報の取得

端末から、avahi-discover コマンドを実行する。標準出力にダンプされる情報を利用するので、ログファイルを取っておく。

desktop$ avahi-discover > log

表示された GUI ウインドウ上で、「Internet Printer」→「EPSON EP-802A @ myserver1」を選択する。その後、×ボタンで GUI を閉じる。

logファイルの内容を確認すると、末尾近くに以下のような行がある。

Host myserver1.local (192.168.100.240), port 631, TXT data: ['printer-type=0xB01E', 'printer-state=3', 'Duplex=T', 'Color=T', 'TLS=1.2', 'UUID=3ae710a1-2d56-928f-4a19-394a152d3eca', 'URF=DM3', 'pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/urf', 'product=(Epson EP-902A Series)', 'priority=0', 'note=Home', 'adminurl=https://myserver1.local:631/printers/EPSON-EP-802A', 'ty=Epson EP-802A Series - epson-inkjet-printer 1.0.0-1lsb3.2 (Seiko Epson Corporation LSB 3.2)', 'rp=printers/EPSON-EP-802A', 'qtotal=1', 'txtvers=1']

3. 情報ファイルの作成

上記の情報をもとに、avahi のサービス情報ファイルを作成する。

myserver1$ sudo vi /etc/avahi/services/AirPrint-EPSON-EP-802A.service
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">AirPrint EPSON-EP-802A @ %h</name>
<service>
 <type>_ipp._tcp</type>
 <subtype>_universal._sub._ipp._tcp</subtype>
 <port>631</port>
 <txt-record>txtvers=1</txt-record>
 <txt-record>qtotal=1</txt-record>
 <txt-record>rp=printers/EPSON-EP-802A</txt-record>
 <txt-record>ty=Epson EP-802A Series - epson-inkjet-printer 1.0.0-1lsb3.2 (Seiko Epson Corporation LSB 3.2)</txt-record>
 <txt-record>adminurl=https://myserver1.local:631/printers/EPSON-EP-802A</txt-record>
 <txt-record>note=Home</txt-record>
 <txt-record>priority=0</txt-record>
 <txt-record>product=(Epson EP-902A Series)</txt-record>
 <txt-record>pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/urf</txt-record>
 <txt-record>UUID=3ae710a1-2d56-928f-4a19-394a152d3eca</txt-record>
 <txt-record>TLS=1.2</txt-record>
 <txt-record>Color=T</txt-record>
 <txt-record>Duplex=T</txt-record>
 <txt-record>printer-state=3</txt-record>
 <txt-record>printer-type=0xB01E</txt-record>
 <txt-record>URF=none</txt-record>
</service>
</service-group>

ファイルができたら、サービスを再起動する。

myserver1$ sudo service avahi-daemon restart
myserver1$ sudo service cups restart

設定が終わったら、iOS デバイスのアプリケーション (例えばSafari) からテスト印刷する。「メニューボタン」→「プリント」を選択して、「プリンタ」に「EP-802A」が表示されたら選択して印刷してみる。自分の環境では、きちんと印刷できた。

参考URL: 今日はLinuxのCUPSプリントサーバをAirPrintサーバにして、iPhoneからAirPrintで印刷するとPDFファイルが生成されるようにしてみた

UbuntuでEPSONプリンタを使う

自分の場合は通常使わないのだが、念のためUbuntuサーバからも印刷ができるようにしてみた。
環境:
プリンタサーバ: Ubuntu 14.04 server (64bit) ホスト名 myserver1
操作用デスクトップ: Ubuntu 14.04 desktop (64bit) ホスト名 desktop
プリンタ: EPSON EP-802A
プリンタサーバ-プリンタ間接続形式: ネットワーク経由

1. プリンタドライバのダウンロード

EPSON Download Center でプリンタ型番をキーワードに検索し、ダウンロードする。
自分の環境の場合は、以下の4つをダウンロードした。
iscan-data_1.29.0-2_all.deb
iscan_2.29.3-1~usb0.1.ltdl7_amd64.deb
epson-inkjet-printer-ep-902a-series_1.0.0-1lsb3.2_amd64.deb
epson-inkjet-printer-escpr_1.4.1-1lsb3.2_amd64.deb

2. プリンタドライバのインストール

必要なパッケージをインストールする。

myserver1$ sudo apt-get install lsb xsltproc

さらに、ダウンロードしたファイルをインストールする。

myserver1$ sudo dpkg -i iscan-data_1.29.0-2_all.deb \
iscan_2.29.3-1~usb0.1.ltdl7_amd64.deb \
epson-inkjet-printer-ep-902a-series_1.0.0-1lsb3.2_amd64.deb \
epson-inkjet-printer-escpr_1.4.1-1lsb3.2_amd64.deb

3. CUPSの設定

今回の設定対象は X 環境の無いUbuntuサーバなので、他のマシン(Ubuntuデスクトップ)からリモートで設定したい。そのため、CUPSの設定を変更して同一ネットワークのマシンからはリモート管理ができるようにする。

myserver1$ sudo vi /etc/cups/cupsd.conf

以下、cupsd.confの編集内容をdiff -u形式で表示する。

@@ -13,11 +13,12 @@
 MaxLogSize 0

 # Only listen for connections from the local machine.
-Listen localhost:631
+#Listen localhost:631
 Listen /var/run/cups/cups.sock
+Port 631

 # Show shared printers on the local network.
-Browsing Off
+Browsing On
 BrowseLocalProtocols dnssd

 # Default authentication type, when authentication is required...
@@ -29,11 +30,13 @@
 # Restrict access to the server...
 <Location />
   Order allow,deny
+  Allow @LOCAL
 </Location>

 # Restrict access to the admin pages...
 <Location /admin>
   Order allow,deny
+  Allow @LOCAL
 </Location>

 # Restrict access to configuration files...
@@ -41,6 +44,7 @@
   AuthType Default
   Require user @SYSTEM
   Order allow,deny
+  Allow @LOCAL
 </Location>

 # Set the default printer/job policies...

サービスを再起動する。

myserver1$ sudo service cups restart

4. Ubuntu デスクトップからの設定

次にUbuntuデスクトップ側で、system-config-printerを使って先のサーバにリモート接続して設定を実施する。system-config-printerがインストールされていなければ、インストールしておく。

desktop$ sudo apt-get install system-config-printer-gnome

手元のUbuntu 14.04 Desktopでは、システム設定 (unity-control-center) にプリンタの設定アイコンが無かったので、端末から直接実行して GUI を起動した。

desktop$ system-config-printer

「サーバー」メニューから「接続」を選択して、「CUPSサーバー」欄にUbuntuサーバのIPアドレスを入力して接続する。

あとは「追加」ボタンを押して「ネットワークプリンター」の中から「Epson EP-802A (aa.bb.cc.dd)」、接続は「DNS-SD 経由の LPD ネットワークプリンター」を選択する。ドライバは自動検索され、高機能版が自動的に選ばれる。

設定が終わったら、テスト印刷を実行して確認する。

参考URL: Ubuntu Weekly Recipe 第286回 UbuntuからEPSON複合機EP-805Aを使用する

外部からVPSへのL2TP/IPsecとVPS-自宅間IPsecの組み合わせ

前回記事のリモートアクセスVPN (L2TP/IPsec) と、さらにその前の記事で構築済みのVPS-自宅間VPN (IPsec) を組み合わせて利用する。

これにより、動的IPアドレスの自宅へ、外部からいつでもログイン可能となる。

前提:
・サーバはすべて Ubuntu 14.04 LTS である。
・IPsec実装は strongswan を利用し、サーバ間はRSA証明書認証を行う。
・外部端末-VPS間はL2TP/IPsecとし、認証はIPsec事前共有鍵+L2TPのMSCHAPv2とする。

ネットワーク構成は以下の通り。
06

すでに記事としては前回前々回で記述している。
今回のポイントは、VPS への L2TP アクセスで割り振られる PPP IPアドレスを、VPS-自宅間IPsecのトンネルに入るよう設定することである。

1. myvps1 と myserver1 の /etc/sysctl.conf

$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す
# 以下、追記する
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.eth0.accept_redirects=0
net.ipv4.conf.eth0.send_redirects=0
net.ipv4.conf.lo.accept_redirects=0
net.ipv4.conf.lo.send_redirects=0
net.ipv6.conf.eth0.accept_redirects=0
net.ipv6.conf.lo.accept_redirects=0
vpn1:~$ sudo sysctl -p /etc/sysctl.conf

2. myserver1上にCAを作成し、myserver1用とmyvps1用の証明書・秘密鍵の組を作成する

前々回記事を参照。

myserver1 には
/etc/ipsec.d/cacerts/ca1.crt (CA証明書)
/etc/ipsec.d/certs/myserver1.crt (サーバ証明書)
/etc/ipsec.d/private/myserver1.key (サーバ秘密鍵)

myvps1 には
/etc/ipsec.d/cacerts/ca1.crt (CA証明書)
/etc/ipsec.d/certs/myvps1.crt (サーバ証明書)
/etc/ipsec.d/private/myvps1.key (サーバ秘密鍵)

以上のファイルを配置する。

3. strongswan の設定 (myserver1側)

/etc/ipsec.conf:

config setup セクションの後に以下の内容を追加する。rightsubnet に L2TP クライアントの IP アドレス領域を追加しておく。

conn myhome-to-vps
	authby=rsasig
	auto=start
	closeaction=restart
	dpdaction=restart
	left=192.168.100.240
	leftsubnet=192.168.100.0/24
	leftcert=myserver1.crt
	right=203.0.113.180
	rightsubnet=203.0.113.180/32,172.16.1.0/24 # ←L2TPのクライアントアドレスを追加
	rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myvps1.vpsnet.example.jp"

※strongswan だと leftsubnet / rightsubnet に複数のサブネットが記述できるが、openswan で複数サブネットの場合は leftsubnets / rightsubnets と書く必要がある。

/etc/ipsec.secrets:

: RSA myserver1.key

4. strongswan の設定 (myvps1側)

/etc/ipsec.conf:

config setup セクションの後に、以下の2つの記述を追加する。
myhome-to-vps の方の leftsubnet には、L2TP クライアントアドレス領域を追加しておく。

conn myhome-to-vps
	authby=rsasig
	auto=add
	closeaction=clear
	dpdaction=clear
	left=203.0.113.180
	leftsubnet=203.0.113.180/32,172.16.1.0/24 # ←L2TPのクライアントアドレスを追加
	leftcert=myvps1.crt
	right=%any
	rightsubnet=192.168.100.0/24
	rightid="C=JP, ST=Aichi, O=Home, OU=Server, CN=myserver1.domain.local"

conn L2TP-PSK
        authby=secret
        auto=add
        closeaction=clear
        dpdaction=clear
        type=transport
        rekey=no
        left=203.0.113.180
        leftprotoport=17/1701
        right=%any
        rightprotoport=17/%any

/etc/ipsec.secrets:
自宅IPsec用のRSA秘密鍵と、L2TP/IPsec用の事前共有鍵文字列を両方記述する。

: RSA myvps1.key
: PSK "mypresharedkey"

5. xl2tpd の設定 (myvps1側)

/etc/xl2tpd/xl2tpd.conf:

[global]
port = 1701

[lns default]
ip range = 172.16.1.11-172.16.1.30
local ip = 172.16.1.254
length bit = yes
require chap = yes
refuse pap = yes
require authentication = yes
name = myvps1.vpsnet.example.jp
ppp debug = no
pppoptfile = /etc/ppp/xl2tpd-options

/etc/ppp/xl2tpd-options:

ipcp-accept-local
ipcp-accept-remote
ms-dns 172.16.1.254  (myvps1にキャッシュDNSサーバが立っている前提)
noccp
auth
crtscts
idle 1800
mtu 1300
mru 1300
nodefaultroute
lock
connect-delay 5000
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2

/etc/ppp/chap-secrets:

username	*	"l2tppassworddesu"	*

一般ユーザで読めない権限にしておくこと。

6. サービス起動と確認

myserver1:~$ sudo service strongswan restart
myvps1:~$ sudo service strongswan restart
myvps1:~$ sudo service xl2tpd restart

milter-greylist で GeoIP を使えるようにする

※以下は古い記事です。Ubuntu 16.04 以降では libGeoIP がリンクされているため、必要ありません。

Ubuntu 14.04 標準パッケージの milter-greylist は libGeoIP をリンクするようにコンパイルされていないので、GeoIP (IPアドレスベースの国別判定) をポリシーに利用することが出来ない。そこで Ubuntu ソースパッケージを微修正してリビルドすることで GeoIP を使えるようにする。また、ついでにPostfixへの対応を入れておく。

必要なパッケージのインストール

myserver1:~$ sudo apt-get install build-essential quilt debhelper autotools-dev bison flex
myserver1:~$ sudo apt-get install libgeoip-dev libspf2-dev libmilter-dev

ソースパッケージのダウンロード

myserver1:~$ apt-get source milter-greylist

パッケージ情報ファイルの編集

GeoIP をリンクするように、パッケージ情報ファイルを編集する。

rules ファイルを編集し、configure オプションの中に –with-libGeoIP \ を追加する。configure 実行時に libGeoIP を探してくれるようになる。

myserver1:~$ cd milter-greylist-4.3.9
myserver1:milter-greylist-4.3.9$ vi debian/rules
override_dh_auto_configure:
    dh_auto_configure -- \
    --with-user=greylist \
    --sysconfdir=/etc/milter-greylist \
    --with-conffile=/etc/milter-greylist/greylist.conf \
    --with-dumpfile=/var/lib/milter-greylist/greylist.db \
    --with-libspf2=/usr \
    --with-libmilter=/usr \
    --with-libGeoIP \  ←ここを追加
    --enable-postfix \  ←ここを追加
    --enable-dnsrbl \
    --disable-rpath \
    LDFLAGS=" -Wl,-z,defs -L/usr/lib/libmilter " \
    CFLAGS=" -fno-strict-aliasing "

また、controlファイルを編集して、Build-Depends 行に libgeoip-dev を追加する。

myserver1:milter-greylist-4.3.9$ vi debian/control
Build-Depends: quilt, debhelper (>= 8), autotools-dev, libmilter-dev, bison, flex, libspf2-dev, libgeoip-dev

パッケージバージョン番号を変更するために、changelogも編集する。内容は適当。

myserver1:milter-greylist-4.3.9$ vi debian/changelog
milter-greylist (4.3.9-101) unstable; urgency=low

  * Build with --with-libGeoIP
  * Build with --enable-postfix

 -- My Name <myname@example.com>  Mon, 30 Jun 2014 10:00:00 +0900

バージョン番号を元のパッケージより大きくしておかないと、apt-get upgrade した時に公式パッケージで置き換えられてしまう。ここでは 4.3.9-1 から 4.3.9-101 にしておいた。

ビルド

編集が終わったら、実際にビルドする。

myserver1:milter-greylist-4.3.9$ dpkg-buildpackage -us -uc

インストール

.deb パッケージが出来上がったら、公式パッケージをアンインストールして入れ換える。

myserver1:milter-greylist-4.3.9$ sudo apt-get purge milter-greylist
myserver1:milter-greylist-4.3.9$ sudo dpkg -i ../milter-greylist_4.3.9-101_amd64.deb

設定

milter-greylist を入れ換えたら、/etc/milter-greylist/greylist.conf に geoip の記述が使えるようになる。例えば自宅のサーバでは、CN からメールを受け取る予定が無いのでこれをブラックリストに入れてみる。

myserver1:~$ sudo vi /etc/milter-greylist/greylist.conf

greylist.conf の中身:

geoipdb "/usr/share/GeoIP/GeoIP.dat"
...
racl blacklist geoip "CN"

Linux サーバ間 IPsec 接続 (strongswan)

Linux サーバ同士の間で通常の IPsec を接続してみる。IPsec 実装として strongswan と libreswan のどちらを使うかは好みによるが、この項では strongswan を利用する。libreswan古い openswan を使ったやり方は別記事にて。

I. 前提

環境は以下の通り。

vpn1、vpn2、host1、host2、router1 OSは全てUbuntu 18.04である。

vpn1←→vpn2の間で、strongswanでトンネルモードIPsec接続をする。10.0.1.0/24 から 10.0.2.0/24 へのパケット、またその逆方向のパケットはトンネルへ入るようにする。つまり、例えばhost1からhost2へpingを打つとトンネルを通ることになる。10.0.1.0/24や10.0.2.0/24へのスタティックルートはrouter1に追加しないようにしておくので、VPNトンネルが出来なければhost1からhost2へのpingは到達できない。

vpn2側に自動接続開始の設定を入れることで、VPNトンネルを自動的に張ることにする。

II. 設定

以下、設定を記述する(IPアドレス設定など基本的なところは省略)

1. router1 の設定:

通過パケットを転送できるように、カーネルパラメータを変更する。
user@router1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@router1:~$ sudo sysctl -p /etc/sysctl.conf

2. vpn1の設定:

strongswan をインストールする。このネットワーク構成ではインターネットからの apt install 不可なので、インターネット接続可能なネットワークに一時的に接続しておく。
user@vpn1:~$ sudo apt install strongswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。以下のように netplan 設定ファイルを編集する。
user@vpn1:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [198.51.100.100/24]
            gateway4: 198.51.100.1
        ens192:
            addresses: [10.0.1.1/24]

編集したら適用する。
user@vpn1:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn1:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn1:~$ sudo sysctl -p /etc/sysctl.conf

IPsecの事前共有鍵を設定する。
user@vpn1:~$ sudo vi /etc/ipsec.secrets

# 以下の行を追記
: PSK "mypresharedkey"

IPsecの接続設定を記述する。ファイルの最後あたりに追記する形にする。
user@vpn1:~$ sudo vi /etc/ipsec.conf

conn linux-to-linux
        authby=secret		# 共有鍵認証とする
        auto=add		# こちら側からはVPN接続を自動開始しない
        closeaction=clear
        dpdaction=clear
        left=198.51.100.100	# 自ホストのIPアドレス
        leftsubnet=10.0.1.0/24	# 自分側のプライベートネットワーク
        right=203.0.113.100	# 対向側ホストのIPアドレス
        rightsubnet=10.0.2.0/24	# 対向側のプライベートネットワーク

デーモンを再起動する。
user@vpn1:~$ sudo systemctl restart strongswan

3. vpn2 の設定:

vpn1 と同様に、strongswan をインストールする。検証構成ではインターネットからの apt install 不可なのも vpn1 と同様である。一時的にインターネット接続可能なネットワークに接続しておく。
user@vpn2:~$ sudo apt install strongswan

インストールが終わったら、ネットワーク構成を検証用の構成に戻す。
user@vpn2:~$ vi /etc/netplan/50-cloud-init.yaml

network:
    version: 2
    ethernets:
        ens160:
            addresses: [203.0.113.100/24]
            gateway4: 203.0.113.1
        ens192:
            addresses: [10.0.2.1/24]

編集したら適用する。
user@vpn2:~$ sudo netplan apply

カーネルパラメータを設定する。
user@vpn2:~$ sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1  #28行目のコメントを外す

上記カーネルパラメータを有効化する。
user@vpn2:~$ sudo sysctl -p /etc/sysctl.conf

IPsec 事前共有鍵を設定する。
user@vpn2:~$ sudo vi /etc/ipsec.secrets

# 以下の行を追記
: PSK "mypresharedkey"

IPsecの設定を記述する。right/leftをvpn1側とは入れ換える。
user@vpn2:~$ sudo vi /etc/ipsec.conf

conn linux-to-linux
        authby=secret
        auto=start		# こちら側からVPN接続を自動開始する
        closeaction=restart
        dpdaction=restart
        left=203.0.113.100
        leftsubnet=10.0.2.0/24
        right=198.51.100.100
        rightsubnet=10.0.1.0/24

デーモンを再起動する。
user@vpn2:~$ sudo systemctl restart strongswan

これで完成。

III. 確認

ipsec statusコマンドで、接続状況を確認できる。

user@vpn1:~$ sudo ipsec status
Security Associations (1 up, 0 connecting):
linux-to-linux[1]: ESTABLISHED 7 minutes ago, 198.51.100.100[198.51.100.100]...203.0.113.100[203.0.113.100]
linux-to-linux{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c90fad30_i c17db9d8_o
linux-to-linux{1}: 10.0.1.0/24 === 10.0.2.0/24

router1でtcpdumpを仕掛けておき、host1からhost2あてにpingを打ってみる。
user@host1:~$ ping 10.0.2.100
user@router1:~$ sudo tcpdump -n -i ens192 not tcp port 22
15:15:46.146244 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xc17db9d8,seq=0x1d), length 136
15:15:46.146569 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0xc90fad30,seq=0xd), length 136
15:15:47.169558 IP 198.51.100.100 > 203.0.113.100: ESP(spi=0xc17db9d8,seq=0x1e), length 136
15:15:47.170081 IP 203.0.113.100 > 198.51.100.100: ESP(spi=0xc90fad30,seq=0xe), length 136

ESPにカプセル化されてパケットが通過していることが確認できた。

※パケットがトンネルに入るか入らないかは、IP ルーティングではなく xfrm ポリシーによって決まっている。
ip xfrm policy コマンドで確認できる。

user@vpn1:~$ sudo ip xfrm policy
src 10.0.1.0/24 dst 10.0.2.0/24
        dir out priority 375423
        tmpl src 198.51.100.100 dst 203.0.113.100
                proto esp spi 0xc17db9d8 reqid 1 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir fwd priority 375423
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 1 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir in priority 375423
        tmpl src 203.0.113.100 dst 198.51.100.100
                proto esp reqid 1 mode tunnel
(snip)