ポートと NAT 穴あけ

A は同じ UDP ソケットから STUN サーバーへリクエストを送信し、外部アドレス 203.0.113.10:62000 を取得して B に伝えます。しかし、B から送られてきたパケットは A に到達しませんでした。これは、A が B と通信する際に別のマッピングを使用したか、またはマッピングは同じだが着信フィルタが B を許可していない可能性があります。NAT 穴あけでは、これら2つの問題の両方を同時に処理し、実際の接続性チェックを通じて候補パスを確認する必要があります。

ポート容量：まず固定されているフィールドを明確にする

TCP 接続は通常、ソース/宛先アドレスとポートによって、対応するネットワークコンテキスト内で区別されます。同じローカルポートが異なるリモートピアへの接続に使用される可能性があるため、「一時ポートが 28232 個しかない場合、合計で 28232 本の TCP 接続しか確立できない」という主張は成立しません。明示的な bind、異なるソケットの使用方法、ターゲットの集中度、および NAT 割り当てポリシーは、再利用条件を変更します。Cloudflare：一時ポートと接続の4元組に関する実験

一時ポートの範囲が 32768～60999 の場合、両端を含めて 28232 個の番号があります。⁠固定されたソース IP、固定された宛先 IP:port に対して、保留ポート、並行存続、および安全な再利用を考慮せず、短い接続ごとに4 タプルが約 60 秒占有すると仮定すると、規模の推定は 28232/60≈470 回の新しい接続/秒となります。これは制限条件下での容量予算であり、マシン全体の性能上限ではありません。

ソースアドレスの拡張、接続の再利用、無効な短い接続の削減は予算を変更する可能性があります。ポート範囲を拡大しても、ファイルディスクリプタ、メモリ、conntrack、またはアップストリーム NAT のポート割当制限は解消されません。失敗点を特定し、EADDRNOTAVAIL などのエラーを説明してから、エラーが発生したからといって無条件に TIME_WAIT パラメータを変更してはいけません。

# ローカル設定と接続状態を参照のみで照合；本稿ではこれらのパラメータを変更しません。
cat /proc/sys/net/ipv4/ip_local_port_range
cat /proc/sys/net/ipv4/ip_local_reserved_ports
ss -s
ss -tan state time-wait

UDP には TCP の TIME_WAIT 状態はありませんが、NAT/conntrack が UDP 用に保持するマッピングおよびフィルタリング状態は、リソースを占有したり、タイムアウトしたり、回収されたりする可能性があります。これらを1つのタイマーで混同して扱うことはできません。

マッピングとフィルタリング：2つの独立した分類軸

内部エンドポイントを I=192.168.1.10:50000 として固定し、S1=198.51.100.1:3478、S2=198.51.100.2:3478、S3=198.51.100.2:9999 に順にアクセスします。

分類はマッピングの依存関係を記述するものであり、毎回必ず未使用の外部ポートを割り当てることを要求するものではなく、APDM のポートが必ずランダムで予測不可能であることを示すものでもありません。ポートの予約、競合処理、およびマッピング分類は異なる次元です。RFC 4787：UDP NAT マッピング

EIM は厳格なフィルタリングと共存できます。旧式の Cone/Symmetric ラベルは複数の動作を1つの名前に圧縮しており、正確な診断には適していません。「家庭用」や「モバイルネットワーク」というラベルだけで、動作と成功率を断定することもできません。RFC 4787：フィルタリング

同じパブリックポートなのに、なぜ返信パケットがブロックされるのか？

まず A:3478 への連絡のみを行い、フィルタリング軸を切り替えて他の2つの発信元の許可状況を観察します。次に B:3478 への連絡を行い、マッピング軸を切り替えて新しい外部エンドポイントが作成されるかどうかを観察します。各行の許可リストは、その行のマッピングのみに対応します。別のマッピング上の通信履歴を使って、それを通すことはできません。

STUN：サーバーが観察した発信元を教える

Binding Request は NAT を通過した後、STUN サーバーは変換されたソースエンドポイントを観察し、レスポンスの XOR-MAPPED-ADDRESS フィールドに返します。STUN の固定ヘッダーは 20 バイトで、メッセージタイプ、属性領域の長さ、マジッククッキー、およびトランザクション ID を含みます。続く属性にはタイプ、長さ、およびアライメントルールがあります。XOR はエンコーディング方式であり、アドレスを秘匿するための暗号化ではありません。RFC 8489：STUN

