【Microsoft Azure】App Service/Functionsから接続先リソースへの疎通・名前解決確認を行う

こんばんは。今日は、Azure App Service/Functionsに関する小ネタです。

App ServiceにWebアプリケーションをデプロイし、その裏でさらにデータベースと接続して処理を行う・・といったケースは多いかと思います。

そんな時にいつも思うのが、App Serviceからそれらのリソースにちゃんと想定した経路で接続できているのだろうか・・・ということ。

特に、最近はプライベートエンドポイントやサービスエンドポイント経由でデータベースやストレージに接続するシナリオも多いかと思いますので、プライベートエンドポイント経由で接続していると思ったら実はパブリックアクセスしてた、なんてこともおこりがちです。

今回はそんなときに役立つコマンドを自分の備忘も兼ねて残しておこうと思います。

厳密にはOSやコンテナかどうかなどで使える/使えないが異なるかとは思いますが、今回は、Windows/LinuxのApp Serviceで確認しています。また、クラウドサービスは変化が激しいので、将来的に動作が変わる可能性は十分あると思いますので、あくまで現時点での情報と捉えていただければと思います。

[前提] pingやnslookupは使えない

前提として、App Serviceではpingやnslookupが使えません。

https://docs.microsoft.com/ja-jp/azure/app-service/web-sites-integrate-with-vnet#tools

というわけで、これらの代替として、以下コマンドが用意されています。(後述の通り、Linuxの場合は別のコマンドが使えるようでした)

使えないツール代替ツール
pingtcpping
nslookupnameresolver

こちらにも詳しい説明があります。

https://docs.microsoft.com/ja-jp/archive/blogs/waws/networking-related-commands-for-azure-app-services

疎通確認をする

<Windowsの場合>

上記の通り、tcppingコマンドがデフォルトで使えます。

#コマンド
tcpping xxxx.database.windows.net:1433

#結果
Connected to xxxx.database.windows.net:1433, time taken: 203ms
Connected to xxxx.database.windows.net:1433, time taken: 156ms
Connected to xxxx.database.windows.net:1433, time taken: 140ms
Connected to xxxx.database.windows.net:1433, time taken: 156ms
Complete: 4/4 successful attempts (100%). Average success time: 163.75ms

<Linuxの場合>

Bashからtcppingコマンド自体は使えるようだが、上と同じコマンドをうってもダメだった。なんでだろう・・?分かったらまた更新します。

#コマンド
tcpping xxxx.database.windows.net:1433

#結果
Bad destination address: xxxx.database.windows.net:1433

代わりにtcptracerouteコマンドが使えるようでした。(こちらもBashから)

#コマンド
tcptraceroute xxxx.database.windows.net 1433


#結果
1  172.xx.xx.xx  0.121 ms  0.043 ms  0.042 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  40.xx.xx.xx [open]  8.224 ms  1.696 ms  6.340 ms

名前解決情報を確認する

<Windowsの場合>

上の通り、nameresolverが使えます。

nameresolver xxxx.database.windows.net

<Linuxの場合>

Bashからはnameresolverは使えません。

代わりに以下のコマンドが使えました。

#コマンド
getent hosts xxxx.database.windows.net

#結果
40.xx.xx.xx    cr3.eastus1-a.control.database.windows.net xxxx.database.windows.net xxx.privatelink.database.windows.net xxx.database.windows.net xxxx.trafficmanager.net

また、アプリケーションコンテナにSSH接続するとnameresolverは引き続き使えませんが、nslookupやdigが使えました。(すみません、ネットワーク構成を変更したので上の結果とは整合していないですが、同じネットワーク構成であればこちらでも上記と同じ結果が得られる想定です)

#コマンド
nslookup xxxx.database.windows.net

#結果
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
xxxx.database.windows.net     
canonical name = xxx.privatelink.database.windows.net.
Name:   xxxx.privatelink.database.windows.net
Address: 10.1.1.4
#コマンド
dig 

#結果
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> xxxx.database.windows.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53141
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1224
;; QUESTION SECTION:
;xxxx.database.windows.net. IN        A

;; ANSWER SECTION:
xxxx.database.windows.net. 300 IN CNAME 
xxxx.privatelink.database.windows.net.
xxxx.privatelink.database.windows.net. 10 IN A 10.1.1.4

;; Query time: 21 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Wed Oct 20 17:10:58 UTC 2021
;; MSG SIZE  rcvd: 121

以上、App Service上で接続先リソースへの疎通、名前解決を行える方法のご紹介でした。

おしまい

この記事を気に入っていただけたらシェアをお願いします!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

ABOUT US
Yuu113
初めまして。ゆうたろうと申します。 兵庫県出身、東京でシステムエンジニアをしております。現在は主にデータ分析、機械学習を活用してビジネスモデリングに取り組んでいます。 日々学んだことや経験したことを整理していきたいと思い、ブログを始めました。旅行、カメラ、IT技術、江戸文化が大好きですので、これらについても記事にしていきたいと思っています。