ポイント対サイト VPN に関する重要な通知について

Azure 仮想ネットワーク ゲートウェイを使ってポイント対サイト VPN(P2S VPN)のサービスをご利用いただいているお客様に影響が出る可能性があるメンテナンスについて、弊社サイトにてアナウンスさせていただきました。   Transition from self-signed to public CA certificates for P2S gateways https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-point-to-site-gateway-public-ca   このメンテナンスの内容を正しく理解いただくため、今回のメンテナンスの技術的な背景や事前にご協力いただきたい作業について、本ブログにて補足させていただきます。   背景 P2S VPN で利用される証明書について P2S VPN は、SSL を利用した SSTP という VPN プロトコルを使って動作いたします。 このため、P2S VPN クライアントと仮想ネットワーク ゲートウェイ間で SSL を確立するための、サーバー証明書が仮想ネットワーク ゲートウェイ側に設定されます。   この証明書はお客様が作成するクライアントの認証で利用される証明書とは異なり、仮想ネットワーク ゲートウェイ作成時に自動的に構成されます。   このサーバー証明書は、自己署名された認証局によって署名されており、認証局も証明書も有効期間は 3 年で構成されていました。 また、自動的に生成されたサーバー証明書を P2S VPN クライアント側で正しく検証を行うため、VPN クライアントパッケージをインストールする際に自己署名した認証局の公開証明書をクライアントの証明書ストアに配置していました。   以前の仮想ネットワーク ゲートウェイの動作では、証明書の更新に伴いこの自己署名された認証局も更新されていました。 この結果、クライアントの証明書ストアに配置された認証局の公開証明書と仮想ネットワーク…


Azure ロードバランサー利用時の注意点

こんにちは、Azure サポートチームの檜山です。 今回は Azure ロードバランサーの利用にあたり、よくあるお問い合わせで代表的なものについてご紹介させていただきます。 Azure ロードバランサー利用時に想定した動作ができないといった時に制限事項にあてはまっている場合がございますので、そのような時はご一読いただけますと幸いです。 また、Azure ロードバランサーを経由した通信のトラブルシューティングについては以下もご参照ください。 ロードバランサー経由での通信ができない場合のチェックポイント https://blogs.technet.microsoft.com/jpaztech/2016/11/23/loadbalancer-troubleshooting/ Azure ロードバランサー (内部 [プライベートIP] / 外部 [パブリック IP]) 利用時のよくあるお問合せ Azure ロードバランサー利用時のよくあるお問合せとして以下のようなものがあります。 ロードバランサーのバックエンドプールに VM を追加できない ロードバランサーのバックエンドプールに追加したら外部へ接続できなくなった バックエンドプールに所属した VM からロードバランサーのフロントエンド IP アドレスにアクセスできない Standard SKU の外部ロードバランサーで正常性プローブは成功するが、負荷分散ができない ロードバランサーのフロントエンド IP アドレスの送信元 NAT (SNAT) による外部接続ができない それぞれについて以下に詳細を記載します。 ロードバランサーのバックエンドプールに VM を追加できない こちらの事象についてよくある原因としては以下があります。 1 台の VM を複数のロードバランサーに追加しようとしている ロードバランサーと VM に付与されているパブリック IP アドレスの SKU…

0

詳説 Azure ExpressRoute – Part5: ExpressRoute の増速やプロバイダー変更について

こんにちは。Azure サポートの宇田です。 今回は ExpressRoute 回線の増速や、プロバイダー変更の際の手順についてご紹介いたします。 Part1: ExpressRoute を導入する前に Part2: ExpressRoute のルーティング制御について Part3: ExpressRoute の導入手順について Part4: ExpressRoute の冗長構成について Part5: ExpressRoute の増速やプロバイダー変更について


Load Balancer と Application Gateway の通信の違い

こんにちは、Azure サポートチームの山崎です。 今回は Load Balancer と Application Gateway の通信の違いについてご紹介します。 Load Balancer の場合 Load Balancer を経由する通信は宛先 NAT され、バックエンドのサーバへ転送されます。 [行きの通信] 1.クライアントから Load Balancer への通信 送信元:クライアントの IP 宛先 :Load Balancer のフロントエンド IP 2.Load Balancer からサーバへの通信 送信元:クライアントの IP 宛先 :サーバの IP (宛先 NAT)   [戻りの通信] 3.サーバから Load Balancer への通信 送信元:サーバの IP 宛先 :クライアントの IP 4.Load Balancer からクライアントへの通信 送信元:Load Balancer のフロントエンド  IP 宛先 :クライアントの…

0

詳説 Azure ExpressRoute – Part4: ExpressRoute の冗長構成について

こんにちは。Azure サポートの宇田です。 今回は、ExpressRoute を複数ご契約いただく場合の留意点や、冗長構成の考慮点についてご説明します。 Part1: ExpressRoute を導入する前に Part2: ExpressRoute のルーティング制御について Part3: ExpressRoute の導入手順について Part4: ExpressRoute の冗長構成について Part5: ExpressRoute の増速やプロバイダー変更について


Linux ディストリビューションにおける、Azure 上の動作保証と Azure Site Recovery に関する注意事項