IPv4 の XOR-MAPPED-ADDRESS については、ポートとクッキーの上位 16 ビットが XOR され、アドレスは完全な 32 ビットクッキーと XOR されます。IPv6 のマスクにはトランザクション ID も組み合わされます。末尾のコードは、本例の 203.0.113.10:62000 の往復エンコード/デコードを検証します。

得られるのはサーバーがこのトランザクションで観察したアドレスです。マッピングが宛先に依存する場合、B 宛ての外部エンドポイントは異なる可能性があります。状態がタイムアウトした場合、古いアドレスも無効になる可能性があります。テストには、実際の通信に必要なソケットとコンテキストを使用する必要があり、他のポートを適当に開いて結果を取得し、元のソケットの結果と置き換えてはいけません。

UDP 穴あけでなぜ双方の協調が必要なのか

A と B は、アプリケーション独自のシグナリングチャネルを介して候補エンドポイントを交換し、それぞれ相手の候補に対してチェックパケットを送信します。送信パケットは対応するマッピングおよびフィルタ許可を確立する可能性があり、その後で相手のパケットが通過する機会を得ます。最初のチェックで破棄されたからといって、必ずしも失敗するわけではありません。リトライ、タイミング、および状態の寿命が関係しています。

STUN は、アプリケーションがこのシグナリングチャネルを実装することを担当していません。穴あけは「STUN サーバーが後続の全データを転送する」ものではありません。ピアツーピア接続が確立されると、アプリケーションデータは両端の間で直接フローします。多重 NAT、異なるマッピング動作、ヘアピンサポート、および送信 UDP の制限は結果に影響を与えます。

TURN：リレー両側のプロトコルを明確に区別する

クライアントはまず Allocate を通じてリレーアドレスを取得し、割り当てを維持してから、相手側に適切なパーミッションを確立します。送信には Send Indication を使用でき、Channel Binding が確立された後は、よりコンパクトな ChannelData も使用できます。これらは、サーバーが通常のピアに対してアプリケーションペイロードをそのまま転送するものではありません。RFC 8656：TURN

B はリレーアドレスに対して通常の UDP を送信し、サーバーはパーミッションなどの条件に基づいて受信し、Data Indication または ChannelData を通じて A に転送します。Data Indication は TURN サーバーからクライアントへの片方向のものであり、通常の UDP ピア側に配置することはできません。クライアントから TURN への接続には、UDP、TCP、TLS など、サポートされている伝送路を選択できますが、通常のリレーピアが自動的に同じプロトコルに切り替わることを意味するものではありません。

割り当て、パーミッション、Channel Binding には、それぞれ寿命と更新ルールがあります。資格情報、クォータ、サーバーリソース、およびネットワークポリシーにより、リレーが失敗する可能性があります。そのため、TURN は「常に接続可能」なものではなく、代替伝送路を提供するものです。リレーへの TLS は対応するリンクのみを保護します。エンドツーエンドの機密性が必要な業務では、依然として対応するエンドツーエンド暗号化に依存します。

レイテンシと帯域幅の予算はどのように計算するか

片方向 A→R=15 ms、R→B=20 ms と仮定し、キューイングと処理を無視すると、その方向のリレーパスは約 35 ms になります。逆方向がちょうど対称である場合、RTT は約 70 ms になります。2つの RTT を足して不明な N を掛けることを一般的な公式として使用することはできず、リレーがすべてのピアツーピア接続よりも必ずしも遅くなるとは限りません。

A→B のアプリケーションペイロードが 2 Mbit/s、B→A が 1 Mbit/s の場合、リレーは 3 Mbit/s を受信し、3 Mbit/s を送信する必要があり、RX+TX の合計は 6 Mbit/s になります。さらに、エンコーディングとプロトコルのオーバーヘッドがかかります。ネットワークカード、プロバイダーの課金、および容量制限の口径は異なるため、測定対象が入口、出口、またはその合計のどちらであるかを明確にする必要があります。

ICE：候補ペアはチェックされ、ノミネートされる必要がある

