Azure Database for MySQL をプライベート エンドポイントで公開し、ローカルPCから VPN＋VNet ピアリング経由で接続したいのにタイムアウトする――DNS は解決できているのに接続できない場合、原因はほぼ「ルーティングかフィルタリング」です。最短で切り分ける順番と、設定ミスが多いポイントを具体的に整理します。
この症状は「名前解決は成功、TCP が失敗」の典型
「FQDN はプライベート IP に解決できるのに、MySQL Workbench や CLI がタイムアウトする」という状況は、DNS の問題が解決した後に残る、ネットワーク経路（行き／戻り）・転送可否・ポート許可のどこかが詰まっているサインです。
特に、ローカルPC → VPN（UAE の VPN ゲートウェイ）→ UAE VNet →（VNet ピアリング）→ UK South VNet → Private Endpoint という経路は、関係する機能が多く、どれか1つでも向きや設定が違うと「DNS だけ正しい」状態になりがちです。
前提整理：Private Endpoint は「UK South VNet 内に作られる NIC」
Azure Private Link の Private Endpoint は、ざっくり言うと VNet のサブネット内に作成されるネットワーク インターフェイス（NIC）です。つまり、接続トラブルの切り分けは「その IP に TCP で到達できるか」という VNet 間通信の話になります。
この前提に立つと、今回のタイムアウト原因は大きく次のどれかに収束します。
- 戻り経路が無い（VPN クライアントのアドレス プール宛のルートが UK South 側に伝播していない）
- 転送トラフィックが許可されていない（VPN ゲートウェイが中継する通信がピアリングで落とされる）
- NSG / UDR / ファイアウォールで遮断（3306/TCP まで到達できない）
- VPN クライアント側に必要なルート/DNS が入っていない（VPN に繋いでも UK South 宛がトンネルに入らない）
ネットワーク構成を文字で可視化する
まずは「どこを通るべきか」を固定します。構成を簡略化すると次のイメージです。
ローカルPC（VPNクライアント）
↓（P2S VPN）
UAE VNet（VPN Gateway がある＝ハブ）
↓（Global VNet Peering）
UK South VNet（Private Endpoint がある＝スポーク）
↓（Private Link）
Azure Database for MySQL（プライベート接続）VNet ピアリングは同一リージョンだけでなくリージョン跨ぎ（Global）でも利用でき、ゲートウェイ転送（gateway transit）もサポートされます。
また、Azure Database for MySQL（Flexible Server）の Private Link は、同一 VNet だけでなくリージョンを跨ぐピアリング VNet からの接続や、オンプレ/リモート端末からのVPN（P2S/S2S）経由接続もユースケースとして整理されています。つまり、今回の狙い自体は実現可能な範囲で、問題は設定のどこかにあります。
最短で切り分けるチェックリスト
「どこで止まっているか」を早く特定するため、テスト地点を変えて同じ疎通を繰り返します。以下の表どおりに進めると、遠回りしにくくなります。
| チェック | 見るべきポイント | OK の目安 | NG のときの次アクション |
|---|---|---|---|
| Private Endpoint の状態 | 承認状態、NIC の存在、紐付くサブネット | Approved / NIC が有効 | 承認・作り直し、作成先サブネット再確認 |
| DNS 解決（ローカルPC） | 「どの DNS サーバ」で引いているか | FQDN → Private IP | VPN で使う DNS を見直す（後述） |
| ポート疎通（ローカルPC） | 3306/TCP が開くか | TCP 接続が成功 | ルート/NSG/FW のどこか。次に Azure 内 VM でテスト |
| UAE VNet 内 VM → PE | VPN を介さず VNet 内から到達できるか | TCP 3306 が成功 | ピアリング/NSG/UDR が原因（VPN 以前） |
| UK South VNet 内 VM → PE | 同一 VNet 内で到達できるか | TCP 3306 が成功 | PE/NSG/DNS/サーバ側の問題を疑う |
最重要：VNet ピアリングの「ゲートウェイ転送」の向きが逆だと必ず詰まる
VPN ゲートウェイがあるのが UAE VNet（ハブ）で、UK South VNet（スポーク）がそのゲートウェイを利用して VPN クライアントから到達させたい場合、ピアリングのチェックポイントは次のとおりです。
| 設定項目 | UAE VNet（VPN Gateway 側＝ハブ） | UK South VNet（Private Endpoint 側＝スポーク） | 狙い |
|---|---|---|---|
| 仮想ネットワーク アクセスの許可 | 有効 | 有効 | VNet 間の基本通信 |
| 転送トラフィックの許可（Allow forwarded traffic） | 有効 | 有効 | VPN ゲートウェイが中継する通信を落とさない |
| ゲートウェイ転送の許可（Allow gateway transit） | 有効 | 無効 | ハブの VPN ゲートウェイをスポークに共有 |
| リモート ゲートウェイを使用（Use remote gateways） | 無効 | 有効 | スポークがハブのゲートウェイを利用してオンプレ/VPN クライアントへ |
この組み合わせにより、ハブの VPN ゲートウェイが提供する P2S/S2S/VNet-to-VNet などの接続性がピアリング先にも展開されます。さらに、Windows の P2S クライアントはトポロジ変更の影響を受けるため、設定変更後は VPN クライアント パッケージの再ダウンロード／再インストールが必要になることがあります。
なお、ゲートウェイ転送は VPN Gateway の Basic SKU では使えない点も見落とされがちです。
ルーティングの本丸は「戻り経路」：UK South 側に VPN クライアント宛ルートがあるか
DNS が Private IP を返しているということは、ローカルPCがその IP に向けて TCP を張ろうとしている状態です。ここでタイムアウトする典型パターンが、行きは届いても戻り（SYN-ACK）が返せずに破綻するケースです。
特に P2S の場合、ローカルPCは VPN で割り当てられる「クライアント アドレス プール」の IP を持ちます。この宛先に対して UK South VNet 側が「次ホップは（リモートの）仮想ネットワーク ゲートウェイ」と理解していないと、戻りが迷子になります。
Azure 側で“有効なルート”を見て、推測をやめる
Azure では、VM の NIC に対して有効なルート（Effective routes）を確認できます。有効なルートは、Azure の既定ルート、UDR、（BGP などで）ゲートウェイ経由で伝播してきたルートの組み合わせです。
確認手順（例）：Azure ポータルで対象 VM を開き、ネットワーク インターフェイス（NIC）を開いたら、左メニューの「Help」配下にある Effective routes を見ます。
- UAE 側（ハブ）VM の NIC：UK South VNet 宛のルートが Next hop type「Virtual network peering」として見えるか
- UK South 側（スポーク）VM の NIC：VPN クライアントのアドレス プール宛が、仮想ネットワーク ゲートウェイ（リモート ゲートウェイ）へ向く形で見えるか
VNet ピアリングが成立しているかどうかは、有効なルートに「Virtual network peering」が出ているかで機械的に確認できます。
“有効なセキュリティ ルール”で NSG の最終結果を確認する
NSG は NIC とサブネットの両方に効きますが、「最終的にどう評価されるか」は画面で見るのが早いです。Network Watcher の Effective security rules では、NIC に適用されるインバウンド／アウトバウンドの集計結果を確認できます。
Network Watcher で「どこで落ちているか」を可視化する
“見るべき場所が多すぎて迷う”場合は、先に Network Watcher に寄せるのが得策です。Connection troubleshoot は、NSG・UDR・ブロックされたポートなど主要チェックをまとめて実施し、トポロジ表示まで出せるので「どこで落ちているか」を短時間で可視化できます。
おすすめの使い方は次の3段階です。
- UK South のテスト VM → Private Endpoint（IP/FQDN）で 3306 をテスト
- UAE のテスト VM → Private Endpoint（IP/FQDN）で 3306 をテスト
- （可能なら）UK South のテスト VM → VPN クライアント アドレス プール（ローカルPC）で戻り方向をテスト
VPN クライアント側で「UK South 宛ルート」が入っているか確認する
次に多いのが、ローカルPCが UK South（または Private Endpoint のサブネット）宛の経路を VPN に向けていないケースです。DNS は正しいのにタイムアウトするのは、このパターンでも起きます（= そもそもトンネルに入らず、別経路で捨てられる）。
Windows での確認コマンド
ipconfig /all
route print
powershell -Command "Get-NetRoute | Sort-Object -Property DestinationPrefix | Format-Table -AutoSize"VPN 接続中に、少なくとも以下が確認できるのが理想です。
- UK South VNet のアドレス空間（例：10.20.0.0/16）が VPN インターフェイスに向くルートとして存在する
- Private Endpoint が属するサブネット（例：10.20.1.0/24）が、より具体的なプレフィックスとして存在する（あればベター）
macOS / Linux での確認コマンド
# macOS
scutil --dns
netstat -rn
# Linux
resolvectl status
ip routeルートが入らないときの対処：P2S の「カスタム ルート広告」を使う
P2S（Point-to-Site）では、VPN クライアントへ特定プレフィックスのルートを配布したい場面があります。Azure VPN Gateway では、P2S 構成で カスタム ルート（advertise custom routes）を配布でき、必要な宛先（例：UK South VNet のプレフィックス）を VPN トンネルへ誘導できます。
注意点として、いわゆる強制トンネリング目的で 0.0.0.0/0 相当を広告する手法もありますが、VPN ゲートウェイはインターネット向けの出口ではないため、全トラフィックをトンネルに寄せると「インターネットが落ちる」副作用を招きます。目的はあくまで必要なプレフィックスだけを確実にトンネルへ入れることです。
DNS は「解決できた」だけで終わらせない：どの DNS で引いているかが重要
今回の条件では、プライベート DNS ゾーン privatelink.mysql.database.azure.com を作成し、Private Endpoint の A レコードを登録、UAE/UK South 両 VNet にリンク済みとのことです。ここまでは正しい方向性です。
ただし、運用で詰まりやすいのがローカルPCが参照している DNS サーバが Azure のプライベート DNS を引けない状態です。たとえば VPN 接続中でも社内 DNS を引いていたり、名前解決が分岐（スプリットブレイン）していたりすると、意図せずパブリック側へ解決したり、解決のたびに結果が揺れることがあります。
Private Endpoint 向けの名前解決は、Private DNS ゾーンを使う方法に加え、必要に応じて Azure DNS Private Resolver などの仕組みで「オンプレ/クライアントから Azure に問い合わせを届ける」設計が安定します。
VPN クライアントに Azure 側 DNS を配布する選択肢
Azure VPN Client（OpenVPN）を使う場合、プロファイル（XML）で DNS サーバやルートを含めたオプション設定ができます。DNS サーバ、DNS サフィックス、カスタム ルートなどを制御できるため、「VPN に繋ぐとプライベート DNS が必ず引ける」状態を作れます。
カスタム DNS を使っている場合の注意
VNet にカスタム DNS（自前 DNS）を設定している場合、VPN ゲートウェイの健全性のために Azure DNS（168.63.129.16）へのフォワーダー構成が推奨される、という注意点があります。DNS を変えた途端に別問題が起きることもあるため、既存の DNS 設計と併せて確認してください。
Private DNS ゾーン運用の落とし穴
プライベート DNS ゾーンは便利な反面、設計ミスがあると「解決はできるが正しくない」「ある日突然解決しなくなる」につながります。代表的な注意点は次のとおりです。
- パブリックに使われているゾーンを上書きしない：推奨される
privatelink.のゾーンを使い、既存の名前解決を壊さない - 同種サービスの Private Endpoint を複数作る場合はゾーンの使い回しに注意：ゾーンとエンドポイントの紐付け方によって A レコードが意図せず消えるなど、解決トラブルの温床になり得る
NSG / UDR / ファイアウォールの確認ポイント
「一通り確認済み」でも、タイムアウトが続く場合は“確認の粒度”を上げます。Private Endpoint 周りは、送信元が VPN クライアントのアドレス プールになる点が盲点になりやすいです。
Private Endpoint のサブネットで「ネットワーク ポリシー」を確認する
Private Endpoint 宛のトラフィックを NSG やルート テーブル（UDR）で制御したい場合、サブネットの「Network policy for private endpoints」で Network security groups や Route tables を有効化します（有効化すると、そのサブネット上の Private Endpoint に対してポリシーが適用されます）。
ここを意識せずに「NSG を見たのに直らない」となるケースがあるため、そもそも NSG/UDR を Private Endpoint に効かせる設計なのかを最初に揃えると、切り分けがぶれません。
最低限チェックしたい通信方向
- ローカルPC（VPN クライアント IP） → Private Endpoint（UK South のプライベート IP）: TCP 3306
- 戻り方向（Private Endpoint → VPN クライアント IP）も通ること（戻りが無いとタイムアウト）
よくある引っかかり
- UAE 側は許可しているが UK South 側サブネットの NSG が VPN クライアント アドレス プールを許可していない
- UDR で 0.0.0.0/0 を Firewall/NVA に向けており、戻りが Firewall 側で落ちる（Firewall が VPN クライアント宛を知らない、NAT している、など）
- サービスチェイニングの設計：ピアリングを跨いで NVA/ゲートウェイに迂回させる場合、UDR の次ホップや経路対称性が崩れやすい
VNet ピアリングはサービスチェイニング（UDR でピアリング先の VM や VPN ゲートウェイを次ホップにする）を前提にした設計が可能ですが、UDR が絡むと一気に複雑になります。疑わしい場合は、まず UDR の無いサブネット（検証用）で成立するかを確かめ、そこから差分を戻すと安全です。
ポート疎通を“クライアント側”で確実に確認する
「MySQL Workbench がタイムアウトする」だけだと切り分けが難しいため、OS の標準ツールで 3306/TCP の到達性を先に確定させます。
| 環境 | コマンド例 | 成功時の目安 |
|---|---|---|
| Windows | Test-NetConnection <FQDNまたはIP> -Port 3306 | TcpTestSucceeded : True |
| macOS / Linux | nc -vz <FQDNまたはIP> 3306 | succeeded / open などの表示 |
| どの環境でも | traceroute/tracert <Private Endpoint IP> | 経路の途中で落ちる地点のヒント |
ここで失敗するなら、MySQL の認証や TLS の前に、ルート／NSG／FW の問題です。逆にここが成功しているのに Workbench だけ失敗する場合は、クライアント設定（TLS やユーザー名の形式）を疑います。
MySQL クライアント設定：FQDN と TLS を外さない
Azure Database for MySQL（Flexible Server）の Private Link では、接続ホスト名に <server>.privatelink.mysql.database.azure.com を使い、クライアント側で SSL/TLS を必須にする構成が基本になります。MySQL Workbench でも、ホスト名、ユーザー名（username@servername 形式）、SSL を Required にする手順が案内されています。
CLI で試すなら、次のように「FQDN 指定＋SSL 必須」をまず合わせるのが安全です。
mysql -h <server>.privatelink.mysql.database.azure.com -u <username>@<servername> -p --ssl-mode=REQUIREDIP アドレス直打ちでも通信確認はできますが、証明書検証や SNI の関係で、最終的な運用は FQDN で揃えるほうがトラブルが減ります。
それでもタイムアウトする場合に疑う「ありがちな落とし穴」
| 落とし穴 | 症状 | 確認・対処 |
|---|---|---|
| ピアリング設定の向き違い | DNS は OK、通信は全滅 | ハブ=Allow gateway transit、スポーク=Use remote gateways、両方向 Allow forwarded traffic を再確認 |
| VPN クライアントのプロファイルが古い（特に Windows） | 設定を直したのに端末だけ変化なし | VPN クライアント パッケージを再生成して再インストール |
| VPN クライアントへルートが配布されていない | ローカルPCだけ到達しない | route print / ip route で確認し、必要なら P2S カスタム ルート広告を検討 |
| 戻り経路を UDR/Firewall が潰している | ときどき繋がる、または常にタイムアウト | 検証用サブネットで UDR を外して再現確認。Firewall 側に VPN クライアント宛経路があるか確認 |
| DNS が揺れている（社内 DNS / 公開 DNS を参照） | 解決結果が一定しない、環境依存で失敗 | VPN 接続時の DNS を固定。Private DNS Zone と Azure Private Resolver を含めた設計に寄せる |
| アドレス帯の重複 | 一部だけ到達しない、謎の迂回が起きる | VNet 同士、VPN クライアント アドレス プール、オンプレ LAN のアドレスが重複していないか確認（重複は最優先で解消） |
再発防止：安定して「VPN 端末から Private Endpoint に繋ぐ」ための設計ヒント
一度繋がっても、運用フェーズで DNS/ルートが崩れると再発しがちです。実務で安定しやすいパターンを押さえておくと、手戻りが減ります。
- ハブ＆スポークを前提に「ハブに VPN / DNS、スポークに Private Endpoint」を集約し、ピアリングはテンプレ化する
- DNS は “VPN 接続時に必ず Azure 側へ問い合わせが届く” 形に統一（クライアントが参照する DNS を固定し、条件付きフォワードや Private Resolver を活用）
- 切り分け用のテスト VM を UAE と UK South に1台ずつ置く（障害時に「VPN 以前／以後」を即断できる）
- Network Watcher の Connection troubleshoot を定期的に使える状態にしておく（NSG/UDR 変更時の影響確認が早い）
まとめ：タイムアウトは「ルート・転送・ポート」のどこかで止まっている
Azure Database for MySQL の Private Endpoint は、UK South VNet 内のプライベート IP（NIC）として振る舞います。DNS が Private IP を返しているのにタイムアウトする場合、原因はほぼ VPN〜VNet ピアリング〜Private Endpoint の経路か、その途中の NSG/UDR/Firewall にあります。
- ピアリングはハブで Allow gateway transit、スポークで Use remote gateways、両方向 Allow forwarded traffic
- Azure 側は Effective routes / Effective security rules で最終結果を確認し、推測をやめる
- P2S クライアントはルートと DNS が端末に反映されているかを OS コマンドで確認（必要ならプロファイル再配布）
- 3306/TCP の疎通を先に確定し、WorkBench の設定（FQDN＋TLS）に進む
- 詰まったら Network Watcher の Connection troubleshoot で「どこで落ちているか」を可視化
この順番で切り分ければ、DNS だけが正しい“惜しい状態”から抜け出し、VPN 端末からでも Private Endpoint 経由で安定して MySQL に接続できるはずです。
コメント