Point-to-Site (P2S) VPN をスプリットトンネルで使っていると、「Azure SQL / Synapse だけ VPN 経由にしたい」という要望はとても多いです。本記事では、なぜその経路制御が現実的に難しいのかを整理し、運用が破綻しない設計（Private Link／強制トンネル）を具体的に解説します。
要件の整理：いま何が起きていて、何を実現したいのか
まずは状況を、ネットワーク設計の言葉に落とし込みます。ここが曖昧だと「できそうな気がするけど実はハマる」構成になりがちです。
| 項目 | 現状 | 困りごと／要望 |
|---|---|---|
| 接続方式 | P2S VPN（リモート端末 → Azure） | 端末は社外・在宅・出張など、送信元 IP が変わる |
| トンネル方式 | スプリットトンネル | インターネット全体は端末の ISP 経由のままにしたい（帯域・遅延・コストの理由） |
| 対象サービス | Azure SQL（*.database.windows.net）／Synapse（*.sql.azuresynapse.net） | 社外からでも安全に接続したい |
| アクセス制御 | Public endpoint + IP 制限（ホワイトリスト） | 端末のグローバル IP が変わるたびにホワイトリスト更新が必要で運用負荷が高い |
| やりたいこと | 「SQL/Synapse 宛て通信だけ」P2S VPN 経由にしたい | 端末の ISP 経由ではなく Azure 側の出口（固定 IP）からアクセスさせたい |
結論：スプリットトンネルのまま「特定の PaaS だけ VPN 経由」は信頼できる設計になりにくい
先に結論です。P2S VPN のスプリットトンネル構成のまま、「*.database.windows.net だけ」「*.sql.azuresynapse.net だけ」のように“ドメイン名（FQDN）単位で”VPN に流すのは、Azure VPN Gateway の標準機能としては用意されておらず、構成として成立させるのが難しいです。
難しさのポイントは大きく 2 つあります。
- ルーティングは基本的に IP プレフィックス（CIDR）で決まり、FQDN を条件に分岐できない
- Azure SQL / Synapse の Public endpoint が使う IP 群は固定ではなく、更新・増減がありうる
なぜ FQDN で「このサービスだけ」を VPN に流せないのか
P2S でクライアントへ配布できる経路（ルート）は、基本的に 「宛先 IP の範囲（x.x.x.x/yy）」 です。Microsoft Learn の手順でも、カスタムルートは IP アドレス（例：203.0.113.250/32）を追加して配布する形になっています。
つまり、実現できるのは下記のような世界観です。
- 「10.10.0.0/16（VNet 内）宛は VPN 経由」
- 「特定の IP（/32）宛は VPN 経由」
一方で、一般に OS のルーティングは “FQDN” を見て経路を選べません。名前解決（DNS）した結果として得られた IP 宛てにパケットを投げるだけです。そのため「この FQDN のときだけ VPN」を OS の経路制御だけで実現するのは筋が悪く、専用のクライアント制御（アプリごとのプロキシや独自ドライバ等）が必要になりがちです。
IP ベースで寄せようとしても運用が破綻しやすい理由
では「FQDN は無理でも、Azure SQL / Synapse の Public IP を調べて、その IP 宛だけ VPN へルートすれば良いのでは？」となりがちです。しかし、ここに大きな運用リスクがあります。
Azure の IP レンジは“変わる前提”で公開されている
Microsoft は Azure の IP レンジ／Service Tags の JSON を公開しており、毎週ダウンロードして更新するように案内しています。つまり Azure の側は「IP が変わる（増える・減る）前提」で設計されている、ということです。
さらに Service Tag は「特定サービスが使う IP プレフィックス群」をまとめたもので、Microsoft が管理して自動更新されます。
SQL/Synapse は“特定の数個の IP”では語れない
Azure SQL Database には Sql という Service Tag があり、そこには Azure SQL が利用する IP アドレスが含まれます（リージョン別にも分割されます）。
ここで重要なのは、P2S クライアントに配るルートは「Service Tag を指定して追従する」ではなく、あくまで IP プレフィックスを静的に持たせる方式だという点です。結果として、SQL/Synapse の IP 変動に追従するには、クライアント配布ルート側も継続的に更新が必要になり、更新漏れ＝即障害になりがちです。
| やり方 | 一見よさそうに見える点 | 破綻ポイント |
|---|---|---|
| FQDN（*.database.windows.net）だけ VPN に流す | 対象が明確で、運用も簡単そう | ルーティングは IP ベース。標準機能だけでは FQDN 条件分岐ができない |
| SQL/Synapse の Public IP を列挙して /32 ルート配布 | 狙った通信だけ VPN に寄せられそう | IP が増減・変更する。追従漏れで接続断、過剰に入れると別サービスも巻き込む |
| Service Tag（Sql）相当の IP 全部をルート配布 | 変更に強く見える | 範囲が広くなりがちで「SQL 以外」を巻き込む。クライアント側ルート更新も必要 |
推奨解決策：Private Link（プライベートエンドポイント）で “Public を通らない” 形にする
ここからが本題です。「SQL/Synapse だけ安全に VPN 経由で使いたい」という要望に対して、最も筋が良いのは Azure Private Link（プライベートエンドポイント） を使うことです。
Private Link を使うと、Azure SQL / Synapse へは VNet 内のプライベート IP に向けて接続します。接続先の URL（FQDN）は基本的に変えずに、DNS の解決結果だけをプライベート IP に切り替えます。Microsoft Learn でも「既存アプリの接続 URL は変わらない」ことが説明されています。
端末 ↓（P2S VPN） Azure VNet ↓（Private Endpoint のプライベート IP） Azure SQL / Synapse（Private Link）
Private Link のキモは DNS：Public FQDN を Private IP に解決させる
Private Link では、パブリック DNS 側に CNAME（別名）を作って “プライベート用ドメイン” に誘導し、最終的に Private DNS Zone の A レコードでプライベート IP を返す、という流れになります。
このため、P2S を使う端末側では、次の 2 点を満たせば OK です。
- VPN で VNet に到達できる（ルートは VNet 宛が VPN 経由になる）
- DNS が Private DNS Zone を参照できる（＝正しくプライベート IP に解決できる）
Azure SQL で必要になる DNS ゾーン名
Azure SQL Database（Microsoft.Sql/servers）の Private Endpoint では、推奨の Private DNS Zone 名は privatelink.database.windows.net です。
Synapse で必要になる DNS ゾーン名（SQL / Serverless / Dev / Studio）
Synapse は “どの機能を閉域化するか” によって、Private Endpoint（サブリソース）と DNS ゾーンが複数に分かれます。代表的には下記です。
| 用途 | サブリソース | Private DNS ゾーン（推奨） | 補足 |
|---|---|---|---|
| Synapse SQL（Dedicated） | Sql | privatelink.sql.azuresynapse.net | 一般に「workspace.sql.azuresynapse.net」へ接続する想定 |
| Synapse SQL（Serverless） | SqlOnDemand | privatelink.sql.azuresynapse.net | 同じゾーンに集約される |
| 開発用エンドポイント | Dev | privatelink.dev.azuresynapse.net | CI/CD やノートブック連携で影響しやすい |
| Synapse Studio | Web（Private Link Hubs） | privatelink.azuresynapse.net | 「Studio も閉域化したい」場合に重要 |
P2S クライアントの DNS 設計パターン
Private Link 移行で一番つまずくのは DNS です。特に P2S 端末は「社内 DNS を見に行く」「自宅ルーターの DNS を見に行く」など環境がバラけます。ここを先に設計しておくと移行がスムーズです。
| パターン | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| VPN で Azure 提供 DNS を使う | VNet に紐づく Azure DNS で Private DNS Zone を解決 | 構成をシンプルにしたい、P2S 端末の数が多い | 社内向け名前解決（オンプレ DNS）が必要な場合は追加設計が必要 |
| VNet 内に DNS サーバーを用意 | AD DS / BIND などを VNet に置き、Private DNS と統合 | 社内の DNS ポリシーが厳格、独自ドメインが多い | 可用性（冗長化）と運用（パッチ・監視）が必要 |
| オンプレ DNS から条件付き転送 | privatelink.* を Azure 側のリゾルバへ転送 | 社内 DNS を単一の正にしたい | 拠点と Azure 間の DNS 経路、名前解決の遅延、障害時の影響範囲に注意 |
Private Link への段階移行（公開停止までの現実的ステップ）
「いきなり Public endpoint を閉じる」のはリスクが高いので、段階的に進めるのが定石です。
- Azure SQL / Synapse に Private Endpoint を作成し、Private DNS Zone（privatelink.*）を VNet にリンクする
- P2S で接続した端末から DNS がプライベート IP を返すことを確認する（nslookup など）
- 疎通確認（SQL なら 1433/TCP、アプリなら実接続）を行い、ログも確認する
- 問題がなければ、Public network access を無効化、または Public 側の許可範囲を最小化する
検証時に便利な確認観点を表にまとめます。
| 確認項目 | 例 | 期待値 |
|---|---|---|
| 名前解決 | nslookup <server>.database.windows.net | privatelink 経由の CNAME を辿り、最終的にプライベート IP が返る |
| 到達性 | Test-NetConnection <FQDN> -Port 1433 | TCP 接続が成功する（タイムアウトしない） |
| 経路 | route print / traceroute | VPN インターフェース側が選択される |
| Azure 側ログ | Firewall / NSG Flow Logs / SQL 監査 | 想定した送信元（P2S プールや VNet）からの通信が見える |
Private DNS Zone で起きがちな落とし穴
Private DNS Zone を作ると “何でも解決してくれる” ように見えますが、実際は注意点があります。Microsoft Learn でも、Private DNS Zone のリンク状態によっては、public リソースへの解決が NXDOMAIN になりうること、必要に応じてフォールバック（インターネット解決）を検討することが書かれています。
- 同名の Private DNS Zone を複数の用途で混ぜない（ゾーン設計をサービス単位で揃える）
- 社内 DNS と Azure Private DNS の “分岐点” を決める（条件付き転送など）
- クライアントが参照する DNS が統一されていない場合、端末ごとに挙動が変わる
代替案：強制トンネル + Azure Firewall で「出口 IP を固定」し、IP ホワイトリスト運用を続ける
「Private Link を今すぐ使えない」「監査の都合で全トラフィックを検査したい」「どうしても Public endpoint + IP 制限を維持したい」という事情もあります。その場合の現実的な代替が 強制トンネル（フルトンネル） です。
強制トンネルの基本：0.0.0.0/1 と 128.0.0.0/1 を広告する
Azure VPN Gateway の P2S では、クライアントに対して 0.0.0.0/1 と 128.0.0.0/1 を広告することで、実質的にインターネット宛てを含む通信を VPN トンネルへ向けられます。
ただし重要な注意点があります。VPN Gateway 自体は “インターネットへの出口” を提供しません。そのため、強制トンネルを有効にしても、そのままだとインターネット宛ての通信はドロップされます。
Azure VPN Client なら 0/0 を XML で入れる方法もある
Azure VPN Client（OpenVPN）では、プロファイル XML に 0.0.0.0/0 を含める方法も案内されています。OS やクライアントのバージョンによって挙動・制約があるので、端末の混在環境では事前検証が必須です。
「出口」を作る：Azure Firewall（または NVA）で SNAT して固定 IP から出す
強制トンネルを「ホワイトリスト運用のための固定 IP 化」に使う場合、一般的な構成は次の通りです。
P2S 端末 ↓（VPN：強制トンネル） Azure VPN Gateway ↓（経路制御で Firewall/NVA へ） Azure Firewall（SNAT） ↓ Internet / Public endpoint（SQL / Synapse）
Azure Firewall は outbound の SNAT を自動で行い、外向き通信の送信元を Firewall のパブリック IP に集約できます。これにより、Azure SQL / Synapse 側の IP 制限には Firewall のパブリック IP を登録すればよくなります。
設計時の注意：GatewaySubnet に 0.0.0.0/0 の UDR は置けない
強制トンネル構成では「VPN Gateway から Firewall へ確実に送る」ためにルート設計が必要ですが、GatewaySubnet には制約があります。Microsoft Learn では、GatewaySubnet に 0.0.0.0/0 宛のユーザー定義ルート（UDR）を関連付けることはサポートされないと明記されています。
このため、強制トンネルを検討するなら以下を前提にしてください。
- 「やりたいこと」が SQL/Synapse だけで良いなら、まず Private Link を検討する（設計がシンプルで堅牢）
- どうしてもフルトンネルが必要なら、Virtual WAN（セキュアハブ）など “フルトンネル前提の設計” も視野に入れる
- vNet VPN Gateway でやる場合は、GatewaySubnet の制約を踏まえた経路設計・検証が必須
強制トンネル方式のメリット／デメリット
| 観点 | メリット | デメリット |
|---|---|---|
| 運用 | 出口 IP が固定化でき、ホワイトリスト更新が激減 | VPN 端末の全通信が Azure 経由になり、障害・遅延の影響範囲が広い |
| セキュリティ | Firewall で一元的に制御・ログ取得ができる | 全通信を検査する分、設計ミスがあると業務影響が大きい |
| コスト | IP 制限運用の工数を削減できる | Azure Firewall・転送料・ログ保管などコスト増になりやすい |
判断基準：結局どちらを選ぶべきか
最後に、選定の判断を “迷わない形” に落とし込みます。
| 要件 | おすすめ | 理由 |
|---|---|---|
| SQL/Synapse への通信だけを閉域化したい | Private Link | Public を経由しない。スプリットトンネルのままでも成立しやすい |
| Public endpoint + IP 制限を当面維持したい（固定 IP が必要） | 強制トンネル + Firewall | 出口 IP を固定化できるが、全通信が対象になる点に注意 |
| すでに全トラフィック検査が必須、ゼロトラスト方針 | 強制トンネル（設計をしっかり） | 監査・制御・ログの要件を満たしやすい |
よくある質問
Private Link にすると接続文字列（FQDN）は変わりますか？
基本的に変わりません。従来どおり <server>.database.windows.net や <workspace>.sql.azuresynapse.net を使い、DNS 解決だけがプライベート IP を返す形になります。
IP ホワイトリスト運用が大変です。SQL のルール数に制限はありますか？
Azure SQL ではサーバーレベルの IP ファイアウォールルールを構成できますが、管理方法や制限もあります。たとえば Azure portal でのサーバーレベル IP ルールは最大 256 件という記載があります。ホワイトリストが増え続ける運用は、早めに出口固定化や Private Link へ寄せた方が安全です。
まとめ：やりたいことを“ルート”で解くのではなく、“接続方式”で解く
- P2S スプリットトンネルのまま「SQL/Synapse だけ VPN 経由」をルーティングだけで実現するのは難しく、IP 列挙方式は運用が破綻しやすい
- 最優先の解は Private Link（プライベートエンドポイント）。Public を通らず、DNS とルートが素直になる
- どうしても Public endpoint + IP 制限を維持するなら、強制トンネル + Azure Firewall で出口 IP を固定化する。ただし GatewaySubnet の制約を含め、設計・検証が重要
コメント