ブロックされたポート

どのポートがブロックされるのか

ネットワークポートは、同じネットワークアドレス上のサービスを区別する番号です。同じサーバーが、あるポートでウェブ接続を、別のポートで別のアプリケーションへの接続を受け付けられます。アプリケーションには、サーバーのアドレス、適切なポート、使用するトランスポートであるTCPまたはUDPの情報が必要です。

プロキシ接続には、別々の接続先が2つあります。最初にアプリケーションが事業者の指定したアドレスとポートでプロキシへ接続し、次に、対象サーバーのアドレスとポートへ接続するようプロキシに要求します。設定に入力するプロキシのポートは前者で、接続先ポートの制限は後者に適用されます。

たとえば、プログラムがproxy.example:1080に接続し、portal.example:443を要求します。同じプロキシ入口に、mail.example:587への要求も送れます。事業者が前者の接続先ポートを許可し、後者をブロックすれば、ウェブ接続は成功しても、メール接続は拒否されます。

これらは、プロキシから外部サービスへの発信接続に関する制限です。許可されても、コンピューター上のアプリケーションに、ほかのインターネット利用者が到達できる着信ポートが与えられるわけではありません。着信ポート転送は別の機能です。

事業者がポートを制限する理由

最も分かりやすい理由は、特定サービスの不正利用を防ぐことです。メールサーバーへの直接アクセスは、迷惑メールの大量送信に使われる場合があります。苦情や送信元ブロックリストは、通信を運ぶIPアドレスに影響するため、送信した利用者以外にも影響が及びます。事業者は、メッセージ送信前にメール送信用ポートへの接続を拒否し、そのリスクを減らせます。

遠隔管理、ファイル共有、データベースサービスにも同様の事情があります。事業者は、無許可のログイン試行などの攻撃を減らすため、関連するポートを制限する場合があります。制限は接続自体に適用されるため、正当な管理者も、その製品経由では自分のサーバーにアクセスできないことがあります。

規則を決めるのは、必ずしもプロキシの販売者ではありません。ホスティング会社やネットワーク運営者が、プロキシのインフラから出る接続をフィルタリングする場合があります。プロキシソフトウェア側で許可しても、経路の先で課された制限を上書きすることはできません。

ポートフィルターは広範囲に作用します。各メッセージを検査したり、個別の操作の正当性を判断したりせずに望ましくない通信を止められますが、同じポートを必要とする有用なアプリケーションも制限します。この兼ね合いがあるため、妥当な作業を行う有料利用者に対しても、事業者がポートを閉じたままにする場合があります。

ポートのアクセス規則の仕組み

基本的な方法は2つです。ブロックリストは使えないポートを列挙し、それ以外の接続はサービスの残りの規則に従って判断します。許可リストは逆に、指定ポートだけを許可し、それ以外を拒否します。後者では、非標準ポート上の通常のウェブアプリケーションも、ポートが許可範囲外というだけで利用できなくなる場合があります。

規則は、すべての外部アドレスの特定ポートを対象にすることも、ポートと特定の接続先を組み合わせることもできます。製品や承認済みの用途によって規則を変えることもできます。そのため、あるネットワークからのアクセス成功だけでは、同じ会社の別製品の権限は分かりません。

接続先ポートの規則を適用するために、プロキシがアプリケーションの通信を復号する必要はありません。HTTP CONNECTでは、クライアントが対象ホストとポートを渡します。SOCKS5の接続要求にも接続先が含まれます。対象サーバーとの保護されたセッションが始まる前に、プロキシは要求を拒否できます。

同じポート番号のTCPとUDPを、別々に許可またはブロックできます。TCPポート443に接続できても、UDPポート443が使えるとは限りません。また、選んだ製品がUDP自体を運ばない場合もあります。その場合、制限は個々のUDPポートではなく、トランスポート全体に関するものです。

