Point-to-Site VPN (P2S)を理解するための前提
P2Sは個別clientからVPN Gatewayへ接続し、専用site-to-site VPN deviceをremote側に置かずAzure VNetへremote accessする。 Azure VPN GatewayのP2SではOpenVPN、IKEv2、SSTPなどのprotocol選択肢があり、対応OS・authentication方式との組み合わせで決める。
authenticationはcertificate、Microsoft Entra ID、RADIUS等を選べる。Microsoft Entra IDはOpenVPN/Azure VPN Clientを前提にする。 client address poolは接続clientへ払い出すprivate rangeで、接続元on-prem networkや接続先VNetと重複させない。
clientへ配布するrouteはVNet/on-prem到達性とsplit tunnel/forced tunnelの挙動を決める。custom routeを広告する場合はclient側実routeまで確認する。 Linux向けAzure VPN Clientは2026-08-31でsupport終了。Linux利用を前提にする場合はcurrent supported client/protocol構成を再確認する。
Control plane と data plane
Provider / responsibility boundary
VPN Gateway resource、GatewaySubnet、public IP、connection、Local Network Gateway、BGP設定を管理する。
IPsec packetが通るunderlay。Azure VPN GatewayがSucceededでも、途中のNAT・firewall・ISP品質は別failure domain。
VPN deviceのIKE/IPsec proposal、route/BGP、NAT、policy、HA状態を管理する。Azure側だけではremote peerの実転送を証明できない。
仕組み
P2Sは「VPNがconnected」と「client OSに期待routeがinstallされた」を分けて見る。profileが古いとgateway側変更がclientへ反映されていない場合がある。
client address pool overlapはremote userのlocal LANやVNet/on-prem prefixとの曖昧なrouteを生む。private rangeなら何でも良いわけではない。
Entra authenticationはidentity controlを強化できる一方、tenant/audience/issuer、Azure VPN Client、MFA/Conditional Accessなどidentity planeの依存が増える。
forced tunnelingでは0/1 + 128/1等のroute advertisementを含め、Internet trafficの出口・DNS・security appliance経路まで設計する。
P2S clientからon-premへtransitさせる構成では、VPN Gatewayが学習/広告するrouteだけでなくon-prem側がP2S client poolへのreturn routeを持つ必要がある。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- clientがauthenticationを完了し、P2S address poolからtunnel interfaceへIPを取得する。
- VPN profile/configurationに基づきclient OSへVNet/custom routesがinstallされる。
- destinationがVPN対象prefixならclientはencrypted tunnelへpacketを送る。対象外ならsplit tunnelではlocal Internetへ出る。
- Azure VPN Gatewayが復号し、VNet route/BGP/peeringに従ってworkloadまたはon-prem pathへ転送する。
- reply側はP2S client poolへのrouteをAzure gatewayへ戻す必要がある。NVA/on-prem経由ではreturn route omissionが典型障害になる。
- 障害時はauth failure、tunnel connection、client route、DNS、Azure route/security、applicationの順で分ける。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Client routes | 接続後のOS route tableを必ず採取し、期待Azure/on-prem prefixがVPN adapterへ向くか確認する。 |
| Gateway routes | Azure gatewayがBGP/peeringから学んだprefixがP2S clientへどう配布されるかを確認し、custom route設定との差を管理する。 |
| Return route | VNet/NVA/on-premからP2S poolへのrouteを確認する。forwardだけ通る片方向疎通をDNSやNSGの問題と誤認しない。 |
| Identity vs network | Entra/RADIUS/certificateで接続前に失敗する問題と、接続後packetが届かない問題を別incidentとして切り分ける。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Protocol | client OS・NAT traversal・identity requirementでOpenVPN/IKEv2/SSTPを選ぶ。 | 単純な好みではなくsupported authenticationと端末fleetの実態で決める。 |
| Authentication | managed identity要件が強い環境はEntra、既存AAA統合はRADIUS、閉域/独立運用はcertificate等を比較する。 | identity lifecycle、MFA、revocation、offline operationの責任範囲が異なる。 |
| Routing | split tunnelかforced tunnelかをsecurity/egress要件で明示する。 | Internet出口・DNS・SaaS到達性が大きく変わるため暗黙defaultにしない。 |
| Address pool | 将来の同時接続数と既存VNet/on-prem/home LAN rangeを確認して余裕あるnon-overlap rangeを確保する。 | overlapはclient側routingの診断を難しくし、後からのrenumberingも重い。 |
確認手順
Azure Portal / provider / edge
- VPN Gateway → Point-to-site configurationでaddress pool、tunnel type、authentication、custom routesを確認する。
- 接続clientでassigned VPN IP、adapter、route table、DNS server、VPN client logsを採取する。
- clientからAzure VM/Private Endpoint/on-premへ対象別に試験し、IP疎通と名前解決を分ける。
- Gateway metrics/logsとidentity sign-in/RADIUS logを接続失敗のphaseに応じて突き合わせる。
Verification discipline
- subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
- control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
- advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
- 変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。
az network vnet-gateway show -g <rg> -n <gateway> -o jsonc
az network vnet-gateway list-learned-routes -g <rg> -n <gateway> -o table
az monitor diagnostic-settings list --resource <gateway-resource-id> -o jsoncGet-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <gateway>
Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>
Get-NetRoute | Sort-Object DestinationPrefix,RouteMetric障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| clientが接続前に失敗 | auth/protocol/profile/tenant/certificate/RADIUS | VPN client log + identity/RADIUS log | network route調査へ進む前にauthentication phaseを確定する |
| ConnectedだがVNetへ届かない | client route、overlap、NSG、gateway route | client route table + effective routes | IP destinationを固定しDNS問題と分離する |
| Azureには届くがon-prem不可 | on-premへのBGP/routeとP2S pool return route | gateway learned route、on-prem route、NVA log | 両方向でP2S poolをroute可能か確認する |
| 一部clientだけ異常 | 古いprofile、OS/client version、local LAN overlap | 正常/異常clientのroute/profile/version diff | gateway全体を変更せずendpoint差分を先に特定する |
変更時の確認と rollback
- 変更前にP2S configurationと配布中client profile/version、address pool、custom routeを保存する。
- protocol/auth変更はpilot clientで新profileを検証してから全体配布する。
- forced tunneling変更はInternet/DNS/identity endpointへのreachabilityをrollback条件に含める。
- rollback後は既存接続を切断して再接続し、新profile/routeが実際に適用されたことを確認する。
What changed recently
Azure VPN Client for Linux (Preview) は2026-08-31に廃止済みです。既存installationが動作する場合でもbug fix・security patch・Microsoft supportは提供されないため、本番接続はOpenVPN clientまたはstrongSwan等のcurrent supported optionへ移行します。Entra認証構成もMicrosoft管理App IDのcurrent guidanceとclient support matrixを確認します。