WireGuard PersistentKeepalive：NATマッピングを生かし続ける

ピアがトラフィックを送った直後だけ逆方向の接続が機能するなら、マッピングが期限切れです。ルーターの背後でキープアライブを設定し、実際のタイムアウトを読み取ります。

自宅のボックスはトンネルを開き、問題なくクラウドサーバーに到達します。クラウドサーバーは、自宅のボックスが最後に何かを送ってから一、二分間は自宅のアプリケーションに到達できますが、その後は止まります。WireGuardのログには何も現れず、ハンドシェイクエラーも報告されず、トンネルを再起動するとしばらく直ります。このパターンは壊れたトンネルではなく期限切れのマッピングであり、以下の手順書は何かを変える前にそれを確認します。

パターンがアイドルによる期限切れであることを確認する

見分けるポイントはタイミングです。自宅のピアがトラフィックを送った直後に逆方向の接続が機能し、静かな時間の後に失敗するなら、経路は正常で中間の状態が問題です。トラフィックの直後でも一度も動かなかったなら、その診断は間違いです。

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

自宅のピアが何かを送った直後に最初の二つのコマンドを実行し、五分待ってからもう一度実行します。新しいエンドポイントなしで予定どおりに更新されるハンドシェイクのタイムスタンプは、トンネルが生きていることを示します。変わったのは外部から一方的なパケットが届く能力であり、これはトンネルではなく経路の性質です。

次に逆方向の試行を行い、転送カウンターを確認します。クラウド側がバイトを送っているのに自宅側が一バイトも受信しないなら、パケットはクラウドを離れ、途中の状態を保持する機器で消えています。これが探している兆候です。両方のカウンターが動いていれば、トンネルはパケットを届けており、疑わしいのはアプリケーションです。

キープアライブをルーター背後のピアに置く

常時キープアライブは、スケジュールに従って小さな認証済みパケットを送ることで、NATマッピングとファイアウォールの状態を維持します。設定は、送信パケットで状態を作るのがその側だからこそ、ルーター背後のマシンのリモートピアに対するエントリに属します。

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

既存のピアセクションに統合します。同じ公開鍵で二つ目のブロックを追加することは有効なオプション追加の方法ではなく、wg-quick もそれらを統合してくれません。文書化されている25秒は、一般的なUDPタイムアウトを下回るように選ばれた例であり、特別な意味を持つ値ではありません。

同じディレクティブをクラウド側に置いても、この問題には役立ちません。そのピアのパケットはすでに公開アドレスから届いているので、重要な方向に保持すべきマッピングはありません。トラフィックが増えるだけで、何も変わりません。

間隔を推測せずタイマーを読む

キープアライブが機能するのは、状態が期限切れになるよりも頻繁に届くからです。つまり必要な数字はタイムアウトであり、Linuxでは変換を行う機器上で読めます：

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

最初の値は片方向でしか観測されていないUDPフローのタイムアウトで、二つ目は応答が観測された後に適用されます。どちらも通常は短く、静かになったマッピングは自分のフローに当てはまる方に従います。

その数字を自分の間隔と比較してください。25秒のキープアライブは30秒のタイムアウトの下では機能しますが、同じキープアライブは15秒のタイムアウトの下では機能しません。何度再試行してもこの算術は変わりません。一部の家庭用ルーターや携帯事業者はLinuxの既定よりはるかに短い値を使っており、あるネットワークで機能する設定が別のネットワークで失敗するのはそのためです。

ObservationWhat it meansReasonable response
Works after traffic, dies when idleMapping or firewall state expiringLower the keepalive interval
Never works, even immediatelyNo return route, listener or firewallStop tuning keepalive
Works for hours, then dies onceCarrier-side translation or address changeCheck the endpoint and logs together

リスナーとファイアウォールを別々に確認する

生きたマッピングは必要ですが、十分ではありません。自宅のボックスのアプリケーションは正しいアドレスで待ち受けている必要があり、ホストのファイアウォールは復号後にパケットを許可する必要があります。

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

ソケットがトンネルのアドレスではなく物理インターフェースのアドレスだけにバインドされている場合、トンネルに届くパケットはファイアウォールに問い合わせる前に破棄されます。この失敗はクラウド側から見るとマッピングの問題とまったく同じに見え、キープアライブの調整では解決しません。

許可リストの確認も逆方向では同じくらい重要です。クラウドのピアは応答するなら自宅トンネルのアドレスを送信元として許可する必要があり、自宅のピアはクラウドのアドレスを宛先として許可する必要があります。キープアライブのパケットは認証済みのトラフィックであり同じルールを通るため、機能しているように見えるキープアライブが機能しないアプリケーションと共存することがあります。

変更を展開し、限界を知る

設定を適用し、それが更新方法ならインターフェースを再起動し、直後のテストではなくアイドルテストを繰り返します。先に読んだタイムアウトより長く待ち、逆方向の要求を行い、両端でカウンターが動いたことを確認します。

間隔と測定したタイムアウトを並べて記録します。将来のルーターのファームウェア変更やモバイル接続への移行でタイムアウトが変わる可能性があります。メモがあれば、値をコピーするのではなく再び導き出せます。一行に二つの数字があれば、後で調査を丸ごと省けます。

常時キープアライブは状態を保護します。ポートを開くことも、許可リストに項目を追加することも、リスナーを出現させることもありません。逆方向の接続がまったく機能しないとき、原因はこの三つのどれかであり、WireGuardのクイックスタートも同じ狭い表現でキープアライブ設定を説明しています。

関連記事