ヘルプおよびサポートを受ける方法
IBM Cloud ゲートウェイアプライアンス( vFSA, VRA、 vSRX )を使用中に問題が発生した場合や質問がある場合は、サポートケースを開く前に以下のリソースをご利用ください。
- コンソールまたは IBM Cloud CLIから AIアシスタントで 質問する。
- vFSA の既知の制限 を確認します。
- 製品資料で VRA に関する FAQ を確認してください。
- vSRX の既知の制限 を確認します。
- ステータスページで、 IBM Cloud プラットフォームとリソースのステータスを確認してください。
- Stack Overflowで他のユーザーが同じ問題を経験していないか確認してください。 質問するときは、
ibm-cloudとgateway-appliancesのタグをつけて、 IBM Cloud の開発チームに見てもらえるようにしてください。
それでも問題を解決できない場合は、サポート Case をオープンできます。 詳しくは、サポート Case の作成を参照してください。 また、フィードバックを提供したい場合は、 フィードバックを提出するを ご覧ください。
vFSA のサポート Case 詳細の提供
問題のタイムリーな解決を確実にするため、vFSA:に関する問題のサポート・ケースには以下の情報を含めてください:
- Fortinet vFSA とそのバージョンの IP アドレス (10 個のネットワークまたはパブリック・ネットワーク) またはホスト名。
- ネットワーク接続全体で問題が発生している場所を追跡するには、送信元 IP アドレス、宛先 IP アドレス、宛先ポートとプロトコル、および
ping、traceroute、mtr、nmap/netcatなどのネットワーク・ツールからの関連出力を指定します。 - より複雑な問題の場合は、接続の予期されるネットワーク・パスまたはネットワーク・トポロジー・ダイアグラムの基本的な説明が必要です。
- その他の有用な情報には、予期される許可またはブロックを含むセキュリティー・ポリシー名が含まれます。
Virtual Router Appliance のサポート Case の詳細の提供
問題をタイムリーに解決するには、Vyatta の問題のサポート・ケースに以下の情報を含めてください。
- VRA の IP アドレス (10 個のネットワークまたはパブリック・ネットワーク) またはホスト名、およびその NOS バージョン。
- ネットワーク接続全体で問題が発生している場所を追跡するには、送信元 IP アドレス、宛先 IP アドレス、宛先ポートとプロトコル、および
ping、traceroute、mtr、nmap/netcatなどのネットワーク・ツールからの関連出力を指定します。 - より複雑な問題の場合は、接続の予期されるネットワーク・パスまたはネットワーク・トポロジー・ダイアグラムの基本的な説明が必要です。
- その他の有用なトラブルシューティング情報には、ファイアウォール・ルール・セット名、およびトラフィックを許可またはブロックするために予期されるルールのルール番号 (
show firewallの出力を含む) が含まれます。 また、ロギングを有効にして、トラフィックが許可されているかどうかを示すこともできます。 さらに、monitor、tshark、およびtcpdump(パケット・キャプチャー) の各コマンドを使用して、入口インターフェースおよび出口インターフェース上のトラフィックを表示できます。 また、これらのコマンドを使用して、トラフィックが予想されるインターフェイスに表示され、別のインターフェイスには表示されないことを説明することもできる。 この動作は、ブロッキングやルーティングの問題を証明するのに役立つ。 - 問題に関連するすべてのログを収集します。 これを行うには、
journlctl -aを使用するか、syslog 項目を表示するか、show logコマンドを使用します。
vSRX のサポート Case の詳細の提供
問題のタイムリーな解決を確実にするため、vSRX:に関する問題のサポートケースには、以下の情報を含めてください:
-
Juniper vSRX の IP アドレス (10 ネットワークまたはパブリック・ネットワーク) またはホスト名と、そのバージョン。 注意として、
19.4R2-S3以前のバージョンには、一貫性のあるクラスターとクラッシュの問題があります。 これらのバージョンのいずれかを使用している場合は、クラスタリングの問題を一時的に解決するために再起動してください。 また、できるだけ早く最新バージョンに更新する必要があります。 -
ネットワーク接続全体で問題が発生している場所を追跡するには、送信元 IP アドレス、宛先 IP アドレス、宛先ポートとプロトコル、および
ping、traceroute、mtr、nmap/netcatなどのネットワーク・ツールからの関連出力を指定します。 -
より複雑な問題の場合は、接続の予期されるネットワーク・パスまたはネットワーク・トポロジー・ダイアグラムの基本的な説明が必要です。
-
その他の有用な情報には、予期される許可またはブロックを含むセキュリティー・ポリシー名が含まれます。 また、
show security match-policies(タブコンプリートでコマンドの続きを終了)を使って、トラフィックが許可されているかどうかを示すこともできる。 さらに、show security flow sessionコマンドは、Ingress インターフェース上の転送トラフィックと応答トラフィック、およびパケットが 1 つの予期された方向で増加しているかどうかを表示します。 また、traceoptionsを使用して、指定したトラフィックのデバッグ・レベル出力を受信することもできます。 -
ローカルの発信トラフィックと宛先トラフィックについて、
PROTECT-INポリシーに適切な許可設定が含まれているかどうかを確認します。このポリシーは制御プレーンのポリシングに使用されるためです。 -
また、RSIとログファイルを生成する必要がある。 RSIにはシステムの状態に関する情報が含まれ、ログには存在する可能性のある履歴情報が記録される。
スタンドアロン・デバイスの場合、この手順は1ノードにつき1回だけ行う。 HAペアでは、両方のRSIとログをキャプチャする必要がある。 そのためには、ゲートウェイIPにSSH接続してログインする。 以下の例では、ノード1にログインしていると仮定しています:
cli request support information | save /var/log/rsi-node1 file archive compress source /var/log/* destination /var/tmp/node1.tgzこのコマンドはノード1のRSIとログを生成する。 次に、もう一方のノードに移動する:
request routing-engine login node 0 cli request support information | save /var/log/rsi-node0 file archive compress source /var/log/* destination /var/tmp/node0.tgz file copy /var/tmp/node0.tgz node1:/var/tmp/同じファイルがノード0で生成され、圧縮されたファイルがノード1にコピーされる。 セキュアコピーやその他のツールを使って、これらのファイルを
/var/tmpディレクトリからダウンロードすることができます。