Oracle Cloud Infrastructureドキュメント

ネットワーキングの既知の問題

VCN内の内部接続やオンプレミス・ネットワークへの接続など、ネットワーキング・ファミリのサービスでは、次の既知の問題が特定されています。

関連項目: 「SCNおよび接続のトラブルシューティング」

WindowsインスタンスではアクティブなFTPはサポートされない

詳細
Microsoft Windowsによって提供されるデフォルトのFTPクライアントでは、アクティブ・モードのFTPのみがサポートされていますが、Oracleのステートフル・ファイアウォール・ルールや、NATゲートウェイの背後にデプロイされたインスタンスではこれが機能しません。
回避策
Windowsインスタンスでは、パッシブ・モードで実行されるサードパーティFTPクライアントを使用することをお薦めします。

CPE構成ヘルパーでCPEベンダーの指定に問題がある

詳細

次のことが発生すると、Oracle Consoleに次のようなエラーが表示されます: CPEにベンダー情報(デバイス・タイプ)がありません。CPEを更新し、ベンダー情報を追加してください:

  • CPE構成ヘルパー機能がリリースされる前に存在していたCPEがある。
  • Oracle ConsoleでCPEをまだ編集しておらず、どのベンダーがCPEを作成するかを指定した。
  • CPEまたはそのCPEを使用するIPSec接続のヘルパー・コンテンツを生成しようとしている。
回避策

次のアクションを実行します。

  1. Oracle Consoleで、CPEを表示します。
  2. 「編集」をクリックします。
  3. 「CPEベンダー情報」セクションで、CPEを作成するベンダーを選択します。CPEの作成ベンダーがわからない場合、またはリストにない場合、「その他」を選択します。

  4. プロンプトが表示されたら、「プラットフォーム/バージョン」の値を選択します。ガイドラインを示します:

    • 可能な場合、ルートベースの構成を使用することをお薦めします。
    • リストに特定のCPEプラットフォームまたはバージョンが表示されない場合は、そのCPEバージョンより前の最も新しいプラットフォーム/バージョンを選択します。
  5. 「変更の保存」をクリックします。ベンダーの値を変更していなくても、これをクリックすることが重要です。

その後、CPEまたはそのCPEを使用するIPSec接続のヘルパー・コンテンツを正常に生成できます。

サービス・ゲートウェイを介したオンプレミス・ネットワークからOracle Analytics Cloudへのプライベート・アクセスの問題

詳細
次のすべてを実行すると、オンプレミス・ネットワークとOracle Analytics Cloudの間のトラフィックに対して非対称ルーティングが発生する可能性があります: 非対称ルーティングとは、リクエスト・トラフィックとレスポンス・トラフィックが異なるパスを経由することを意味します。非対称ルーティングが発生する理由の詳細は次を参照してください: Oracle Analytics Cloudがオンプレミス・ネットワーク内のクライアントへの接続を開始する場合、接続リクエストはパブリック・パス(インターネットまたはFastConnectパブリック・ピアリング)を経由する必要があります。ただし、レスポンスは、オンプレミス・ネットワークからOracleへのトラフィックのルーティング・プリファレンスの推奨に基づいて、プライベート・パスを経由します。
回避策が必要となるのは、オンプレミス・ネットワークでクライアントへの接続を開始し、ネットワークでデータ・ゲートウェイをまだ使用しないようにOracle Analytics Cloudを使用する場合のみです。
回避策1(推奨)
Oracle Analytics Cloudで、リモート・データ・コネクタの使用からデータ・ゲートウェイ に切り替えます。
回避策2
Oracle Analytics Cloudのリージョナル・ソースIPアドレスに静的ルートを追加して、インターネットまたはFastConnectパブリック・ピアリング・パスを優先するように顧客構内機器(CPE)を構成します。このようにすると、Oracle Analytics Cloudへのレスポンス・トラフィックは、着信接続リクエストと同じパスに返されます。

サービス・ゲートウェイを介したOracleサービスからパブリック・インスタンスへのアクセスの問題

詳細
VCN内のパブリック・サブネットに関連付けられたルート表に、次の2つの競合するルート・ルールが含まれている場合、Oracleサービスがそのサブネット内のパブリック・インスタンスにアクセスできない可能性があります。
  1. 「ターゲット・タイプ」が「インターネット・ゲートウェイ」に設定されたルート・ルール。
  2. 「宛先サービス」がOracle Services Networkのすべての<region>サービスに、「ターゲット・タイプ」が「サービス・ゲートウェイ」に設定されたルート・ルール。
前述の2つのルート・ルールは、OracleサービスによってVCN内のパブリック・インスタンスへの接続が開始される場合に、非対称ルーティングにつながる可能性があります。Oracle Cloud Infrastructureでは、同じルート表内でこれらのルールが同時にサポートされません。Oracleでは、サービスAPIおよびコンソールが更新され、この構成のサポートが無効になりました。
回避策

