【実務・中級編】 OpenVPNで利用されるポート番号（UDP 1194とTCP 443）の役割と使い分け – サイバーセキュリティとプライバシー保護実践ガイド

コーヒーを片手に、深夜のトラブルシューティングで冷や汗をかいた経験は誰しもあるだろう。ある日突然、海外拠点から「社内リソースにアクセスできない！」と悲鳴が上がり、調査を進めると、現地の宿泊先の極めて厳格なファイアウォールがすべての非標準ポートを塞いでいた……なんていう現場の修羅場だ。

インフラエンジニアやWeb APIの設計に携わる者にとって、プロトコルの挙動とポートフォワーディングの裏側を理解することは、単なる教養ではなく、ビジネスを死守するための必須スキルである。

今日は、個人向けVPNからエンタープライズのセキュアアクセスまで幅広く使われている「OpenVPN」を取り上げ、その生命線とも言える2つのポート――王道の UDP 1194 と、ファイアウォールを鮮やかにすり抜ける TCP 443 の実務的な使い分けと、パケットの裏側の挙動について、現場の知見を交えて徹底的に解説しよう。

—

1. なぜOpenVPNなのか？プロトコルの基本と「UDP 1194」の独壇場

OpenVPNが長年エンジニアから厚い信頼を得ている理由は、その圧倒的な柔軟性と堅牢性にある。SSL/TLSプロトコルをベースにしつつ、独自のトンネリング機構を持つこのオープンソースVPNは、設定次第でレイヤー2（TAP）としてもレイヤー3（TUN）としても動作する。

そして、その標準ポートとしてIANA（Internet Assigned Numbers Authority）に登録されているのが UDP 1194 だ。

パケットの挙動とUDPを選ぶべき理由

ネットワークの現場で「VPNを張るなら基本はUDP」と叩き込まれるのには、明確な物理的・論理的理由がある。

[クライアント (TUN/TAP)] ──(UDPパケット)──> [Internet] ──> [OpenVPNサーバー (1194)]

UDP（User Datagram Protocol）は、TCPのようなコネクション確立のための3ウェイハンドシェイク（SYN, SYN-ACK, ACK）を行わない。パケットを投げたら投げっぱなしの「非接続型」だ。これがVPNにおいてどう作用するか。

1. オーバーヘッドの最小化: ヘッダーサイズがTCPの20バイトに対し、UDPはわずか8バイト。ミリ秒単位の遅延が命取りになるリアルタイム通信や、トータルのスループットを最大化したい場合に圧倒的に有利。
2. 「TCP meltdown（TCPのメルトダウン現象）」の回避: ここが最大のポイントだ。もしTCP上のトンネルの中にさらにTCPのパケットを通した場合（TCP over TCP）、内側のTCPがパケットロスを検知して再送制御を始めたとき、外側のTCPもそれに追随して再送を試みる。結果として帯域が圧迫され、パケットロス率が雪だるま式に悪化する現象が起きる。UDPはその構造上、この「二重の再送地獄」を完全に回避できる。

client.ovpn 設定ファイルの実例（UDP 1194）

実際のインフラ構築や、開発環境での検証で使われる標準的なOpenVPNクライアント設定（.ovpn）を見てみよう。

# クライアント設定ファイル (client-udp.ovpn)
client
dev tun                # レイヤー3（IP層）の仮想ネットワークデバイスを使用
proto udp              # 王道のUDPプロトコルを指定
remote vpn.example.com 1194 # 接続先のエンドポイントと標準ポート
resolv-retry infinite  # DNSの解決を無限にリトライ（ネットワーク一時断対策）
nobind                 # ローカルのランダムなポートをクライアント側に割り当て
persist-key
persist-tun            # 再接続時にキーやデバイスの再初期化を行わずリソースを節約

ca ca.crt
cert client.crt
key client.key

remote-cert-tls server
cipher AES-256-GCM     # 暗号化アルゴリズム（モダンなGCMモードで効率化）
auth SHA256
verb 3                 # ログの冗長度（トラブルシューティング時は4〜5に上げる）

—

2. 厳格な要塞を突破せよ：「TCP 443」とHTTPS偽装のメカニズム

しかし、世の中のすべてのネットワークがエンジニアに優しいわけではない。公共Wi-Fi、厳格な企業ネットワーク、あるいは国家レベルのファイアウォール（GFWなど）は、UDP 1194 のような非標準ポートを容赦なくブロックする。「安全な通信以外は通さない」というポリシーのもと、通常許可されているのはウェブ閲覧に必要な TCP 80 (HTTP) と TCP 443 (HTTPS) だけ、という環境はザラにある。

ここで登場するのが、TCP 443 を用いたOpenVPNの運用、いわゆる「HTTPS偽装（Port 443 tunneling）」だ。

