AWS Client VPN でデフォルトルートが VPN に吸われちゃう

メディア統括本部 サービスリライアビリティグループ(SRG)の長谷川(@rarirureluis)です。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、AWS Client VPN 構築時に起きた問題を共有し、同じ問題にあたった方の助けになることを目的としています。
 

AWS Client VPN でデフォルトルートが VPN に吸われる


VPC へのアクセスだけを目的としているのに、すべてのトラフィックが VPN 経由になってしまうというアレです。
クライアント設定に一行追加するだけで解決できるこの問題について解説します。
 

突然インターネットにつながらなくなる謎


あるユーザーはAWS Client VPN への接続が成功した直後、突然インターネットへの接続が失われました。
でも私の環境では平気です。
「VPC 内のリソースにだけアクセスしたいだけなのに...」と思いながら該当ユーザーのルートテーブルを確認すると、なぜか 0.0.0.0/0 への経路が VPN の tun デバイスに向いていることに気づきます。
スプリットトンネリングを有効にしているはずなのに、なぜかすべてのトラフィックが VPN に吸い込まれてしまうのです。
サーバー側でデフォルトルートを追加していないのに、どうしてこうなるのでしょうか?
 

AWS Client VPN の隠れた動作


実はこれ、AWS Client VPN の「安全策」による動作なのです。
AWS の公式ドキュメントを読むと、次のような記述があります:
クライアントの LAN IP アドレス範囲が標準的なプライベート IP アドレス範囲(10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、または 169.254.0.0/16)外にある場合、Client VPN エンドポイントは OpenVPN ディレクティブ "redirect-gateway block-local" をクライアントに自動的にプッシュし、すべての LAN トラフィックを VPN に強制します。
つまり、あなたのクライアント端末が上記以外の IP アドレス範囲を使用している場合、AWS Client VPN は「安全のため」に強制的にすべてのトラフィックを VPN 経由にしてしまうのです。
これは VPN 接続を通じたセキュリティを高めるための措置ですが、スプリットトンネリングを使いたい場合には邪魔になります。
 

一行追加で解決する方法


この問題を解決するには、クライアント設定ファイル(.ovpn ファイル)に次の一行を追加するだけです:
💡
AWS 公式の Client VPN ソフトで動作します。
この設定により、サーバーから送られてくる「redirect-gateway block-local」指示を無視するようになります。
実際の設定ファイルは以下のようになります:
この設定を追加した後、VPN に再接続すると、AWS リソースへのアクセスを維持しつつ、インターネットトラフィックはローカルネットワーク経由で流れるようになります。
 

pull-filter の仕組みとメリット・デメリット


pull-filter は OpenVPN 2.4 以降で使用可能になった機能で、サーバーからプッシュされる設定を選択的にフィルタリングします。
💡
AWS 公式の Client VPN ソフトで動作します。
構文は以下の通りです:
  • : 指定したオプションを受け入れる
  • : 指定したオプションを無視する
  • : 指定したオプションを拒否し、サーバーに拒否したことを通知する
今回のケースでは、ignore を使ってサーバーから送られてくる redirect-gateway block-local という指示を黙って無視しています。

メリット

  • 帯域の節約: すべてのトラフィックを VPN 経由にしないので、AWS Client VPN の帯域使用量と費用を削減できます。
  • 既存設定の維持: route-nopull と違い、他のルート設定は維持したまま特定の設定だけを無視できます。

デメリット

  • セキュリティ考慮: すべてのトラフィックを VPN 経由にしないため、セキュリティポリシーによっては問題になる場合があります。
  • トンネルクラックの可能性: AWS Client VPN がこの設定を強制している理由の一つは「TunnelCrack」と呼ばれるセキュリティリスクへの対策です。この設定を無視することで、理論上はそのリスクに晒される可能性があります。

TunnelCrack とは

以下、AI による解説(DYOR)

TunnelCrack脆弱性の本質

2023年8月に公表されたTunnelCrackは、VPNクライアントのルーティング処理に潜む根本的な脆弱性群を指します。特に以下の2種類の攻撃が核心です14
LocalNet攻撃(CVE-2023-36672)
  • 悪意あるアクセスポイント経由で偽のローカルネットワーク経路を注入
  • VPNトンネル外にトラフィックを漏洩させ、平文通信を傍受可能
  • CVSSスコア6.8(中リスク)
ServerIP攻撃(CVE-2023-36673)
  • DNS改ざんによりVPNサーバーIPを偽装
  • 初期接続段階でトラフィックを横取り
  • CVSSスコア7.4(高リスク)

pull-filter設定のセキュリティ影響

の使用は、TunnelCrack脆弱性の観点から両刃の剣となります。
メリットとのトレードオフ
  • ローカルネットワークトラフィックの分離を無効化するため、LocalNet攻撃に対して脆弱性が顕在化
  • ただしHTTPSなど暗号化通信自体は保護される1
  • OpenVPN公式はフラグを推奨するも、完全対策ではないと表明4
現実的リスク評価
  • 攻撃成立には「悪意あるネットワークへの接続」が前提2
  • 公共Wi-Fi利用時など高リスク環境で問題が顕在化
  • 企業内ネットワークなど信頼環境では許容リスクの範囲内

多層防御の実践例

脆弱性を完全に排除できない状況下で推奨される対策:
  1. アプリケーション層の保護
      • 全サービスでTLS 1.3を強制(Let's Encrypt等の活用)1
      • HSTSプリロードリストの適用
  1. VPN設定の最適化
  1. OSレベルの対策
      • クライアントファイアウォールで予期しないアウトバウンドをブロック
      • DNS over HTTPS/TLSの強制適用

ベンダー対応状況

主要ベンダーの対応状況(2025年4月現在):
ベンダー対策状況推奨設定
OpenVPNオペレーティングシステム別対策開発中4
Sophosクライアント更新不要(低リスク判定)1TLS必須化
Fortinet適切設定で影響なし5暗号化プロトコル強制
 

終わりに


AWS Client VPN は便利なサービスですが、特定の条件下ではすべてのトラフィックを強制的に VPN 経由にしてしまう動作があります。
これは「redirect-gateway block-local」というディレクティブが自動的にプッシュされることが原因です。
クライアント設定に pull-filter ignore "redirect-gateway block-local" を追加することで、必要なトラフィックだけをVPN経由にし、インターネットへの通信はローカルネットワーク経由で行うスプリットトンネリングが実現できます。
SRG では一緒に働く仲間を募集しています。 ご興味ありましたらぜひこちらからご連絡ください。