翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
トラブルシューティング AWS Transfer Family
次の情報は、 の使用時に発生する可能性がある一般的な問題の診断と修正に役立ちます AWS Transfer Family。
Transfer Family の IAM に関する問題については、AWS Transfer Family ID とアクセスのトラブルシューティングを参照してください。
トピック
- サービス管理ユーザーのトラブルシューティング
- Amazon API Gateway の問題をトラブルシューティングする
- 暗号化された Amazon S3 バケットのポリシーのトラブルシューティング
- 認証の問題のトラブルシューティング
- マネージド型ワークフローの問題のトラブルシューティング
- ワークフローの復号に関する問題のトラブルシューティング
- Amazon EFS の問題をトラブルシューティングする
- ID プロバイダーのテストのトラブルシューティング
- SFTP コネクターにトラステッドホストキーを追加する際のトラブルシューティングを行います。
- ファイルアップロードの問題のトラブルシューティング
- ResourceNotFound 例外のトラブルシューティング
- SFTP コネクタの問題のトラブルシューティング
- AS2 の問題をトラブルシューティングする
サービス管理ユーザーのトラブルシューティング
このセクションでは、以下の問題に対する可能な解決策を説明します。
Amazon EFS サービス管理ユーザーのトラブルシューティング
説明
sftp
コマンドを実行した場合にプロンプトの代わりに次のメッセージが表示されることがあります。
Couldn't canonicalize: Permission denied Need cwd
原因
AWS Identity and Access Management (IAM) ユーザーのロールには、Amazon Elastic File System (Amazon EFS) へのアクセス許可がありません。
対策
ユーザーのロールについてポリシーのアクセス権限を増やします。などの AWS 管理ポリシーを追加できますAmazonElasticFileSystemClientFullAccess
。
公開鍵本文が長すぎる場合のトラブルシューティング
説明
サービス管理対象ユーザーを作成しようとすると、次のエラーが表示されます。
Failed to create user (1 validation error detected: 'sshPublicKeyBody' failed to satisfy constraint: Member must have length less than or equal to 2048)
原因
パブリックキー本文に PGP キーを入力する可能性があり、 AWS Transfer Family はサービスマネージドユーザーの PGP キーをサポートしていません。
解決策
PGP 鍵が RSA ベースの場合は、PEM 形式に変換できます。たとえば、Ubuntu は次のような変換ツールを提供しています:https://manpages.ubuntu.com/manpages/xenial/man1/openpgp2ssh.1.html
SSH 公開鍵の追加に失敗した場合のトラブルシューティング
説明
サービス管理ユーザーの公開鍵を追加しようとすると、次のエラーが表示されます。
Failed to add SSH public key (Unsupported or invalid SSH public key format)
原因
SSH2 形式のパブリックキーをインポートしようとしている可能性があり、 AWS Transfer Family はサービスマネージドユーザーの SSH2-formattedパブリックキーをサポートしていません。
解決策
キーを OpenSSH 形式に変換する必要があります。このプロセスは、「SSH2 公開鍵を PEM 形式に変換します。」で説明されています。
Amazon API Gateway の問題をトラブルシューティングする
このセクションでは、以下の API Gateway の問題に対して考えられる解決策について説明します。
トピック
認証失敗の回数が多すぎる
説明
Secure Shell (SSH) File Transfer Protocol (SFTP) を使用してサーバーに接続しようとすると、次のエラーが発生します。
Received disconnect from 3.15.127.197 port 22:2: Too many authentication failures Authentication failed. Couldn't read packet: Connection reset by peer
原因
入力したユーザーパスワードが正しない可能性があります。もう一度、正しいパスワードを入力してみてください。
パスワードが正しい場合、この問題はロールの Amazon リソースネーム(ARN)が有効でないことが原因かもしれません。それが原因であることを確認するには、サーバーの ID プロバイダをテストします。次のようなレスポンスが表示される場合、すべてがゼロのロール ID 値は、ロール ARN がプレースホルダーのみであることを示します。
{ "Response": "{\"Role\": \"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\": \"/\"}", "StatusCode": 200, "Message": "", "Url": "https://
api-gateway-ID
.execute-api.us-east-1.amazonaws.com/prod/servers/transfer-server-ID
/users/myuser/config" }
解決策
プレースホルダーロール ARN をサーバーへのアクセス権限がある実際のロールに置き換えます。
ロールを更新するには
-
https://console.aws.amazon.com/cloudformation
で AWS CloudFormation コンソールを開きます。 -
左のナビゲーションペインで [Stacks] (スタック) をクリックします。
-
「スタック」リストでスタックを選択し、「パラメータ」タブを選択します。
-
[更新] を選択します。「スタックの更新」ページで、「現在のテンプレートを使用する」を選択し、「次へ」を選択します。
-
を、Transfer Family サーバーにアクセスするための十分なアクセス許可を持つロール ARN UserRoleArnに置き換えます。
注記
必要なアクセス許可を付与するには、ロールに
AmazonAPIGatewayAdministrator
およびAmazonS3FullAccess
マネージドポリシーを追加します。 -
「次へ」を選択し、もう一度「次へ」を選択します。
スタック
の確認ページで、IAM リソース を作成する AWS CloudFormation 可能性があることを確認してから、スタックの更新 を選択します。
接続が終了する
説明
Secure Shell (SSH) File Transfer Protocol (SFTP) を使用してサーバーに接続しようとすると、次のエラーが発生します。
Connection closed
原因
この問題の考えられる原因の 1 つは、Amazon CloudWatch ログ記録ロールに Transfer Family との信頼関係がないことです。
解決策
サーバのロギングロールが Transfer Family と信頼関係にあることを確認します。詳細については、「信頼関係を確立するには」を参照してください。
暗号化された Amazon S3 バケットのポリシーのトラブルシューティング
説明
暗号化された Amazon S3 バケットがTransfer Family サーバーのストレージとして使用されています。サーバーにファイルをアップロードしようとすると、「Couldn't close
file: Permission denied
」エラーが表示されます。
そしてサーバーログを表示すると、次のエラーが表示されます。
ERROR Message="Access denied" Operation=CLOSE Path=/bucket/user/test.txt BytesIn=13 ERROR Message="Access denied"
原因
IAM ユーザーのポリシーには、暗号化されたバケットにアクセスする権限がありません。
解決策
必要な AWS Key Management Service (AWS KMS) アクセス権限を付与するには、ポリシーに追加のアクセス権限を指定する必要があります。詳細については、「Amazon S3 でのデータ暗号化」を参照してください。
認証の問題のトラブルシューティング
このセクションでは、以下の認証問題に対して考えられる解決策について説明します。
認証エラー-SSH/SFTP
説明
Secure Shell (SSH) File Transfer Protocol (SFTP) を使用してサーバーに接続しようとすると、次のようなメッセージが表示されす。
Received disconnect from 3.130.115.105 port 22:2: Too many authentication failures Authentication failed.
注記
API Gateway を使用していて、このエラーが表示される場合は、認証失敗の回数が多すぎるを参照してください。
原因
ユーザーの RSA キーペアを追加していないので、代わりにパスワードを使って認証する必要があります。
解決策
sftp
コマンドを実行する際、-o
PubkeyAuthentication=no
オプションを指定します。このオプションは、システムにパスワードを要求させます。例:
sftp -o PubkeyAuthentication=no
sftp-user
@server-id
.server.transfer.region-id
.amazonaws.com
マネージド AD のレルム不一致問題
説明
ユーザーのレルムとグループのレルムを一致する必要があります。両方ともデフォルトレルム内にあるか、または両方とも信頼されるレルムに属している必要があります。
原因
ユーザーとそのグループが一致しない場合、そのユーザーはTTransfer Family ilyによって認証されません。ユーザーの ID プロバイダーをテストすると、「ユーザーのグループに関連するアクセスが見つかりません
」というエラーが表示されます。
解決策
グループレルム (デフォルトまたは信頼できる) と一致するユーザーのレルム内のグループを参照します。
その他の認証に関する問題
説明
認証エラーが発生し、他のトラブルシューティングは実行されません。
原因
先頭または末尾にスラッシュ (/) を含む論理ディレクトリのターゲットを指定した可能性があります。
解決策
論理ディレクトリのターゲットを更新して、先頭がスラッシュで、末尾にスラッシュが含まれていないことを確認してください。例えば、 /DOC-EXAMPLE-BUCKET/images
は許容されますが、 DOC-EXAMPLE-BUCKET/images
と /DOC-EXAMPLE-BUCKET/images/
は許容されません。
マネージド型ワークフローの問題のトラブルシューティング
このセクションでは、以下のワークフロー問題に対して考えられる解決策について説明します。
Amazon を使用したワークフロー関連のエラーのトラブルシューティング CloudWatch
説明
ワークフローに問題がある場合は、Amazon CloudWatch を使用して原因を調査できます。
原因
いくつかの原因が考えられるので、Amazon CloudWatch Logs を使用して調査します。
解決策
Transfer Family は、ワークフロー実行ステータスを CloudWatch Logs に出力します。 CloudWatch ログには、次のタイプのワークフローエラーが表示されることがあります。
-
"type": "StepErrored"
-
"type": "ExecutionErrored"
-
"type": "ExecutionThrottled"
-
"Service failure on starting workflow"
ワークフローの実行ログは、異なるフィルターやパターン構文を使ってフィルターすることができます。例えば、ログに CloudWatch ログフィルターを作成して、ExecutionErroredメッセージを含むワークフロー実行ログをキャプチャできます。詳細については、「Amazon Logs ユーザーガイド」の「サブスクリプションを使用したログデータのリアルタイム処理」および「フィルターとパターン構文」を参照してください。 CloudWatch
StepErrored
2021-10-29T12:57:26.272-05:00 {"type":"StepErrored","details":{"errorType":"BAD_REQUEST","errorMessage":"Cannot tag Efs file","stepType":"TAG","stepName":"successful_tag_step"}, "workflowId":"w-abcdef01234567890","executionId":"1234abcd-56ef-78gh-90ij-1234klmno567", "transferDetails":{"serverId":"s-1234567890abcdef0","username":"lhr","sessionId":"1234567890abcdef0"}
ここで、StepErrored
はワークフロー内のステップでエラーを生成したことを示します。1 つのワークフローには複数のステップを設定できます。このエラーでは、どのステップでエラーが発生したかがエラーメッセージに表示されます。しかし、Amazon EFS ファイルシステム内のファイルへのタグ付けはサポートされていないため、このステップはエラーを生成しました。
ExecutionErrored
2021-10-29T12:57:26.618-05:00 {"type":"ExecutionErrored","details":{},"workflowId":"w-w-abcdef01234567890", "executionId":"1234abcd-56ef-78gh-90ij-1234klmno567","transferDetails":{"serverId":"s-1234567890abcdef0", "username":"lhr","sessionId":"1234567890abcdef0"}}
ワークフローで実行できないステップがあると、「ExecutionErrored
」というメッセージが表示されます。 たとえば、特定のワークフローに設定したステップのうち 1 つのステップを実行できないと、ワークフロー全体が失敗します。
Executionthrottled
ワークフローが、システムがサポートできる速度よりも速い速度でトリガーされる場合、実行はスロットルされます。このログメッセージは、ワークフローの実行速度を落とす必要があることを示しています。ワークフロー実行率をスケールダウンできない場合は、 へのお問い合わせ AWS Support で AWS
ワークフロー開始時に発生したサービス障害
サーバーからワークフローを削除し、新しいワークフローに置き換える場合、またはサーバー構成を更新する場合(ワークフローの実行ロールに影響する)、新しいワークフローを実行する前に約 10 分間待機する必要があります。Transfer Familyサーバーはワークフローの詳細をキャッシュし、サーバーがキャッシュを更新するのに10分かかります。
さらに、アクティブなSFTPセッションからログアウトし、10分間の待ち時間の後にログインし直すと、変更を確認できます。
ワークフローコピーエラーのトラブルシューティング
説明
アップロードされたファイルをコピーするステップを含むワークフローを実行している場合、以下のエラーが発生する可能性がある:
{ "type": "StepErrored", "details": { "errorType": "BAD_REQUEST", "errorMessage": "Bad Request (Service: Amazon S3; Status Code: 400; Error Code: 400 Bad Request; Request ID:
request-ID
; S3 Extended Request ID:request-ID
Proxy: null)", "stepType": "COPY", "stepName": "copy-step-name
" }, "workflowId": "workflow-ID
", "executionId": "execution-ID
", "transferDetails": { "serverId": "server-ID
", "username": "user-name
", "sessionId": "session-ID
" } }
原因
ソースファイルは、レプリケート先バケット AWS リージョン とは異なる にある Amazon S3 バケットにあります。
解決策
コピーステップを含むワークフローを実行する場合、コピー元とコピー先のバケットが同じ AWS リージョンにあることを確認します。
ワークフローの復号に関する問題のトラブルシューティング
このセクションでは、暗号化されたワークフローに関する以下の問題に対して考えられる解決策について説明します。
署名付き暗号化ファイルのエラーのトラブルシューティング
説明
復号ワークフローが失敗し、次のエラーが表示されます。
"Encrypted file with signed message unsupported"
原因
Transfer Family は現在、暗号化されたファイルの署名をサポートしていません。
解決策
PGP クライアントで、暗号化されたファイルに署名するオプションがある場合は、選択をクリアしてください。Transfer Family は現在、暗号化されたファイルの署名をサポートしていないためです。
FIPS アルゴリズムのエラーのトラブルシューティング
説明
復号化ワークフローが失敗し、ログメッセージが次のように表示されます。
{ "type": "StepErrored", "details": { "errorType": "BAD_REQUEST", "errorMessage": "File encryption algorithm not supported with FIPS mode enabled.", "stepType": "DECRYPT", "stepName": "
step-name
" }, "workflowId": "workflow-ID
", "executionId": "execution-ID
", "transferDetails": { "serverId": "server-ID
", "username": "user-name
", "sessionId": "session-ID
" } }
原因
Transfer Family サーバーでは FIPS モードが有効になっており、関連する復号化ワークフローステップがあります。Transfer Family サーバーにアップロードする前にファイルを暗号化すると、暗号化クライアントは FIPS で承認されていない対称暗号化アルゴリズムを使用する暗号化ファイルを生成する可能性があります。このようなシナリオでは、ワークフローはファイルを復号化できません。次の例では、GnuPG バージョン 2.4.0 は OCB (非 FIPS ブロック暗号モード) を使用してファイルを暗号化しています。これによりワークフローが失敗します。
解決策
ファイルの暗号化に使用した GPG キーを編集し、再暗号化する必要があります。次の手順では、実行する必要のある手順について説明します。
PGP キーを編集するには
-
次のコマンドを実行して、編集する必要のあるキーを特定します。
gpg ‐‐list-keys
これにより、キーのリストが返されます。各キーには次のような詳細が含まれます。
pub ed25519 2022-07-07 [SC] wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY uid [ultimate] Mary Major <marymajor@example.com> sub cv25519 2022-07-07 [E]
-
編集するキーを特定します。前の手順で示した例では、ID は
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
です。 -
gpg ‐‐edit-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
を実行します。システムから GnuPG プログラムと指定されたキーに関する詳細を応答します。
-
gpg>
プロンプトで、showpref
を入力します。以下の詳細情報が返されます。[ultimate] (1). Mary Major <marymajor@example.com> Cipher: AES256, AES192, AES, 3DES AEAD: OCB Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, AEAD, Keyserver no-modify
キーに保存されている推薦アルゴリズムが一覧表示されていることに注意してください。
-
OCB を除くすべてのアルゴリズムを保持するようにキーを編集したいと考えています。
setpref
保持するすべてのアルゴリズムを指定してコマンドを実行します。gpg> setpref AES256, AES192,AES,3DES,SHA512, SHA384, SHA256, SHA224, SHA1,ZLIB, BZIP2, ZIP, Uncompressed
これは以下の詳細を返す:
Set preference list to: Cipher: AES256, AES192, AES, 3DES AEAD: Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Really update the preferences? (y/N)
-
「
y
update」と入力して更新し、変更を確認するプロンプトが表示されたらパスワードを入力します。 -
変更を保存します。
gpg> save
復号化ワークフローを再実行する前に、編集したキーを使用してファイルを再暗号化する必要があります。
Amazon EFS の問題をトラブルシューティングする
このセクションでは、以下の Amazon EFS の問題に対して考えられる解決策について説明します。
POSIX プロファイルが見つからない場合のトラブルシューティング
説明
サーバーに Amazon EFS ストレージを使用していて、カスタム ID プロバイダーを使用している場合は、POSIX プロファイルを AWS Lambda 関数に提供する必要があります。
原因
考えられる原因のひとつは、 AWS Lambdaに対応した Amazon API Gateway のメソッドを作成するためのテンプレートが、現在 POSIX 情報を含んでいないことです。
POSIX 情報を提供した場合、POSIX 情報を提供するために使用したフォーマットが、Transfer Family によって正しく解析されていない可能性があります。
解決策
PosixProfile
パラメータに JSON 要素を Transfer Family に提供していることを確認します。
例えば、Python を使用している場合、PosixProfile
パラメータをパースする箇所に以下の行を追加することができる:
if PosixProfile: response_data["PosixProfile"] = json.loads(PosixProfile)
または、 で次の行 JavaScriptを追加できます。ここで、
と uid-value
は、それぞれユーザー ID (UID) とグループ ID (GID) を表す整数 0 以上です。gid-value
PosixProfile: {"Uid":
uid-value
, "Gid":gid-value
},
これらのコード例では、PosixProfile
パラメータを文字列としてではなく、JSON オブジェクトとして Transfer Family に送信しています。
また、 内では AWS Secrets Manager、 PosixProfile
パラメータを次のように保存する必要があります。
とyour-uid
を GID と UID の実際の値に置き換えてください。your-gid
{"Uid":
your-uid
, "Gid":your-gid
, "SecondaryGids": []}
Amazon EFS による論理ディレクトリのトラブルシューティング
説明
ユーザーのホームディレクトリが存在せず、ユーザーが ls
コマンドを実行すると、システムは次のように応答します。
sftp> ls remote readdir ("/"): No such file or directory
原因
Transfer Family サーバーが Amazon EFS を使用している場合は、ユーザーが論理ホームディレクトリで作業するには、ユーザーのホームディレクトリを読み取りおよび書き込みアクセスで作成する必要があります。ユーザーは自分の論理ホームディレクトリに対する mkdir
の権限がないため、このディレクトリを自分で作成することはできません。
解決策
親ディレクトリへの管理アクセス権を持つユーザーは、ユーザーの論理ホームディレクトリを作成する必要があります。
ID プロバイダーのテストのトラブルシューティング
説明
コンソールまたは TestIdentityProvider
API コールを使用して ID プロバイダーをテストする場合、Response
フィールドは空です。例:
{ "Response": "{}", "StatusCode": 200, "Message": "" }
原因
最も考えられる原因は、ユーザー名やパスワードが間違っているために認証が失敗したことです。
解決策
ユーザーの認証情報が正しいことを確認し、必要に応じてユーザー名またはパスワードを更新してください。
SFTP コネクターにトラステッドホストキーを追加する際のトラブルシューティングを行います。
説明
SFTP コネクタを作成または編集しているときに、トラステッドホストキーを追加しようとすると、次のエラーが表示されます。Failed to edit connector details (Invalid host key format.)
原因
正しいパブリックキーを貼り付けた場合、問題は key. AWS Transfer Family does の comment
部分が現在キーのコメント部分を受け入れていないことである可能性があります。
解決策
キーのコメント部分をテキストフィールドに貼り付けると、そのキーのコメント部分が削除されます。例えば、あなたのキーが以下のようなものだとする:
ssh-rsa AAAA...== marymajor@dev-dsk-marymajor-1d-c1234567.us-east-1.amazon.com
==
文字の後に続くテキストを削除し、キーの最初の部分と==
を含む部分だけを貼り付けます。
ssh-rsa AAAA...==
ファイルアップロードの問題のトラブルシューティング
このセクションでは、次のファイルアップロードの問題の考えられる解決策について説明します。
Amazon S3 ファイルアップロードエラーのトラブルシューティング
説明
Transfer Family を使用して Amazon S3 ストレージにファイルをアップロードしようとすると、次のエラーメッセージが表示されます。AWS Transfer は S3 オブジェクトへのランダムアクセス書き込みをサポートしていません。
原因
サーバーのストレージに Amazon S3 を使用している場合、Transfer Family は 1 回の転送で複数の接続をサポートしていません。
解決策
Transfer Family サーバーのストレージに Amazon S3 を使用している場合は、1 回の転送に複数の接続を使用することを記載しているクライアントソフトウェアのオプションをすべて無効にします。
読み取り不可能なファイル名のトラブルシューティング
説明
アップロードしたファイルの一部に壊れたファイル名が表示される。FTP や SFTP での転送で、ウムラウト、アクセント付きの文字、中国語やアラビア語などの特定の文字など、ファイル名の特定の文字が文字化けする問題が発生することがあります。
原因
FTP プロトコルと SFTP プロトコルではファイル名の文字エンコーディングをクライアントがネゴシエートできますが、Amazon S3 と Amazon EFS ではできません。代わりに、UTF-8 文字エンコードが必要です。その結果、特定の文字が正しく表示されません。
解決策
この問題を解決するには、クライアントアプリケーションでファイル名の文字エンコーディングを確認し、UTF-8 に設定されていることを確認します。
ResourceNotFound
例外のトラブルシューティング
説明
リソースが見つからないというエラーが表示されます。たとえば、UpdateServer
を実行すると、エラーが返されます。
An error occurred (ResourceNotFoundException) when calling the UpdateServer operation: Unknown server
原因
ResourceNotFoundException
メッセージを受信する理由はいくつかあります。ほとんどの場合、API コマンドで指定したリソースは存在しません。既存のリソースを指定した場合、最も可能性の高い原因は、デフォルトリージョンがリソースのリージョンと異なることです。たとえば、デフォルトのリージョンが us-east-1 で、Transfer Family サーバーが us-east-2 にある場合、「未知リソース
」例外が発生します。
デフォルトリージョンの設定について詳しくは、「によるクイック設定」を参照してください。aws configure
解決策
API コマンドにリージョンパラメータを追加して、特定のリソースの場所を明示的に指定します。
aws transfer -describe-server --server-id
server-id
--region us-east-2
SFTP コネクタの問題のトラブルシューティング
このセクションでは、以下の SFTP コネクタの問題に対して考えられる解決策について説明します。
キーネゴシエーションが失敗する
説明
キー交換ネゴシエーションが失敗するエラーが表示されます。例:
Key exchange negotiation failed due to incompatible host key algorithms. Client offered: [ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, rsa-sha2-512, rsa-sha2-256] Server offered: [ssh-rsa]
原因
このエラーは、サーバーがサポートするホストキーアルゴリズムとコネクタがサポートするホストキーアルゴリズムが重複していないためです。
解決策
リモートサーバーが、エラーメッセージに記載されているクライアントホストキーアルゴリズムの少なくとも 1 つをサポートしていることを確認してください。サポートされているアルゴリズムのリストについては、「AWS Transfer Family SFTP コネクタのセキュリティポリシー」を参照してください。
その他の SFTP コネクタの問題
説明
の実行後にエラーが表示されますがStartFileTransfer
、問題の原因は不明であり、API コール後にコネクタ ID のみが返されます。
原因
このエラーにはいくつかの原因が考えられます。トラブルシューティングを行うには、コネクタをテストし、 CloudWatch ログを検索することをお勧めします。
解決策
-
コネクタをテストする:「」を参照してくださいSFTP コネクタをテストします。。テストに失敗した場合、システムは失敗の理由に基づいたエラーメッセージを提供します。このセクションでは、コンソールまたは TestConnection API コマンドを使用してコネクタをテストする方法について説明します。
-
コネクタの CloudWatch ログを表示する:「」を参照してくださいSFTP コネクタのログエントリの例。このトピックでは、SFTP コネクタログエントリの例と、適切なログを見つけるのに役立つ命名規則について説明します。
AS2 の問題をトラブルシューティングする
適用宣言書 2 (AS2) 対応サーバーのエラーメッセージとトラブルシューティングのヒントについては、以下を参照してください。AS2 エラーコード