App Serviceからオンプレミスに疎通確認を実施する方法#Azureリレー
2021-10-27
azblob://2022/11/11/eyecatch/2021-10-26-how-to-test-communication-from-appservice-000.jpg

初めに

FIXERの藤井です。先週の弊社の松枝による「診断設定がキレイに消えずにモヤモヤする #Azureリレー」に続き、今週のAzure リレーを担当いたします。

今回は「ハイブリッドクラウド環境(Azure - オンプレミス)」を構築するときに、たいていは必要になる「App Serviceから接続先のオンプレミス環境に疎通確認する方法」について、具体的な設定手順の例を紹介いたします。

App ServiceにはWindows OS基盤とLinux OS基盤の種類が存在し、今回はLinux OS基盤の場合にのみ利用できる"tcptraceroute"コマンドについて、必要な設定手順を紹介いたします。 "tcptraceroute"コマンドは一般的な端末環境 では"tracert"に相当し、指定したIPアドレス/Portに到達するまでの各通過点の情報と、到達までの所要時間について確認ができます。

環境の準備

今回構築する環境について

今回はApache をインストールしたAzure 仮想マシン(Ubuntu)をオンプレミスのサーバーに見立てて、App Serviceからの疎通確認を実施します。
簡略化のため以下の点を割愛しておりますので、読者の皆様がお試しになるときはご留意いただくようお願いします。

  • 簡略化のポイント(1)仮想マシン側のAuzre Network Security Groupの設定をかなりユルユルで設定しています。具体的には"ICMP"プロトコル及び22番ポート(SSH)について、インターネット全体に開放しておりますが、いわゆる「やっちゃいけないやつ」です。あくまで作ってすぐに潰す前提であるということで、ご容赦ください。実際はアクセス元のグローバルIPアドレスを絞り込むのが定石です。
  • 簡略化のポイント(2)上記の1つ目のポイントと関連しますが、閉域網を構築せずに、インターネット経由でApp Service からオンプレミスのネットワークに接続するときは、オンプレミス側でApp Serviceの「送信IPアドレス」と「追加の送信IPアドレス」をそれぞれ許可対象として設定しますが、今回はそもそもインターネットに全開放しているので実施していません。
  • 簡略化のポイント(3)今回はAzure 仮想マシン(Ubuntu)のOS側のファイアウォールは無効の状態です。通常のサーバー環境であれば、OS側のファイアーウォールはWindowsにせよLinuxにせよ設定されているものですので、適宜で許可を設定します。

App Service側の構築

コマンドラインツールのAzure CLIを利用して、App Seivice環境を構築したのちに、Azure Portalから「Web SSH」を開いて、必要な設定を追加します。 "tcptraceroute"コマンド を実行するために必要な「Java 11」ランタイムおよび、「Java SE」はApp Serviceの構築時に設定します。

  1. 以下のコマンドによりAzure のサブスクリプションにログインします。
    az login
  2. 以下のコマンドにより「techblog」の名前でリソースグループを作成します。
    az group create --name techblog --location japaneast
  3. 以下のコマンドにより「techblog-appsrvplan」の名前でLinux OS基盤のApp Service Planを作成します。
    az appservice plan create -g techblog -n techblog-appsrvplan --is-linux --sku B1
  4. 以下のコマンドによりApp Seviceを構築します。【App Service名】はグローバルで一意である必要が有ります。
    az webapp create -g techblog -p techblog-appsrvplan -n 【App Service名】 --runtime "JAVA|11"
    ※PowerShell からAzure CLIを実行する場合、「|(半角パイプ)」を含むコマンドを実行するためには、以下のように「az --% webapp~」のように「--%」を挿入します。
    az webapp create -g techblog -p techblog-appsrvplan -n 【App Service名】 --runtime "JAVA|11"
  5. App Seivice がデプロイできたら、Azure Portalよりアクセスして左側のメニューより「SSH」を選択し、「移動→」をクリックします。
  6. 遷移先の「Web SSH」にて以下の各コマンドを順番に実行します。
    apk update
    apk add tcptraceroute
    cd /usr/bin
    wget http://www.vdberg.org/~richard/tcpping
    chmod 755 tcpping
    apk add bc
  7. 上記の各コマンドが完了したらApp Service 側の設定は完了です。

VM側の構築

  1. 以下のコマンドにより、仮想ネットワークとサブネットを作成します。
    az network vnet create -g techblog -n vnet --address-prefix 10.0.0.0/16 --subnet-name subnet --subnet-prefix 10.0.0.0/24
  2. 以下のコマンドによりLinux 仮想マシンを作成します。【パスワード】は任意で作成します。
    az vm create --admin-username fixeradmin --admin-password 【パスワード】 -n ubuntu -g techblog --location japaneast --vnet-name vnet --subnet subnet --public-ip-address-allocation static --image CentOS --size Standard_A2 --generate-ssh-keys
  3. 以下のコマンドにより、"ICMP"プロトコルを許可する受信セキュリティ規則を追加します。
    az network nsg rule create -g techblog --nsg-name ubuntuNSG -n allowIcmp --protocol Icmp --destination-port-ranges "*" --priority 100
  4. 以下のコマンドにより、80番ポート(HTTP)を許可する受信セキュリティ規則を追加します。
    az network nsg rule create -g techblog --nsg-name ubuntuNSG -n allowHttp --priority 200
  5. 以下のコマンドにより仮想マシンのパブリックIPアドレスを確認します。
    az vm show --resource-group techblog --name ubuntu -d --query publicIps -o tsv
  6. 以下のコマンドにより上記で確認した【パブリックIPアドレス】を使ってssh接続でログインします。
    ssh -l fixeradmin 【パブリックIPアドレス】
  7. ログインしたLinux環境を以下のコマンドにて更新します。
    sudo apt update
  8. Linux環境にて以下のコマンドを実行してApacheをインストールします。
    sudo apt install apache2
  9. Linux環境にて以下のコマンドを実行しApacheが正常に起動していることを確認します。下図はその例です。
    sudo systemctl status apache2
  10. すでに確認済みのパブリックIPアドレスを含む以下のURをブラウザのアドレスバーに入力してApacheのデフォルト画面が表示されることを確認します。
    http://【パブリックIPアドレス】

疎通確認の実行

  1. Azure Portal よりApp Serviceを開き左側のメニューより「高度なツール」を選択し、「移動→」をクリックします。
  2. 遷移先の画面にて上部のメニューより「Bash」を選択します。
  3. デバックコンソールにて、仮想マシンのIPアドレスを指定して以下のコマンドを実行します。
    ※実行結果が表示されるまで1-2分程度以上、待つ場合があります。
    tcptraceroute 【IPアドレス】80
  4. 下図は実行の成功例です。

App Service からオンプレミスに接続し、いわゆる「ハイブリッドクラウド」を構成するとき、初心者が最初に気になる典型的なポイントとは、「疎通確認をとる方法の有無」です。今回はかなり簡略版ですが、実際に疎通確認をとる方法を紹介してみました。導入時の検証だけでなく、トラブルシューティング時の切り分けでも出番があるかと思います。

読者の皆様の参考になれば幸いです。