URLに必要なのはポート80または443の入口で、45000ではない理由

ブラウザにホスト名を入力すると、スキームが行き先のポートを決めます（httpなら80、httpsなら443）。DNSの応答でこれが上書きされることはなく、手元のマシンの転送ルールでプロバイダーの境界にリスナーをでっち上げることもできません。VPNプロバイダーが45000のような高い公開ポートを渡した場合、明示的なURLは動きますが、きれいなURLは動きません。開きは入口にあり、アプリケーションの中にはありません。

ブラウザからプロセスまでの経路を一度たどれば、三つの公開方法は不思議ではなくなります。

リクエストが実際にどこへ行くかを見る

ブラウザは名前をアドレスに解決し、URLが別のポートを指定しない限り、スキームの既定ポートでそのアドレスに接続します。到着した接続をどう扱うかはプロバイダーの境界が決めます。その転送テーブルが45000だけを内部アドレスに対応させているなら、80への接続は行き場がなく、こちらのマシンが関与する前に拒否または破棄されます。

その拒否は境界で起きるので、アプリケーションのログには何も残りません。ログがないことはパケットがどこで止まったかの証拠であり、アプリケーションが壊れている証拠ではありません。

ローカルのルールで境界を直せない理由

アプリケーションホスト上のリダイレクトやDNATルールは、すでに到着したパケットに作用します。プロバイダー側で80に送られたパケットは決して到着しないため、そのルールが評価されることはありません。これがこの問題で最もよく失われる一時間です。

DNSもポートを運べません。HTTP仕様はスキームの既定値を定めており、AまたはAAAAレコードはアドレスを返し、CNAMEは別の名前を返します。ブラウザは依然としてスキームのポートを連結するので、URL内の明示的なポートだけが行き先を変えます。

第一の選択肢：明示的なポートを維持する

多くの場合、正しい答えは地味なものです。ポート付きの完全なURLを公開し、それを支える入口でTLSを終端し、生成されるすべてのリンクが同じオリジンを保つようにします。小さく統制された相手にはこれで十分で、見えるポート番号以外のコストはかかりません。

自分のホスト名をLocationヘッダーに書くバックエンドはこの取り決めを台無しにするため、ついでにリダイレクトとCookieのスコープも確認してください。

第二の選択肢：既定ポートの本当の入口を確保する

プロバイダーやホスティングの構成によっては、共有または専用アドレスで80と443を文書化されたサービスとして転送しています。公開の出口アドレスが任意の受信ポートを意味すると決めつけず、実際に何が含まれるかを尋ねてください。専用の出口アドレスは受信転送について何も語りません。

所有権と可用性を書面で確認し、トンネルが別のアドレスで再接続したときに入口がどうなるかも含めてください。トンネルと一緒に動く入口は、DNS障害のように見える停止を生みます。

第三の選択肢：手前にフロントエンドを置く

到達可能なアドレスのリバースプロキシは、443で待ち受け、TLSを終端するし、VPN経由でバックエンドへの別接続を開けます。訪問者にはフロントエンドの名前と既定ポートが見え、フロントエンドはあなたの代わりにバックエンドの高いポートと話します。これが機能するのは、入口と戦うのではなくアーキテクチャを変えるからです。そうすればバックエンドは公開インターネット上の受信ポートをまったく必要としません。

運用するものも変わります。フロントエンドが公開TLS、アクセス方針、ログ、可用性を持ち、バックエンドの選択を意図したサービスに限定しなければなりません。フロントエンドからバックエンドへのホップがHTTPSを使うなら、そのホップで証明書の検証を保ってください。

単一のオリジンを保つ

フロントエンドの公開ホスト名、スキーム、ポートが訪問者の使うオリジンを形づくるので、アプリケーションの外部URL、リダイレクト、Cookieをそのオリジンに設定します。アプリケーションが絶対リンクを組み立てる場合は、元のホストと転送されたスキームを送ってください。利用者をプライベートな名前や高いポートへ跳ね返す応答は、今作ったきれいな入口を台無しにします。

そのうえで相手を考えて決めます。短いURLは管理されたフロントエンドを正当化できますが、VPN専用の私的なサービスを誤って公開サービスに変える価値はありません。