サイト間 VPN とリモートアクセス VPN：それぞれが何をつなぐか

どちらの設計も VPN と呼ばれますが、解決する問題は異なります。サイト間トンネルは 二つのゲートウェイをつなぐため、その背後のすべてのホストは何もインストールせずに反対側の許可されたアドレスへ到達できます。リモートアクセストンネルは個々のデバイスをネットワークにつなぎ、一度に 一クライアントずつ接続します。この比較が重要なのは、多くの導入ミスが一方を構成しながら他方の挙動を期待することで起きるからであり、症状は通常、トンネルが確かに到達したサービスでのタイムアウトです。

二つの設計、二つの境界

どちらの設計も LAN のブロードキャストドメインを拡張しません。遠端のデバイスがローカルの検出リストに現れることはなく、それを期待することが最初に捨てるべき前提です。意図的に公開したプライベート DNS 名は、どの検出プロトコルよりも予測しやすく、ベンダーを変えても維持されます。

一方のサイトで 10.10.0.0/24、もう一方で 10.20.0.0/24 を使います。ゲートウェイ A には 10.20.0.0/24 プレフィックスをトンネルへ送るルートまたはトラフィックセレクタが必要で、ゲートウェイ B にはその鏡像が必要です。その後、両側のホストは通常の IP 接続を使い、トンネルの存在を意識しません。この不可視性こそが機能であり、障害がトンネルのエラーではなく通常のネットワークエラーに見える理由でもあります。

ポリシーベースとルートベースは同じトンネルではありません

ポリシーベースの IPsec 導入では、ネゴシエートされたトラフィックセレクタが、保護される送信元と宛先の組を正確に定義します。あるゲートウェイの背後に新しいサブネットが現れ、どのセレクタもそれをカバーしていなければ、トンネルは上がったままで、新しいサブネットは単に運ばれません。ルートベースの設計ではインターフェースがトラフィックを受け取り、ルーティングテーブルが判断するため、プレフィックスの追加はトンネルの再ネゴシエーションではなくルート変更になります。

StrongSwan は両方のビューを直接公開しており、両方を並べて読むことが、実際にどちらのモデルを導入したかを知る方法です。

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

必要なプレフィックスが抜けているセレクタ一覧は、パケットキャプチャなしで障害を説明します。誤ったインターフェースを指すルートは、戻り方向の鏡像障害を説明します。再ネゴシエーションの前に両方を読みましょう。鍵の更新は、設定していないセレクタを追加しないからです。

トンネルの前にアドレス設計を決める

重複する範囲は、設定では直せない設計ミスです。両方のサイトが 192.168.1.0/24 を使うと、192.168.1.50 を必要とするホストには候補が 二つあり、選ぶ手段がありません。トンネルは認証され、セキュリティアソシエーションは確立し、ルーティングの判断はそれでも誤りか曖昧になります。

正直な 三つの選択肢から 一つを選びます。一方のサイトを再番号付けする、ゲートウェイで重複範囲を変換して両側が異なるプレフィックスを見るようにする、またはそれらのホストの直接ルーティングを諦めて別の方法でサービスを公開する。どれにもコストがあり、二年の視野では最初のものが最も安いことが多いです。トンネルができる前に決めてください。後からでは変更が古いアドレスを持つすべての機器に及びます。

MTU の問題も早めに解決します。トンネルは有効ペイロードを減らし、フラグメンテーションに頼る設計は、ゲートウェイで MSS を固定する設計とは挙動が異なります。

転送とポリシーはトンネルの外側にある

ゲートウェイはトンネルインターフェースと LAN インターフェースの間でパケットを転送する用意が必要で、両方向にサービスを許可するポリシーが必要です。Linux ではこれは 二つの別々の設定であり、さらに転送されたフローをそもそも許可するかを決めるファイアウォール規則があります。

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

受信側のホストは 三層目を追加します。自身のファイアウォールが、遠隔サブネットからのクライアントを依然として受け入れる必要があります。ローカルの /24 だけを許可するファイルサーバーは、トンネルがどれほど健全に見えても 10.20.0.7 からの転送トラフィックを拒否し、その拒否はルーティング障害と読み違えられます。

ゲートウェイからではなくホストから検証する

ゲートウェイ自身が送る ping は、転送されるユーザートラフィックとは異なる送信元アドレスとポリシーに従うことがあります。そのため弱いテストになり、時には誤解を招きます。アプリケーションが失敗しているのに成功したり、動作しているのに失敗したりします。

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

実際のホスト、実際の送信元アドレス、アプリケーションが使う実際のプロトコルを使います。その後、戻り経路を別に読みます。戻りルートのない正常な往路は、ブロックされたサービスとまったく同じに見えるタイムアウトを生むからです。

設計は、あなたが答えようとしている問いで選びます。ネットワークをつないでいるのか、デバイスを迎え入れているのか。どのベンダーを設定するかを含め、それ以外はすべてその答えから導かれます。