議論： NAT：アドレス変換の仕組みと着信接続が失敗する理由

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

翻訳がないため、原文を表示しています。 原文

The two RFC minimums quoted are not arbitrary, and the link explains the Linux default in the TCP article: RFC 5382 chose 2 hours 4 minutes so that a TCP keep-alive at the two-hour default from RFC 1122 arrives, with time for a retransmission, before a compliant NAT drops the mapping. The mapping and filtering behaviours the article describes are discoverable from inside: a STUN request (RFC 8489) to a server with two addresses reports the external address and port, and comparing the mappings obtained for two destinations tells the client whether the NAT is endpoint-independent, which is what the hole-punching bullet depends on. That is what WebRTC's ICE does before it falls back to TURN, so the 'measure rather than assume' advice has a standard tool.