Nebula の punchy 設定：NAT を直すのはどれか

二つのピアが灯台を介して互いを見つけても直接経路を築けず、そのとき最初の衝動は punchy のオプションを全部有効にすることです。その衝動が生むのは三つの変更を抱えた設定で、どれが効いたのかは分かりません。設定はそれぞれ別の問いに答えます：一方は既にあるマッピングを維持し、もう一方は逆向きのハンドシェイクを試みます。どちらに触れる前に、自分がどちらの問いを持っているかを決めてください。

タイミングより先に端点を確認する

期待したアドレスに決して現れないピアは、punch の調整では救えません。古い bootstrap アドレスや誤って公開されたプライベートアドレスはあらゆる越え方の仕掛けを無効にするため、灯台がそのピアについて何を知っているか、ピア自身の設定が何を広告しているかを確認してください。信頼されていない識別子は NAT が問題になるよりずっと前に会話を止めるため、証明書が信頼されていることも確認してください。そのうえで、UDP が灯台にそもそも届くかを確かめます。タイミングの値は最初に見るものではなく、最後に見るものです。

後で比較するときに別の二台ではなく同じピアを使うため、試している端点のペアを記録してください。

punch はマッピングを保ち、respond は方向を開く

punch オプションは、すでにトンネルを持つピアのアンダーレイアドレスへ定期的に空のパケットを送ります。その目的は地味です：直接経路が依存するマッピングを、ステートフルな NAT やファイアウォールに失効させないようにします。respond オプションは、灯台からの通知で起きることを変え、ホストに自分へ到達しようとするピアへ向けた逆方向のハンドシェイクを試みさせます。これらは失敗の仕方が異なる別々の仕組みです。

直接経路が機能してから後で衰えるなら punch を選びます。経路が一方向にしかできないなら respond を選びます。両方を有効にして願うのは、五分で終わる修正を一週間の調整に変える方法です。

遅延が決めるのはいつで、できるかどうかではない

遅延の値はタイミングをずらします：一方は通知後に送るパケットに、もう一方は逆向きのハンドシェイクの試行に適用されます。どちらも塞がれた方向を機能させはしません。両方を同時に変えると、これから行う比較が台無しになります。

仕組みが正しくなるまで、その二つは放っておいてください。それから片方だけ調整し、古い値を書き留めておきます。

リレーが正直な答えになるとき

NAT の組み合わせによっては、タイミングをどう整えても直接経路を支えられません。両側が対称型 NAT の場合や、求められていない受信トラフィックを完全に捨てるファイアウォールでは、貫く先が残りません。

到達可能なアドレスを持つリレーノードは、それらのピアに、越え方の成否に依存しない経路を与えます。そのノードを経由する帯域を消費するので、これは回避策ではなく容量についての判断です。リレー自体が難しい NAT の背後にあるなら何も変わらないため、リレーを意図して設定し、ピアがそこへ到達できることを確認してください。直接経路は現れるはずがなかったのだから、その後、そのペアの punch 設定を調整するのはやめてください。

失敗したペアを、待機させたうえで試す

壊れた条件を再現します：同じ間隔だけペアを待機させるか、以前失敗したハンドシェイクの手順を繰り返します。そのうえで、灯台への要求ではなく、その二つのピアの間でアプリケーションを動かします。灯台の応答は制御経路を証明するだけで、データ経路については何も示しません。

どの設定を変えたか、時刻、そして直接経路が現れたのか通信がリレーに残ったのかを記録します。残ったなら、答えはリレーと容量のメモであり、それはまったく良い結果です。現れたなら、マッピングが衰えることがまさに punch が存在する理由だから、次の問いはそれが一時間の待機に耐えるかどうかです。