候補には、host（ローカルエンドポイント）、server-reflexive（STUN で観察されたもの）、relayed（TURN で割り当てられたもの）が含まれ、チェック時には peer-reflexive 候補が発見されることもあります。双方はシグナリングを介して候補と ICE 資格情報を交換し、比較可能な候補ペアを形成し、STUN 接続性チェックを手配します。RFC 8445：ICE

候補の優先度は、通常 2²⁴×type_pref + 2⁸×local_pref + (256−component_id) によって構築されます。type preference はポリシーに基づく優先度であり、実測された RTT ではありません。チェックが成功すると、使用可能な候補ペアが生成されます。controlling 役割はノミネーションを通じて使用するペアを決定し、controlled 役割はこれに協力します。役割の衝突にも処理ルールがあります。

候補ペアは、host↔host、srflx↔srflx、relay↔relay の3つの整然とした組み合わせだけではありません。ソート、チェックスケジューリング、トリガーチェック、およびノミネーションが一連のフローを構成しており、「すべてのピアツーピア接続が完全に失敗してから、リレーを考慮し始める」という固定された直列階段として描くことはできません。アプリケーションは、プライバシーやネットワークポリシーの理由で、候補タイプを制限することもできます。

Trickle ICE は、候補を増分的に伝送することを許可し、収集とチェックを重複して行います。認証、チェック、またはノミネーションを免除するものではありません。ネットワークが変更された後には、対応する再起動または永続化メカニズムが必要であり、最初の成功が候補の永久利用可能性を保証するものではありません。RFC 8838：Trickle ICE

Tailscale を実装例として

Tailscale にはピアツーピア接続とリレーパスがあり、公式ドキュメントでは DERP と peer relay を区別しています。システムは、利用可能なリレーを使用して接続を維持しながら、より適切なピアツーピア接続を試すことができます。リレー通信とピアツーピア接続の発見は重複して行うことができます。

DERP は TURN の別名ではありません。具体的なパスの確立、WireGuard 暗号化伝送、およびリレーサービスは、製品ドキュメントに基づいて理解する必要があります。ランダムなポート割り当ては探難を困難にしますが、「ランダムであれば数学的に絶対にヒットしない」という主張も成立しません。無限のポートを試すことで、信頼性の高いリレー設計を代替してはいけません。Tailscale 接続タイプ

診断順序：どのレイヤーで状態が失われたかを特定する

IPv6 は IPv4 のアドレス変換ニーズを減らしますが、グローバルアドレスがあってもファイアウォールが入信を許可するとは限りません。ICE は依然としてパスの選択と検証に使用できます。ポートマッピングツールは、管理可能なゲートウェイ上で明示的にマッピングを要求するものであり、NAT の動作を観察する STUN とは異なるアプローチです。

ローカル計算例：XOR アドレスと容量

from ipaddress import IPv4Address
import struct

cookie = 0x2112A442
port = 62000
address = int(IPv4Address('203.0.113.10'))
value = struct.pack('!BBHI',0,1,port^(cookie>>16),address^cookie)
reserved,family,xport,xaddress = struct.unpack('!BBHI',value)
assert reserved == 0 and family == 1
assert xport^(cookie>>16) == port
assert str(IPv4Address(xaddress^cookie)) == '203.0.113.10'
assert value.hex() == '0001d322ea12d548'
assert 60999-32768+1 == 28232
assert 470 < 28232/60 < 471

def priority(type_pref,local_pref,component):
    return (1<<24)*type_pref+(1<<8)*local_pref+256-component
assert priority(126,65535,1) == 2130706431
assert priority(126,65535,1)>priority(100,65535,1)>priority(0,65535,1)
assert 2*(2+1) == 6
print('STUN IPv4 XOR 属性、ポート予算、ICE 優先度、およびリレートラフィックチェックが通過しました')

この例には、完全な STUN トランザクション、認証、または ICE 状態マシンは含まれていません。穴あけ、ポートスキャン、リレー割り当て、またはゲートウェイ設定の試行は行っていません。

継続的な参照

• TCP：4元組、TIME_WAIT、および接続ライフサイクル。
• UDP と QUIC：データグラム、移行、およびパス検証。
• WebRTC：ICE とメディアネゴシエーションの組み合わせ。
• Tailscale アーキテクチャ：コントロール、ピアツーピア接続、およびリレーの役割分担。