クライアントレスVPNポータル経由でSSRSエクスポートが失敗する: 何が異なるのか

レポートはブラウザーで開き、パラメーターはレンダリングされ、エクスポートボタンはエラー、空のダウンロード、またはスプレッドシートが開くのを拒否するファイルを生成する。その組み合わせには標準的な形がある。動作するレポートページはレンダリングと認証を検証しただけで、それ以外は何も検証していない。エクスポートは独自の応答を持つ別の要求であり、クライアントレスポータルを通る場合は、ファイルのダウンロードを想定して設計されたことのない書き換え層も通過する。

二つの経路、一つの動作するページ

レンダリングとエクスポートは、同じボタンから始まっても異なる操作である。レポートサーバーはブラウザー向けにページをレンダリングし、エクスポートは独自のコンテンツタイプと独自のエラー動作を持つ別の出力拡張機能を通じてレンダリングする（これはエクスポートのドキュメントが説明するとおりである）。最初のものを完璧に通すポータルでも、二番目のものを壊すことがある。二番目はポータルが想定していなかった応答であり、両者はセッションとアドレスを共有するが、それ以外はほとんど共有しない。

動作するページは、認証と到達可能性の証拠としてのみ扱う。アカウントがレポートサーバーに到達でき、ポータルがHTMLを転送することを証明する。ファイル応答、コンテンツ配置ヘッダー、またはドキュメントではなくダウンロードで終わるリダイレクトについては何も語らない。

すでに動作しているページを再テストするのではなく、エクスポート経路を単独で比較する理由はまさにそこにある。セッションを共有する二つの要求は、依然として二つの要求である。

エクスポートがどこで壊れるかを決める三つの条件

三つの質問で障害の位置はすぐに定まり、それぞれの答えは異なる所有者を指し示す。

第一に、同じレポート、アカウント、形式が内部ネットワークから正しくエクスポートされるか。そうであれば、レポートサーバーとそのレンダラーは正常で、違いはアクセス経路にある。第二に、失敗した応答がファイルのコンテンツタイプを持つのか、ファイル拡張子をまとったHTMLページなのか。これがレンダラーのエラーとポータルによる置き換えを分ける。第三に、ポータルが要求のURLを書き換えるのか、応答からヘッダーを削除するのか。書き換えられたURLはまったく別のエンドポイントに着地することがある。

設定を変更する前に三つすべてに答えること。それぞれ対処法が異なり、レンダラーの障害はレポートサーバーに属し、置き換えられた本文はポータルに属し、削除されたヘッダーはバグではなくポリシーの問題である。

答えを書き留める。その三行から組み立てたサポートケースは、スクリーンショット十枚分の価値がある。

ステータスコードではなくエクスポート応答を読む

HTTPの成功ステータスは、何かが要求に応答したことだけを証明する。本文とヘッダーを一緒に調べるべきなのは、興味深い障害が誤ったコンテンツを運ぶ成功応答だからである。

curl -sS -D export.headers -o export.bin --location "https://portal.example.com/reports/export?format=xlsx"
file export.bin
head -c 300 export.bin

ヘッダーのダンプは、コンテンツタイプとポータルが返したコンテンツ配置を示す。fileコマンドは本文の実体を特定し、スプレッドシートが期待される場所にあるテキストファイルは古典的な置き換えられたサインインページである。headコマンドは、レポート全体をターミナルに流し込まずにHTMLを認識するのに十分な情報を示す。

そのいずれかを共有する前に、セッションCookieとトークンを削除する。動作するエクスポートのキャプチャーは有用な証拠であり、他人のセッションのキャプチャーはインシデントである。

例外はアカウントではなくアプリケーションに限定する

ポータルが応答を書き換えたり遮断したりしている場合、誘惑される修正はサイト全体を除外するか、レポートを匿名化することだ。どちらもダウンロードを直し、ポータルが存在する理由を取り除く。範囲を絞った例外は、一つのアプリケーションパス、一つのコンテンツタイプ、一つの方向を指定し、ポリシーを所有する者が引き続きレビューできる。

実際に運用しているゲートウェイのバージョンと、その文書化されたアプリケーション設定を使う。ベンダーがかつてトラフィックを変更しないと説明したオプションは一般的な指示ではなく、古いフォーラムのスレッドからコピーすることが、一時的な例外を恒久的なアーキテクチャに変える道である。

例外をそこまで狭く限定できないなら、エクスポートはポータルの背後ではなく、別のアクセス方法による内部経路に属する可能性が高い。サイト全体の除外はポータル所有者の決定であり、一つのレポートの回避策ではない。

保存ダイアログではなくエクスポートを受け入れる

最後の確認はファイルそのものであり、開くこと、期待される列を持つこと、その合計がユーザーが承認したレポートと一致することである。

保存ダイアログが表示されることは成功ではなく、修復の警告とともに開くファイルも成功ではない。画面上のレポートと行数および一つの既知の値を比較すること、切り詰められたエクスポートはファイルサイズだけを見るあらゆるテストに合格するからだ。その後にもう一度エクスポートすること、誤った本文を一度配信したキャッシュ層が、次の試行では正しい本文を配信するかもしれない。

ユーザーが必要としたワークフローを受け入れること、それ以上は求めない。間違ったアプリケーションで開くダウンロードも、依然として失敗したエクスポートである。