「宛先サービス」が「Oracle Services Networkのすべての<region>サービス」に設定され、「ターゲット・タイプ」が「サービス・ゲートウェイ」に設定されているルート・ルールを削除することをお薦めします。Oracle Services Networkのサービス・ゲートウェイを選択する前に使用していた構成に戻してください。この変更により、パブリック・インスタンスは、インターネット・ゲートウェイを介してすべてのOracleサービスにアクセスできるようになります。Oracleサービスは、継続的にパブリック・インスタンスにアクセスできます。

ただし、パブリック・サブネット内のインスタンスは、サービス・ゲートウェイを介してオブジェクト・ストレージに継続的にアクセスできます。「宛先サービス」がOCI <region>オブジェクト・ストレージに設定され、「ターゲット」がVCNのサービス・ゲートウェイに設定されたルート・ルールを含めるようにサブネットのルート表を更新してください。

この既知の問題は、インターネット・ゲートウェイにアクセス可能なパブリック・サブネットにのみ適用されます。プライベート・サブネットについて: VCNのサービス・ゲートウェイを介してOracle Services Networkのすべての<region>サービスまたはOCI <region>オブジェクト・ストレージへのアクセスを提供するようにプライベート・サブネットのルート表を構成することもできます。

サービス・ゲートウェイを介したOracle yumサービスへのインスタンスのアクセスの問題

詳細
インターネット・アクセスにインターネット・ゲートウェイやNATゲートウェイを使用せずにVCNでサービス・ゲートウェイを使用する場合、インスタンスが該当するリージョンのOracle yumサーバーにアクセスできない可能性があります。2つの問題が考えられます:
  • 2018年11月より前に作成されたインスタンスでは、そのリポジトリがサービス・ゲートウェイを介してアクセスできないURLを参照していることがあります
  • 以前はローカル・リージョンのyumサーバーに接続できなかったインスタンスが、yum.oracle.comを使用するように戻され、サービス・ゲートウェイを介してアクセスできなくなることがあります
次のいずれかの緩和策を使用するには、リージョンのyumサーバーに接続できるように、サービス・ゲートウェイ、NATゲートウェイまたはインターネット・ゲートウェイのいずれかのゲートウェイを構成する必要があります。
回避策1(自動)

次の自動軽減策を試してみてください。なんらかの理由で失敗した場合は、後続の手動軽減策の方法を使用してください。

次のスクリプトをローカル・システムにコピーして実行します。スクリプトは、既存のリポジトリを無効にし、repoファイルをダウンロードします。このファイルによって、システムはサービス・ゲートウェイを介してアクセス可能なリージョンのローカルyumサーバーに接続されます。

#!/bin/bash
REPODIR='/etc/yum.repos.d'
REPOS=$REPODIR/*
REGION=$(curl -sfm 3 http://169.254.169.254/opc/v1/instance/ | jq -r '.region' | cut -d '-' -f 2)
VERSION=$(egrep '^VERSION_ID' /etc/os-release | cut -d '"' -f 2 | cut -d '.' -f 1)
REPOURL="http://yum-${REGION}.oracle.com/yum-${REGION}-ol${VERSION}.repo"

echo "Disabling existing repos"
for i in $REPOS
do
  if [[ "$i" != *".disabled" ]]; then
    mv $i $i.disabled
    echo "$i disabled"
  else
    echo "$i repofile already disabled"
  fi
done
yum clean all
echo "Pulling new regional repository file"
wget -q $REPOURL -O "$REPODIR/yum-${REGION}-ol${VERSION}.repo"
retval=$?
if [[ "$retval" -ne 0 ]]; then
  echo "Unable to pull repo file, please run manual steps"
  exit 1
fi
yum makecache fast
回避策2(手動)

自動軽減策が失敗した場合は、問題を手動で軽減できます。ここでは、既存のrepoファイルを無効化し、リージョンのyumサーバーから最新のrepoファイルを取得します。インスタンスのリージョン・キーを確認するには、「リージョンと可用性ドメイン」のリージョン・リストを参照してください。

既存のrepoファイルを無効化するには、/etc/yum.repos.dディレクトリに移動し、ファイル名の最後に.disabledが含まれるように、存在するすべてのファイルの名前を変更します。

例: 

ls /etc/yum.repos.d ksplice-uptrack.repo.disabled public-yum-ol7.repo.disabled

ローカル・システムにリージョンのrepoファイルをダウンロードします。次の例では、Ashburn (リージョン・キーiad)を使用します。iadは、インスタンスに適したリージョン・キーに置き換えてください。

cd /etc/yum.repos.d/
wget http://yum-iad.oracle.com/yum-iad-ol7.repo
chown root:root yum-iad-ol7.repo
yum makecache fast