ポート番号だけで、アプリケーションの動作が分かるわけでもありません。サービスは非標準ポートでも動かせますし、許可された番号だからといって、すべての用途が認められるわけではありません。事業者は、ポートフィルター、接続先制限、活動自体の規則を組み合わせられます。

アプリケーションへの影響

アプリケーションは、特定の機能のために接続を使います。ブラウザーのテストで確認できるのは、そのウェブ接続であり、別のプログラムが必要とする接続すべてではありません。以下は、ほかの部分は動いているサービスが、ポート制限でどう影響を受けるかの例です。

メールではこの違いが特に明確です。メールアプリは、通常ポート587または465で送信メールをメールサーバーに渡します。465は最初からTLSで暗号化し、587は通常STARTTLSで暗号化を確立します。ポート制限は、送信前にどちらの接続も止められます。暗号化は通信を保護しますが、事業者のアクセス規則をなくすものではありません。

ウェブメールでは、ブラウザーがHTTPSでサイトと通信し、メールサービスが配送を扱います。ブラウザーは、同じSMTP接続を確立するようプロキシへ要求していません。そのため、SMTPがブロックされてもウェブメールは使えることがあります。別のアプリでの受信はさらに別の接続であり、IMAPやPOPは送信とは分けて検討する必要があります。

FTPは、ログインだけのテストでは問題を見落とす理由を示します。パッシブモードでは、最初の接続でコマンドを送り、その後、データ転送のためサーバー指定のポートに接続します。後者が制限されれば、認証は動いてもファイル一覧やダウンロードが失敗します。ログイン、音声、ファイル交換で別々の接続を使うアプリケーションにも、似た部分的な失敗が起こります。

プロキシ設定の変更では直らない場合

設定内の入口ポートを変えても、アプリケーションがプロキシに接続する場所が変わるだけで、外部サービスに要求する接続先ポートは変わりません。事業者がポート443の入口を用意していても、メールサーバーの587への要求には、引き続きメールポート制限が適用されます。

HTTPプロキシからSOCKS5への変更は、新しい接続方式が持つ機能をアプリケーションが必要とする場合、互換性の問題を解決できます。ただし、それだけで事業者の規則が取り消されるわけではありません。SOCKS5はTCP接続やUDP転送の要求方法を定め、サービスはそのうちどの要求を受け入れるか決めます。

出口IPを交換しても、製品全体の制限は残ります。特定の外部ネットワークが原因なら経路変更で挙動が変わる場合はありますが、製品全体に適用される規則をIPローテーションで消すことはできません。IP数や通信量の枠を増やしても、その権限は変わりません。

ポート制限を特定する方法

最も有用な証拠は、要求した接続先ポートが許可されないという事業者の明確な応答です。一般的なアクセス拒否メッセージは、それより曖昧です。たとえばSOCKS5の規則による拒否の応答は、ポリシーによる拒否を示しますが、原因となる規則までは示しません。タイムアウトやリセットだけなら、証拠としてはさらに弱くなります。

対象サーバーがそのポートで待ち受けていない、特定の送信元だけを許可している、一時的に利用できない、といった可能性もあります。アプリケーションが誤ったプロトコルを使ったり、一部の通信を設定済みプロキシの外へ送ったりする場合もあります。1回のウェブ要求が成功しても、別の接続の制限とこれらの原因は区別できません。

サポートには、製品、対象ホスト名またはIP、ポート、TCPかUDPか、アプリケーション名、正確なエラー、試行時刻を伝えてください。これらがあれば、単にプロキシがオンラインか確認するのではなく、該当する接続を調べられます。購入予定の場合も、同じ情報で作業への対応可否を確認できます。

例外を認める事業者では、必要な接続先と用途を明示して承認を受ける必要があります。恒久的な制限や、事業者が管理できないインフラ由来の制限もあります。確認すべきなのは、具体的な接続をサービス規則の範囲で提供できるかです。「全ポートを開いてほしい」だけでは、要件も限界も曖昧なままです。