Azure サービスを日々ご利用いただいている皆様こんにちは、Azure サポート チームの工藤です。 今回は、Linux ディストリビューションにおいて、Azure で動作保証された OS バージョンと Azure Site Recovery での保護 (移行・レプリケーション・フェールオーバー・フェールバック) がサポートされる OS バージョンに関する公開情報について、補足情報をご案内いたします。


Azure Load Balancer で IP フラグメンテーションは未サポート

こんにちは、Azure サポートチームの山崎です。 今回は Azure Load Balancer で IP フラグメンテーションされたパケットが通信できない場合の理由と対策についてご紹介します。 IPフラグメンテーションとは 通信を行う際に一度に送信できるパケットのサイズは決まっており、サイズ(MTU)を超える大きなパケットは複数のパケットに分割されます。この分割処理をIPフラグメンテーションと呼びます。   MTU: 1回で送信可能なパケットサイズ(IPヘッダまでのサイズ)   Azure Load Balancer で IP フラグメントされた通信が未サポートの理由 Azure Load Balancer でサポートされている通信はドキュメントに記載のとおり、TCP と UDP のみサポートされています。   https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview#limitations   制限事項 Load Balancer は TCP または UDP 製品であり、これらの特定の IP プロトコルに対する負荷分散とポート フォワーディングを行います。 負荷分散規則と受信 NAT 規則は TCP および UDP についてサポートされており、ICMP を含む他の IP プロトコルについてはサポートされていません。   フラグメントされたパケットは以下のようなパケットになり、TCP、UDP ヘッダがありません。 Azure…

0

[ASM] データセンタ リージョン間の Classic 仮想マシンの移動方法

こんにちは! Azure サポート チームの澤田です。 Azure サポート チームでは ARM デプロイメント モデルを利用した Azure 仮想マシンについてのお問い合わせを多くいただいておりますが、Classic である ASM デプロイメントモデルを利用の仮想マシンについてもお問い合わせを頂いています。ARM では新機能が続々と追加されている状況から、サポートチームとしても ARM の利用を推奨している状況ではありますが、事情により Classic を利用しなければいけない場合がある事も認識しています。本日はそんな Classic ユーザーのご利用者様を対象として、Azure 仮想マシンのデータセンター間での移動方法を纏めてみましたので、ご参考下さい。 ASM ARM に関わらず Azure 仮想マシンではリージョンを跨ぐ移動をサポートしていないため、利用しているリージョンを変更する為には、手動で移動させる必要があります。具体的には、VHD ファイルを残す方法で仮想マシンを削除し、VHD ファイルを移動させ、VHD ファイルから新規で仮想マシンを作成する方法です。 なお以下手順での移動対象はクラウドサービスにシングルで構成しているシンプルな仮想マシンでデータ ディスクがアタッチされている環境を想定しています。 目次 まず初めに、手順の項目を以下で説明します。  仮想マシンを停止させる  仮想マシンにアタッチされているデータディスクの構成を確認する  仮想マシンに紐づく vhd ファイルを移動先のストレージ アカウントへコピーする  仮想マシンを “特殊化” でバックアップする  仮想マシンのエンドポイントや NSG など設定をメモする  仮想マシンをクラウド サービスごと削除する  移動先のデータセンタで新規クラウド サービスを再作成する  移動した vhd ファイルを基に、OS ディスクならびにデータディスクを作成する…

0

Application Gateway (WAF) での脆弱性検知について

こんにちは、Azure サポートチームの山崎です。 今回は Application Gateway で Web アプリケーション ファイアウォール(WAF) 機能をご利用の際によくお問い合わせをいただく “949110” ルールについてご紹介します。 WAF 機能で検知した情報をログから確認したい 一般的な WAF の導入シナリオとして、WAF 機能をいきなり本番環境に導入してしまうとフォールスポジティブや (誤検知) フォールスネガティブ (見逃し) に合致してしまう可能性があります。そのため、まずは本番導入前に通信の破棄は行わず、検知のみを行ってログ情報からフォールスポジティブ、フォールスネガティブが発生していないか確認したいというご要望を多くいただきます。Application Gateway の WAF 機能でも検知モード、ログ出力に対応しており、以下を設定することで導入前のテストを実施いただけます。   検知モード / 防止モード 検知モードでは脆弱性の診断は実施されますが、対象の通信が異常と判定された場合でも通信をブロックせず、後述の Firewall ログにログを保存します。防止モードでは異常と判定された通信をログに保存しつつ、通信もブロックします。   (設定例)[Azure ポータル] Application Gateway 設定の [Web アプリケーション ファイアウォール] から設定します。   なお、防止モードで異常判定され通信をブロックした場合には Application Gateway が 403 エラーをクライアントに送信します。 (403 エラー)   Firewall ログ…

0

[2018/11/14 説明会開催] Azure サポート エンジニア募集中!

日本マイクロソフトの Azure サポートでは、Azure のお客様を日々支えるサポート エンジニアを募集しています! お客様が一番お困りであるとき、最も近い相談相手となる。そういった貴重な機会を通じて、Azure の未来を一緒に作り上げていきませんか。 未曾有の成長・変革のまっただ中であるパブリック クラウドに携わる刺激的な毎日になります。最近では、サポートの技術を集約した書籍を出版し、お問い合わせによるサポート対応という枠を超えたお客様への支え方も模索しています。

0