「OpenVPN＋Azure AD認証のAzure P2S VPNに移行したら、NordLayerと同時接続できなくなった」。そんな現場の声に、根本原因（ルーティングの独占）を分解し、具体的な回避策（スプリットトンネリング／仮想マシン分離／SSTPロールバック）を設計・手順・検証まで踏み込んで解説します。運用目線のチェックリストやDNS分割・セキュリティ考慮点も網羅しました。
背景と課題の整理（現象の正体を言語化）
従来のSSTP（証明書認証）では、Windows標準のVPNクライアントを使いながらも、既定経路（0.0.0.0/0）を奪い合わない設計により、NordLayerと共存できる構成が一般的でした。ところがOpenVPN（SSL）＋Azure ADへ切り替えると、Azure VPN Clientが配布されたルートを元に既定経路または広範囲の経路を占有し、NordLayerのトンネルとルーティング競合が発生、結果的に「どちらか片方しか機能しない」状態になります。
この症状は「同時接続をブロックする仕様」ではなく、ルーティングとDNSの設計に起因する挙動です。したがって、Azure P2S側の経路広告（Advertise custom routes）を適切に限定し、NordLayer側でもスプリットトンネルを使うことで同時利用を成立させる余地があります。
構成の変化と影響
| 項目 | 従来 | 変更後 | 影響 |
|---|---|---|---|
| トンネル種別 | SSTP（SSL） | OpenVPN（SSL） | クライアントがAzure VPN Client化 |
| 認証方式 | 証明書認証 | Azure AD認証 | MFA・条件付きアクセス対応、ただしルート配布が強力 |
| クライアント | Windows標準VPN | Azure VPN Client | 既定経路やNRPT（DNS）を強く制御 |
| NordLayer併用 | 可能 | 既定は不可 | ルーティング競合の調整が必要 |
結論先出し：現実解の選択肢
| 方策 | 概要 | 長所 | 短所 |
|---|---|---|---|
| ① 仮想マシン分離 | ホストOSでNordLayer、VM内でAzure VPNを稼働 | 物理的にルーティング競合を回避、切り分け容易 | VMのリソース・運用コストが増える（配布・管理含む） |
| ② スプリットトンネリング（OpenVPN維持） | Azure P2SでVNet向けプレフィックスのみ配布。既定経路はNordLayer | 1台のPCで共存。Azure AD認証も継続 | 両VPNのスプリット対応とDNS設計の詰めが必要 |
| ③ SSTP＋証明書に戻す | 旧構成へロールバック | 最短で安定化しやすい | Azure AD認証・条件付きアクセスを使えない |
Azure ADのMFA/条件付きアクセスが必須なら、②または①が推奨。逆に手戻りコスト最小を最優先するなら③が確実です。また、社内ポリシーで「全通信は単一VPNで暗号化」が必須なら、そもそもVPN併用は避ける設計判断が妥当です。
スプリットトンネリングの要点（概念設計）
「スプリットトンネリング」は、宛先ベースでトラフィックを複数の出口へ振り分ける設計です。ここでのゴールは次のとおり：
- Azure側へはVNet関連プレフィックスのみ（例：10.1.0.0/16、10.2.0.0/24 など）をAzure P2Sトンネルへ。
- その他のインターネット向け通信はNordLayerへ送る（NordLayer側で既定経路を確保）。
- DNSは名前解決のスプリットも合わせて設計（特定ドメインは社内DNS、一般ドメインはNordLayer側DNS）。
この「経路」「DNS」の2点が揃って初めて、ユーザー体験として「両方が自然に同時動作」します。
実装手順：Azure 側（OpenVPN＋Azure AD を維持）
もっとも汎用的で効果の高いのが、VNet向けプレフィックスのみを配布する構成です。以下はAzure Portalでの手順です。
- Azure Portalで対象の仮想ネットワークゲートウェイを開きます。
- Point-to-site 構成（Point‑to‑site configuration）を開いて、カスタム ルート（Advertise custom routes）を編集します。
- 配布するアドレス プレフィックスに、Azure側で到達させたい範囲のみを列挙します。
例：10.1.0.0/16、10.2.0.0/24、172.16.100.0/24など。 - 重要：
0.0.0.0/0は絶対に入れない（強制トンネルになり全通信がAzureへ流れ、NordLayerと競合します）。 - 保存後、クライアント構成ファイル（azurevpnconfig.xml）を再生成・ダウンロードします。
- WindowsのAzure VPN Clientに新しいプロファイルをインポートして接続します。
ルートが想定どおりかの確認
接続後、端末で次の確認を行います。
route print
tracert -d 10.1.0.10
PowerShell: Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property DestinationPrefix, RouteMetric | ft -Auto
Azure向けのプレフィックス（例：10.1.0.0/16）にのみ、Azure VPNの仮想インターフェイス（例：AzureVPN）が紐づくこと、既定経路（0.0.0.0/0）はNordLayerの仮想NIC側にあることを確認します。
azurevpnconfig.xml を手で確認したい場合
XMLを直接扱う場合は、該当プロファイルの <IncludeRoutes> にプレフィックスが列挙されていることを確認します（編集は自己責任で）。
<VpnProfile>
<.../>
<IncludeRoutes>
<Route>10.1.0.0/16</Route>
<Route>10.2.0.0/24</Route>
</IncludeRoutes>
<DnsSuffixes>
<DnsSuffix>corp.contoso.local</DnsSuffix>
</DnsSuffixes>
<DnsServers>
<DnsServer>10.1.0.53</DnsServer>
</DnsServers>
</VpnProfile>
DNSサフィックスやDNSサーバーも配布できます。DNS設計は後述の章で詳述します。
NordLayer 側の推奨設定（既定経路の司令塔）
NordLayerは既定経路（0.0.0.0/0）を握る側に据えるのが基本方針です。そのうえで以下を確認・調整します。
- スプリットトンネリングを有効化：
アプリ単位／ドメイン単位／経路単位のいずれでも、Azure向けプレフィックスはスプリット対象から除外（＝Azure向けはNordLayerを通らない）。 - Kill Switch/Threat Protection：
すべての非スプリット通信を遮断する設定は、Azure側の一部通信まで遮ってしまう場合があります。許可リストやスプリット経路を正確に整備してください。 - DNS設定：
一般WebはNordLayerのDNS、社内FQDNはAzure側DNSに解決させる方針。アプリやドメインベースのスプリット機能を使って、特定サフィックスはローカル解決（Azure DNS）となるように調整します。
最終的に、「Azure宛はAzureトンネル」「それ以外はNordLayer」となっていればOKです。
Windows ルーティングと優先度の基礎（失敗しないための要点）
Windowsでは、より具体的な経路（長いプレフィックス）が優先され、同一長の場合はメトリックが小さい経路が選ばれます。したがって、Azure側に配布するのはVNetの明示プレフィックスに限定し、既定経路は配らないのが鉄則です。
必要に応じてインターフェイス メトリックを調整できますが、原則として明示経路の設計（IncludeRoutes）で勝つのが安全です。
# 参考：メトリック調整（慎重に）
PowerShell: Get-NetIPInterface | Sort-Object -Property InterfaceMetric
PowerShell: Set-NetIPInterface -InterfaceAlias "NordLayer Tunnel" -InterfaceMetric 10
ただし、この調整は既定経路の取り合いを解決する補助策であり、プレフィックス設計が正しいことが前提です。
DNS 設計：名前解決もスプリットする
通信経路だけでなくDNSの向き先を分けないと、社内名の解決失敗や、逆に一般サイトが社内DNSへ流れて遅延する問題が起こります。以下の原則を推奨します。
- 社内ドメイン（例：
corp.contoso.local）は、Azure側のDNSサーバー（VNet内のAD DNSなど）へ。 - それ以外の一般ドメインは、NordLayer側のDNSで解決。
実装手段としては、Azure VPN Clientの配布XMLでDNSサフィックス／DNSサーバーを指定する、あるいはWindowsのNRPT（Name Resolution Policy Table）ルールを用います。
# 例：NRPTで社内サフィックスをAzure DNSへ誘導
PowerShell: Add-DnsClientNrptRule -Namespace "corp.contoso.local" -NameServers 10.1.0.53
# 既存ルールの確認
PowerShell: Get-DnsClientNrptRule
DNSルールはユーザー体験に直結します。意図せず社内向け名がNordLayer DNSに解決されない／一般向けが社内DNSに吸い込まれる、といった逆流を起こさないよう、解決テスト（nslookup、Resolve-DnsName）を必ず実施してください。
詳解：スプリットトンネリング設定手順（再掲・実務版）
- Azure Portal → 仮想ネットワークゲートウェイ → Point‑to‑site 構成を開く。
- カスタム ルート（Advertise custom routes）に、Azure VNetのプレフィックスのみを列挙（
0.0.0.0/0は入れない）。 - 保存後、クライアント構成（azurevpnconfig.xml）を再ダウンロード。
- WindowsのAzure VPN Clientで新しいプロファイルをインポート→接続。
- route printやGet‑NetRouteで、指定プレフィックスのみAzure VPNへ、その他はNordLayerへ流れることを確認。
- NordLayer側のスプリット機能を有効化し、Azure宛経路／社内ドメインを除外（＝NordLayerを通さない）する設定を適用。
もしazurevpnconfig.xmlの手修正が必要なら、<IncludeRoutes>にAzure側のサブネットのみを記載してください。編集後は再インポートが必要です。
よくある失敗例と対処
| 症状 | 原因 | 対処 |
|---|---|---|
| NordLayer接続中にAzure P2Sが切れる／通信不可 | Azure側が0.0.0.0/0を広告し既定経路を奪取 | カスタムルートから既定経路を除外。VNetプレフィックスのみ配布 |
| 社内FQDNが解決できない | DNSがNordLayer側へ寄っている／NRPT未設定 | azurevpnconfig.xmlでDNSサフィックス・サーバーを配布、またはNRPTルールを追加 |
| 一般サイトが遅い／繋がらない | 社内DNSへ一般名が流れてタイムアウト | 一般ドメインはNordLayerのDNSで解決されるようNRPTやスプリットを見直し |
| 一部のAzureサービスだけ繋がらない | 必要なプレフィックスがIncludeRoutesに不足 | 該当サブネット（PaaS/Private Endpoint等）を追加で広告 |
| 接続順で結果が変わる | NICメトリックやルート追加順序の差分 | 明示ルートで優先、必要ならメトリック固定／スクリプトで接続順を標準化 |
仮想マシン分離（①）の実践ポイント
併用要件は厳格だが端末要件やアプリが複雑な場合、VMでネットワーク境界を物理的に分離するのが堅いです。設計の勘所は次のとおり。
- ハイパーバイザー：WindowsならHyper‑Vが手堅い。仮想スイッチはNATでもブリッジでも可だが、VM内から直接Azure VPN Clientを使う想定ならNATで十分。
- プロファイル配布：VM用ローカルアカウント／イントラAD参加など、Azure AD認証の要件をVM内で満たす。
- RDP/管理：ホストとVM間で管理ポートを明確化。クリップボードやドライブ共有のポリシーも合わせて定義。
- コスト：CPU/RAM/ストレージ増。端末配布・パッチ適用・セキュリティ監査など運用負荷を受け入れる。
VM分離はルーティングの悩みから解放されますが、運用自動化（プロビジョニング／ポリシー配布）まで設計するのが成功の鍵です。
SSTP＋証明書へ戻す（③）の注意点
労力に対する安定性を最優先するなら現実的な選択ですが、Azure ADのMFA・条件付きアクセス・監査連携などの恩恵を失います。戻す場合は次を確認します。
- 証明書配布（クライアント証明書のライフサイクル・失効運用）。
- セキュリティ要件（デバイス準拠・IDベース制御）の再評価。
- 将来の再移行計画（OpenVPN＋Azure AD）へ向けた成熟度ロードマップ。
セキュリティとコンプライアンスの考慮
- MFA・条件付きアクセス：Azure AD側の強み。スプリットでもこの価値は維持できます。
- デバイス準拠：エンドポイント保護（EDR/AV）、ファイアウォール、更新プログラムは両トンネル併用時も必須。
- ロギング：Azure側・NordLayer側の接続ログを突合できるよう、ユーザーID・端末ID・タイムスタンプの整合を事前に設計。
- 禁止アプリ／高リスクサイト：NordLayer側のWeb制御ポリシーを優先させる場合、Azure宛の業務アプリはスプリット除外で影響を受けないように。
検証シナリオ（再現性のある受け入れ基準）
- NordLayerのみ接続し、一般サイトとSaaSが正常動作するか。
- Azure P2Sを追加接続し、Azure VNet内サーバーのRDP/HTTP/DBへ到達できるか。
- 一般サイトのトラフィックがNordLayer経由のままか（
tracert／IP確認） - 社内FQDNがAzure DNSで解決されるか（
nslookup/Resolve‑DnsName）。 - ログに二重化やドロップ（RST/ICMP不可）がないか（
pktmon／イベントログ）。 - 接続順序（NordLayer→Azure／Azure→NordLayer）を変えても結果が安定か。
運用ベストプラクティス
- プロファイルの標準化：azurevpnconfig.xmlはGit等でバージョン管理し、配布はMDM/Intuneなどで自動化。
- アドレス設計：重複・オーバーラップを避ける（10.0.0.0/8乱用は衝突の温床）。
- スクリプト整備：接続／切断／確認を自動化（例：PowerShellで
rasdial相当・Azure VPN ClientのCLI操作、Get‑NetRouteの差分チェック）。 - 障害時フォールバック：Azure側が不調時はNordLayerのみ、NordLayer不調時はAzureのみの単独動作に切替できるランブックを用意。
- 監査トレイル：どのユーザーがどのトンネルをいつ使ったか、最低1年は追跡できるように。
技術ディープダイブ：なぜ「同時に使えない」と感じるのか
OpenVPN＋Azure ADのP2Sは、Azure VPNゲートウェイが広告する経路をAzure VPN Clientが忠実に適用します。ここに既定経路や広いサマリ（例：10.0.0.0/8）が混ざると、Windowsのルート選定によりほぼ全トラフィックがAzureトンネルに吸い込まれるため、NordLayerが提供する既定ルートやDNSポリシーと競合します。つまり、「同時接続を禁止」しているのではなく、ルートの独占が自然と発生しているだけです。
逆にいえば、プレフィックスをVNet範囲に限定し、DNSも分割すれば、Windowsは「より具体的な経路」をAzureへ、「その他」はNordLayerへ振り分けるため、実質的に共存できます。
トラブルシューティング手順テンプレート
- ルート一覧取得：
route printとGet‑NetRoute。 - 既定経路の所有者を確認（どのインターフェイスが0.0.0.0/0を持つか）。
- Azure向けプレフィックスの経路の所有者を確認（AzureVPNになっているか）。
- DNS解決経路の確認（NRPT／Azure VPN ClientのDNS配布）。
- 到達性テスト：
tracert -d 10.1.0.10、Test‑NetConnection。 - NordLayerポリシーのスプリット設定・Kill Switch・Web保護の例外を確認。
サンプル：検証用ルートテーブル（イメージ）
IPv4 ルート テーブル
===========================================================================
ネットワーク宛先 ネットマスク ゲートウェイ インターフェイス メトリック
0.0.0.0 0.0.0.0 10.254.0.1 10.254.0.2 10 ← NordLayerの既定経路
10.1.0.0 255.255.0.0 10.11.0.1 10.11.0.2 5 ← Azure VNet1 へはAzureVPN
10.2.0.0 255.255.255.0 10.11.0.1 10.11.0.2 5 ← Azure VNet2 へはAzureVPN
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
===========================================================================Q&A（現場で出やすい質問）
Q. Azure P2SとNordLayerを毎回どちらを先に接続すべき？ A. 理想はどちらの順でも安定する設計（明示ルート＋DNS分割）。不安定なら、先にNordLayer（既定経路を確保）→後でAzureの順を推奨。 Q. IPv6は考慮する？ A. まずはIPv4で安定化させるのが現実的。IPv6を有効にする場合は、両トンネルのIPv6経路とDNS（AAAA）の分割方針を別途設計。 Q. Always‑On（自動再接続）と相性は？ A. 片方のトンネルが再接続時に既定経路を奪うケースがあります。IncludeRoutesの厳格化とキルスイッチ例外で安定させてください。 Q. Private Endpoint／PaaSのFQDNが引けない A. 対象VNet/サブネットのプレフィックス不足、またはDNSフォワーダの設定漏れが典型。DNSゾーンリンクとNRPT/azurevpnconfig.xmlを見直し。
実装チェックリスト（最終確認）
- Azure P2Sのカスタムルートに既定経路が無い。
- VNet関連プレフィックスのみがIncludeRoutesに入っている。
- NordLayer側でスプリットトンネル有効かつAzure宛は除外されている。
- 社内ドメインのNRPTまたはDNS配布が設定済み。
- tracertでAzure宛のホップがAzureVPN側に出ている。
- 一般サイトの出口IPがNordLayer側になっている（IP確認サイト等で検証）。
- 接続順序を変えても通信が維持される。
どの方法を選ぶべきか（意思決定の指針）
- Azure ADの多要素認証が必須：②スプリットトンネリング or ①仮想マシン分離。
- 運用コスト最小・手戻り少なく安定化：③SSTP＋証明書へ戻す。
- 全社ポリシーで単一トンネル強制：併用をやめ、どちらか一方へ集約。
本記事の推奨は、②スプリットトンネリング。Azure AD認証のガバナンスを活かしつつ、NordLayerのインターネットセキュリティを両立できます。
まとめ（実務の要点）
- 「同時に使えない」の本質はルーティングとDNSの独占問題。
- Azure側はVNet向け経路のみ広告、既定経路は配らない。
- NordLayer側は既定経路の司令塔＋スプリットでAzure宛を除外。
- DNSは社内ドメインをAzure DNS、一般はNordLayer DNSへ。
- 検証はroute print / tracert / nslookupの三点セットで。
これらを満たせば、OpenVPN＋Azure AD認証を維持したまま、Azure P2S VPNとNordLayerの安定した同時利用が可能になります。
付録：スクリプト例（導通とDNSのセルフチェック）
# Azure宛経路の存在確認
$azurePrefixes = @("10.1.0.0/16","10.2.0.0/24")
$routes = Get-NetRoute -AddressFamily IPv4 | Where-Object { $azurePrefixes -contains $_.DestinationPrefix }
$routes | Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric
# Azure向け到達性
$targets = @("10.1.0.10","10.2.0.20")
foreach ($t in $targets) {
Test-NetConnection -ComputerName $t -InformationLevel Detailed
}
# 社内FQDNの解決先がAzure DNSかを確認
$corpDomains = @("host1.corp.contoso.local","app.corp.contoso.local")
foreach ($d in $corpDomains) {
Resolve-DnsName $d
} 付録：運用ドキュメント断片（チーム配布用）
| 項目 | 設定値（例） | メモ |
|---|---|---|
| Azure IncludeRoutes | 10.1.0.0/16, 10.2.0.0/24 | 既定経路は不可（0.0.0.0/0禁止） |
| Azure DNS | 10.1.0.53 | AD DNS/フォワーダで外部解決も可 |
| NRPTルール | corp.contoso.local → 10.1.0.53 | 社内のみAzure DNSへ |
| NordLayer Split | Azure宛経路・ドメインは除外 | 既定経路はNordLayerが保持 |
| 接続順序 | 標準：NordLayer → Azure | 順序依存が無い設計が最終目標 |
付録：変更管理・ロールバック観点
- 事前バックアップ：現行のazurevpnconfig.xml、NordLayerポリシーを書き出し。
- 段階展開：IT部門→パイロット→全社の順で展開。
- ロールバック条件：Azure宛通信不可・一般サイト不可・DNS失敗が一定を超えた場合。
- ロールバック手順：旧XMLに戻す／SSTPへ切り替え／NordLayerのみ運用へ一時移行。
付録：監査・可観測性の強化
- Azure側：ゲートウェイの接続ログ、P2Sの認証ログ、条件付きアクセスの結果。
- 端末側：Windowsイベントログ（Microsoft-Windows-VPN、RasClient）、EDR。
- NordLayer側：接続・ブロック・Webフィルタの記録。
- 相関分析：ユーザーID・端末ID・時刻同期（NTP）を厳密化。
最後に：現場で迷ったらここだけ押さえる
- AzureはVNetだけにルートを配る（0.0.0.0/0を入れない）。
- NordLayerが既定経路（一般通信の出口）。
- DNSは社内ドメインだけAzure DNS（NRPTまたはXML配布）。
この三点セットで、Azure P2S VPN（OpenVPN＋Azure AD）とNordLayerの同時接続は十分に実現可能です。
コメント