こんばんは。ゆーろんです。
今回はIPsecVPNをAWS Lightsailを使って組もうとしたが、最終的には構築を断念した話をまとめます。
IPsec-VPNとは#
IPsecは1990年代に設計されたVPNプロトコル群のこと。
TCP/IPが本来持つセキュリティの脆弱性を補うため、インターネットが商用利用され始めた時代背景から設計された。
設計思想は、特定のアプリケーションに依存せず、ネットワーク層で通信全体を包括的に保護することにあった。
IPsecは、以下に示す複数のプロトコルで構成されており、この複雑性が、ベンダー間の実装の差異や、設定の難しさの要因となっている。
- IKE (Internet Key Exchange):
- IPsecで利用する暗号鍵を自動で安全に交換・管理するプロトコル。
- IKEv1とIKEv2があり、それぞれ2つのフェーズに分かれる。
- フェーズ1でピア間の認証を行い安全な通信路(IKE SA)を確立し、フェーズ2で実際のデータ通信に使う鍵(IPsec SA)を生成する。
- AH (Authentication Header):
- データの認証と完全性（改ざん検知）のみを提供し、暗号化は行わない。
- ESP (Encapsulating Security Payload):
- データの暗号化、認証、および完全性を提供し、AHより広く使用されている。
IPsecは、これらの要素を組み合わせて、トランスポートモードやトンネルモードなどの通信モードで動作する。 特にトンネルモードは異なるネットワーク間を安全に接続するサイト間VPNで広く利用されている。
今回組もうとした構成#
今回の試みは、YAMAHA RTX830のIPsec-VPN機能とAWS Lightsail上のStrongswanを組み合わせ実装するものでした。
IKEv1とIKEv2の両方で設定を試み、journalctlのログを基にデバッグを行いました。
特にIKEのフェーズ2とKey-IDの表現の差異がボトルネックとなり、解決に時間を要しました。
調査の結果、StrongswanとRTX830の間でKey-IDのデフォルト表現に違いがあることが判明し、その不一致を解消することで2日かけてその問題をクリアしました。
しかし、その後にIkEv1,IKEv2は同じネットワークの問題に直面しました。
具体的には、RTX830からの通信（上り）は正常にStrongswanに届きましたが、Strongswanからの通信（下り）がRTX830にうまく届かず、通信が不安定になりました。
この現象の発生と調査の結果、本実装を断念する形となりました。
失敗した原因の推察/考察#
IPsec VPNが確立された後、ルーティング設定が不可欠です。
つまり、どの通信をVPNトンネルに流すかを両方のエンドポイントに適切に設定する必要があります。
Lightsailは、単一のウェブサーバーやシンプルなアプリケーションのデプロイを目的としたサービスであり、EC2とは異なり、VPCのルートテーブルを自由に操作するような複雑なネットワークサービス機能は提供していません。
このLightsailのネットワーク上の制約が、IPsecトンネルを介した通信が自宅ネットワークに適切にルーティングされない根本的な原因だったと推察しています。
このため、IPsec-VPNに限らず、これらの設定が必要となるような複雑なVPN(SoftEtcher VPNなど)もLightsailではうまく機能しない可能性が高いです。
学んだこと#
今回の経験を通じて、IPsecの複雑性が異なるベンダー間の設定を非常に困難にしていることを痛感しました。
OpenVPNやWireGuardといったモダンなVPNプロトコルと比較すると、その設定の複雑さに驚かされましたが、これはIPsecが設計された当時の理念に起因するものと考えられます。
逆に言えば、同じベンダーの製品同士であれば、その実装の統一性からIPsec VPNは非常に安定しているのかもしれません。
これが、多くの日本のSierでIPsec VPNがインターネットVPNとして多く採用されている一因であると推察します。