今回はAWS SitetoSite VPNとLibreSwanに関する記事です。
AWSのVPN対向側にAzureを利用しています。
主に以下を説明する記事を書いていきます。
- 本記事のターゲット
- 構成図
- Libreswanを利用することのメリット
- Azureリソースの配置
- AWSリソースの配置
- LibreSwanのインストールと設定
- 疎通確認
- 最後に
【AWS】【Azure】LibreSwanを使ってAWS Site-to-Site VPN 接続を試してみる
本記事のターゲット
単純にAWS VPC間を接続したいだけであればVPC Peeringを利用するのが
一番シンプルで低コストです。
しかしながらSitetoSite VPNを利用した場合ルーティング制御は
どんなふうになるのか？どのようにすればよいか？
など検証したいときがあると思います。
また、VPC to VPCではなく、他のパブリッククラウドとの構成を検証したいので
AWS VPC to Azure Vnetなどの構成をとりたいケースもあると思います。
そんなときAWSのSitetoSite VPNを試してみたいけど、
家や会社に業務用のルータがない！
そういった方に向けて本記事を作成していきます。
構成図
今回は以下のようなAWS to Azureの構成を作成します。
ちなみにAWS SitetoSite VPNとAzure VPNは以下記事のように
直接接続することもできます。
AWSとAzure間でSite-to-Site VPNを張る
Libreswanを利用することのメリット
上記のリンクでよくない？と思った方！
確かにAWS to Azureの構成であればそれで問題ないですが
他にもメリットはありますのでご紹介します。
メリット１：汎用性の高さ
各パブリッククラウドには各々でインターネットVPNサービスが
提供されておりますが、
それぞれクセや仕様があるので利用するにあたり
それらを把握することが必要になってきます。
Libreswanの場合、RHELの仮想マシンさえ利用できるなら
どのクラウドでも実装可能なことが最大の強みです。
メリット２：学習コストの一本化
とりあえずLibreswanの設定方法だけ把握できていればよいので、
VPN装置の代替として
CiscoのASAvやYamahaのVRX、果てはVyOSやVyatta
などの操作方法をわざわざ覚えなくてよいこともメリットといえます。
※これらのVMを生成するときは適応インスタンスサイズなど決まっていたりする
メリット３：慣れ親しんだLinuxで環境準備できる
そもそもLinux触ったことないという方もいると思いますので
これにはメリットを感じない人もいるかもしれません。
ただ、世の中的にはVyOSやVyattaの利用経験を問われるより、
Linuxの利用経験を問われることのほうが圧倒的に多いです。
※ちなみに筆者はお客さんからVyOSやVyattaの知見があるか確認されたことありません。
メリット４：ランニングコストが安価
大まかにAWS SitetoSite VPNが月額5000円程度、
Azureも同程度といったふうにそこそこの利用料が必要となってきます。
これと比較して、最小スペックのVMを生成し日中帯だけ稼働させるなど
の方法をとればだいぶ利用料金を抑えることができます。
1日未満の接続検証ではなく数カ月単位など
長期間環境を維持したい場合は選択肢になりえるでしょう。
Azureリソースの配置
まずはAzureのリソースを配置します。
| リソース種類 | 指定パラメータ | 備考 |
| リソースグループ | Addache-Test | |
| Vnet | 10.10.1.0/24 | Vnet名:Addache-Test |
| サブネットA | 10.10.1.0/26 | RHEL VMの配置サブネット |
| サブネットB | 10.10.1.64/26 | 疎通確認VMの配置サブネット |
| サブネットC | 10.10.1.128/26 | Bastion用のサブネット |
| ネットワーク インターフェースA | 10.10.1.10 | RHEL VMのプライベートIP |
| ネットワーク インターフェースB | 10.10.1.70 | 疎通確認VMのプライベートIP |
| パブリックIP | 自動取得 | |
| Virtual Machine A | RHEL-VPN | RHEL VM |
| Virtual Machine B | Azure-SOTSU | 疎通確認VM(RHEL) |
＜手順＞ ※詳細手順は記事分割していますのでそちらをご参照ください。
①リソースグループの作成
②Vnetの作成
③サブネットの作成
④ネットワークインターフェース作成
※LibreswanをインストールするVM用には、忘れずIP転送を有効化する設定をしましょう
⑤パブリックアドレスの取得
⑥ルートテーブル
⑦VMの作成
⑧Bastionの配置
⑨NSGの設定
AWSリソースの配置
次にAWSのリソースを配置します。
リソース名と主要パラメータ
| リソース種類 | 指定パラメータ | 備考 |
| VPC | 10.10.2.0/24 | |
| サブネット | 10.10.2.0/26 | |
| ENI | 10.10.2.10 | |
| EC2 | AWS-SOTSU | AL2023 |
| カスタマーゲートウェイ | [AzureのパブリックIP] | |
| 仮想プライベートゲートウェイ | 特になし | |
| SitetoSiteVPN | ルーティング：静的 |
手順
①VPCの作成
②サブネットの作成
③カスタマーゲートウェイの作成
④VGWの作成
⑤SitetoSite VPNの作成
LibreSwanのインストールと設定
RHELのバージョン
今回使用しているRHELは以下です。
[root@RHEL-VPN ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 9.5 (Plow)AzureでRHELを使用するときのお作法①
知らないと使い始めるまでにいろいろ戸惑うことがあると思います。
まずyum update ができません。
エラーメッセージを確認しながら対処していくのですが、
以下よくあるパターン①：VMサイズが小さすぎてメモリ不足になる(Killed)
の対処方法です。
VMのサイズアップするのもよいですが、
メモリの代わりにスワップ領域を使う選択肢が手軽でいいと思います。(コストに跳ねないし)
dd if=/dev/zero of=/swapfile bs=1M count=4096
chmod 600 /swapfilemkswap /swapfile
swapon /swapfile
swapon -s
vi /etc/fstab
# -----------------------------------
# 末尾へ追記
/swapfile swap swap defaults 0 0
# -----------------------------------AzureでRHELを使用するときのお作法②
もうひとつ、こちらのほうがが比較的目にするかもしれません。
以下よくあるパターン②：デフォルトの/(ルートボリューム)割り当てがカツカツすぎる
At least 6MB more space needed on the / filesystem.AzureでRHELを(頻繁に)利用しない人は「あーまたこれか」
ってなると思います。筆者がそうです。速攻忘れます。
以下のサイトに記述されている手順を参考に、/ (ルートボリューム)を拡張します。
RHELでホームフォルダの拡張
# rootvgボリュームグループに残っているスペースを確認
vgdisplay -v rootvg | grep Free
# 5Gほど拡張
lvextend -L +5G /dev/mapper/rootvg-rootlv
# ファイルシステムを拡張
xfs_growfs -d /dev/mapper/rootvg-rootlvAzureでRHELを使用するときのお作法③
もうひとつ、お作法があります。
それはFirewalldと、selinuxの無効化です。
今回はただ単に疎通確認したいだけなので無効化してしまいますが、
本番運用するVMへ設定する場合は十分留意し、適切なセキュリティ設定を施してください。
Firewalldの無効化
systemctl stop firewalld
systemctl disable firewalldselinuxの無効化
grubby --update-kernel ALL --args selinux=0
reboot再起動すると適用されます。
再起動後はgetenforce を打鍵して応答を確認しましょう。
パッケージのインストール
はい、ここまで長かったですね！
とりあえずyum updateとLibreswanのインストールを済ませてしまいます。
yum -y update
yum -y install libreswan
systemctl restart ipsecLibreswanのエラーチェック
Libreswanを起動するとき、エラーになっている個所をチェックします。
[Failed] や[NOT DISABLED]がなければよいです。
ipsec verify
# ---------------------------------------------------------------------------
Verifying installed system and configuration files
Version check and ipsec on-path [OK]
Libreswan 4.15
Checking for IPsec support in kernel [OK]
NETKEY: Testing XFRM related proc values
ICMP default/send_redirects [NOT DISABLED]
Disable /proc/sys/net/ipv4/conf/*/send_redirects or XFRM/NETKEY will act on or cause sending of bogus IC
MP redirects!
ICMP default/accept_redirects [NOT DISABLED]
Disable /proc/sys/net/ipv4/conf/*/accept_redirects or XFRM/NETKEY will act on or cause sending of bogus
ICMP redirects!
XFRM larval drop [OK]
Pluto ipsec.conf syntax [OK]
Checking rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/default/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/eth0/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/ip_vti0/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/lo/rp_filter [ENABLED]
rp_filter is not fully aware of IPsec and should be disabled
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for IKE/NAT-T on udp 4500 [OK]
Pluto ipsec.secret syntax [OK]
Checking 'ip' command [OK]
Checking 'iptables' command [OK]
Checking 'prelink' command does not interfere with FIPS[OK]
Checking for obsolete ipsec.conf options [OK]
ipsec verify: encountered 11 errors - see 'man ipsec_verify' for help大抵何かしらの出力があります。末尾でどれだけNG箇所があるか教えてくれてますね。
エラーになる箇所の修正
そういうわけで、Systemdの一部を修正しましょう。
vi /etc/sysctl.conf
# --------------------------------------------------------------
# Disable /proc/sys/net/ipv4/conf/*/send_redirects
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.eth0.send_redirects=0
net.ipv4.conf.ip_vti0.send_redirects=0
net.ipv4.conf.lo.send_redirects=0
# Disable /proc/sys/net/ipv4/conf/*/accept_redirects
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.eth0.accept_redirects=0
net.ipv4.conf.ip_vti0.accept_redirects=0
net.ipv4.conf.lo.accept_redirects=0
# Two or more interfaces found, checking IP forwarding [FAILED]
net.ipv4.ip_forward=1
# Checking rp_filter
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.eth0.rp_filter=0
net.ipv4.conf.ip_vti0.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
上記追加後は以下のコマンドで反映、再確認をして
[OK]が並ぶようになるまで頑張ります。
※まだ何かしら出力された場合は修正してください
sysctl -p
ipsec verifyこんな状態になればOKです。
何かダメなら末尾にエラー出力が出てきます。
Verifying installed system and configuration files
Version check and ipsec on-path [OK]
Libreswan 4.15
Checking for IPsec support in kernel [OK]
NETKEY: Testing XFRM related proc values
ICMP default/send_redirects [OK]
ICMP default/accept_redirects [OK]
XFRM larval drop [OK]
Pluto ipsec.conf syntax [OK]
Checking rp_filter [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for IKE/NAT-T on udp 4500 [OK]
Pluto ipsec.secret syntax [OK]
Checking 'ip' command [OK]
Checking 'iptables' command [OK]
Checking 'prelink' command does not interfere with FIPS[OK]
Checking for obsolete ipsec.conf options [OK]IPSec設定ファイル編集
ここからIPSecの設定ファイルを編集していきます。
対象２つを順に編集していきます。
touch /etc/ipsec.d/vpn.conf
vi /etc/ipsec.d/vpn.conf
# --------------------------------------------------------------
conn IPSEC1
authby=secret
pfs=yes
auto=start
keyingtries=3
dpddelay=30
dpdtimeout=120
dpdaction=clear
keyexchange=ike
phase2=esp
encapsulation=yes
vti-interface=vti01
vti-routing=yes
rekey=yes
ike=aes256-sha1;modp1024
ikelifetime=28800s
keylife=1h
type=tunnel
mark=10/0xffffffff
left=10.10.1.10
leftid=A.A.A.A
leftsubnet=10.10.1.0/24
right=X.X.X.X
rightsubnet=10.10.2.0/24
rightid=X.X.X.X
conn IPSEC2
authby=secret
pfs=yes
auto=start
keyingtries=3
dpddelay=30
dpdtimeout=120
dpdaction=clear
keyexchange=ike
phase2=esp
encapsulation=yes
vti-interface=vti02
vti-routing=yes
rekey=yes
ike=aes256-sha1;modp1024
ikelifetime=28800s
keylife=1h
type=tunnel
mark=20/0xffffffff
left=10.10.1.10
leftid=A.A.A.A
leftsubnet=10.10.1.0/24
right=Y.Y.Y.Y
rightsubnet=10.10.2.0/24
rightid=Y.Y.Y.Y設定の途中にある
A.A.A.A
X.X.X.X
Y.Y.Y.Y
はそれぞれ以下から取得してください。
| 変数 | 取得する場所 | 備考 |
| A.A.A.A | [Azure]-[パブリックIP] | AWSのカスタマーゲートウェイにも同じ値を登録する |
| X.X.X.X | [AWS]-[SitetoSiteVPN]- [トンネルの詳細]-[Tunnel 1] | 自動設定される値 |
| Y.Y.Y.Y | [AWS]-[SitetoSiteVPN]- [トンネルの詳細]-[Tunnel 2] | 自動設定される値 |
IPSec事前共有鍵の登録
続いて、IPSec事前共有鍵の設定を行います。
[Tunnel 1 Key][Tunnel 2 Key]パラメータはAWSのSitetoSiteVPNを開いて、
[アクション]-[VPNトンネルオプションの変更]からそれぞれ確認します。
※ほかにも確認方法あります。
vi /etc/ipsec.d/vpn.secrets
# --------------------------------------------------------------
A.A.A.A X.X.X.X : PSK "Tunnel 1 Key"
A.A.A.A Y.Y.Y.Y : PSK "Tunnel 2 Key"IPSecサービス自動起動設定とサービス再起動
上記がひととおり完了したらサービス再起動していきます。
VPNがリンクアップしない場合は、
journalctl -xe を打鍵してエラーが出ていないか確認してください。
systemctl enable ipsec
systemctl restart ipsecルーティング自動追加サービス
トンネルの先にあるネットワーク経路を登録します。
以下手法は起動時登録されるようにサービス登録するものです。
vi /lib/systemd/system/rc-local-latest.service
# --------------------------------------------------------------
[Unit]
After=default.target
[Install]
WantedBy=default.target
[Service]
Type=forking
ExecStart=/etc/rc.local.latest自動起動を有効化します。
systemctl --system enable rc-local-latestルーティング自動追加サービスの内容設定
サービスの中身を設定します。[vti01]が優先されるようにメトリックを指定しています。
この[vti01][vti02]とは、VPN設定ファイルに記述しているものです。
ネーミングを編集した場合はこちらも忘れず編集してください。
vi /etc/rc.local.latest && chmod +x /etc/rc.local.latest
# --------------------------------------------------------------
#!/bin/bash
route add -net 10.10.2.0 netmask 255.255.255.0 metric 10 vti01
route add -net 10.10.2.0 netmask 255.255.255.0 metric 20 vti02ルーティング自動追加サービスの再起動
仕上げにサービス再起動を行います。
再起動後は
・妙なエラーが出ないこと
・routeコマンドで想定した経路が設定されているか
確認してください。
systemctl --system restart rc-local-latest疎通確認
最終的に疎通確認VM 10.10.1.70 (RHEL)から
以下のように疎通できればOKです。
[root@Azure-SOTSU ~]# ping 10.10.1.10
PING 10.10.1.10 (10.10.1.10) 56(84) bytes of data.
64 bytes from 10.10.1.10: icmp_seq=1 ttl=64 time=1.01 ms
64 bytes from 10.10.1.10: icmp_seq=2 ttl=64 time=1.25 ms
64 bytes from 10.10.1.10: icmp_seq=3 ttl=64 time=1.19 ms
64 bytes from 10.10.1.10: icmp_seq=4 ttl=64 time=1.36 ms
64 bytes from 10.10.1.10: icmp_seq=5 ttl=64 time=1.27 ms
Azureリソースグループ内では以下の作成を行いました。
最後に
いかがでしたでしょうか。
Libreswanの設定はヒントが少なく、OSディストリビューションなど条件を変えると
ハマることもありますが、冷静にエラーなどを追跡していけば
疎通できるようになります。
ディストリビューションによるトラブル
ちなみに筆者が今回RHEL9.5を採用してハマったポイントとしては
/etc/ipsec.d/vpn.conf の以下部分がエラーになったところでした。
NG ike=aes128-sha1;modp1024
OK ike=aes256-sha1;modp1024※RHEL7程度の環境では上記NGのほうで問題なかったのですが・・・
暗号化方式の部分なので、世の中的な時間経過につれより強度の高い、上位の暗号化方式を
選択しないとうまく動かなくなってしまうと思います。（OSがフォローをやめたなどの理由で）
opensslなど確認して該当方式を無理やり有効化する等
やり方はあると思いますが、今回のようなケースにおいては
素直により暗号強度の担保された新しいものを選択するのが無難と考えます。
困ったら以下公式サイトも確認してみましょう！
Libreswan VPN software
ネットワークインターフェースの転送設定
非常によく失念する部分ですが、AWS/Azureいずれにおいても
仮想マシンを通過させる設定をする場合は転送設定を忘れないようにしましょう。
Azureの場合
IP転送を有効 にします。
AWSの場合
ソース/宛先チェック を無効にします。
コメント