パケットの挙動と「なぜTCPなのか」

[クライアント] ──(TLS Handshake / TCP 443)──> [ファイアウォール (中身はHTTPSに見える)] ──> [OpenVPNサーバー (443)]

ファイアウォールは、パケットの宛先ポートが 443 であれば、「これは安全な暗号化されたWeb通信（TLS/SSL）に違いない」と判断してパケットを通す。OpenVPNはこの仕組みを逆手にとり、サーバー側のリスニングポートを 443 に設定することで、検閲システムを欺くのだ。

ただし、先ほど解説した「TCP meltdown」の懸念が頭をもたげるはずだ。現場では、このトレードオフをどう捉えればいいのだろうか？

• スループットの低下: パケットロスが発生した際、TCPの輻輳制御によって一時的に速度がガタ落ちするリスクを受け入れる。
• 接続性の優先: 「速度が出ないこと」よりも「そもそも接続できないこと」の方がビジネス上の致命傷になるため、つながりやすさを優先する。

client.ovpn 設定ファイルの実例（TCP 443）

# クライアント設定ファイル (client-tcp.ovpn)
client
dev tun
proto tcp              # 信頼性の高いTCPプロトコルを指定
remote vpn.example.com 443 # HTTPSと誤認させるため、宛先を443ポートに設定
resolv-retry infinite
nobind
persist-key
persist-tun

ca ca.crt
cert client.crt
key client.key

remote-cert-tls server
cipher AES-256-GCM
auth SHA256

# プロキシ環境下やディープパケットインスペクション（DPI）対策のオプション
# HTTPプロキシ経由で接続する場合の記述例
# http-proxy proxy.example.com 8080

verb 3

サーバー側の server.conf では、もちろん以下のように待ち受けを設定する。

port 443
proto tcp
dev tun
...

—

3. Web API開発者・インフラ運用者のための実践的使い分けとトラブルシューティング

ここまで読んで、「じゃあ、すべて TCP 443 にしておけばファイアウォールに悩まされなくて最強なのでは？」と思った読者、ちょっと待ってほしい。そこがプロのエンジニアの腕の見せ所だ。

実務におけるポート選択の判断基準を整理しておこう。

状況に応じたマトリクス

| 評価項目 | UDP 1194 (標準) | TCP 443 (偽装) |
| :— | :— | :— |
| 接続の確実性 | 低（厳格なFWではブロックされる） | 高（大半のネットワークで通過可能） |
| スループット | 高（オーバーヘッド小） | 中〜低（TCP meltdownの影響あり） |
| レイテンシ | 低（リアルタイム性高） | 高（再送制御によるバッファリング発生） |
| ユースケース | 自宅からの社内アクセス、通常のVPN利用 | ホテル、空港、制限の厳しい海外出張先 |

現場で役立つデバッグTips：ポート疎通とパケットキャプチャ

もし「TCP 443には繋がるのに、UDP 1194だとタイムアウトする」という現場に遭遇したら、まずはハンドシェイクの成否を切り分ける必要がある。Pythonやcurlを使った簡易的なテストではなく、低レイヤーのツールを駆使しよう。

1. nc (Netcat) または ncat によるUDP/TCPポートの死活監視

# UDPポートが空いているか確認（UDPはステレスなので返答がないことも多いが送信テストになる）
nc -vzu vpn.example.com 1194

# TCP 443のTLSハンドシェイクが返ってくるか確認
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

2. tcpdump によるパケットキャプチャの現場流アプローチ

サーバー側で、実際にクライアントからのパケットが到達しているかをカーネルレベルで確認する。

# インターフェース eth0 に届くポート1194のUDPパケットをキャプチャして覗き見する
sudo tcpdump -i eth0 -nnvvS udp port 1194

ここでパケットが来てすらいない場合は、その手前のルーターやクラウドのセキュリティグループ（AWSのSGやGCPのファイアウォールルール）で UDP 1194 が弾かれている。アプリ層の設定をいくらいじっても無駄だということに、一瞬で気づけるはずだ。

—

まとめ：ネットワークの「文脈」をハックする

VPNのポート選択は、単なる「数字合わせ」ではない。そこには、パケットが通過する物理的・論理的な経路、ファイアウォールのポリシー、そしてTCP/UDPというプロトコルの宿命が絡み合っている。

• 通常時は、低遅延で高スループットな UDP 1194 をデフォルトとする。
• 要塞のような厳格なネットワーク環境が予想される場合は、TCP 443 へのフォールバック（あるいは常時TCP接続）を設計に組み込む。

この使い分けを的確に行えるかどうかが、インフラの信頼性を左右する。さあ、次のデプロイやネットワーク設計では、この選択に自信を持って挑んでほしい。