Posted inネットワーキング

Linux上でTailscaleのカスタムDERPリレーサーバーを構築する：Symmetric NATを回避してレイテンシを削減

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

メッシュVPNにおけるリレー方式の比較

Tailscaleは、異なるネットワーク間に点在するマシン同士をWireGuardによって相互接続します。理想的な通信環境であれば、UDPホールパンチングによって2つのエンドポイント間で直接ピアツーピア（P2P）接続が確立されます。しかし、厳しいモバイルキャリア回線（CGNAT）、企業ファイアウォール、ホテルのWi-Fiなどでは、Symmetric NAT（対称NAT）が適用されているケースが多々あります。このような環境では、宛先ごとにマッピングされるパブリックポートが無作為に変化してしまいます。直接のP2Pハンドシェイクが失敗した場合、トラフィックは中間リレーサーバーであるTailscaleの「DERP（Designated Encrypted Relay for Packets）」へとフォールバックせざるを得ません。

NAT越え（NAT Traversal）のボトルネックに直面したチームには、通常3つの選択肢が考えられます。

  • デフォルトのパブリックDERPノード： Tailscaleは世界各地で多数の共有リレーを運用しており、設定不要ですぐに利用できます。ただし、地理的に離れたリージョンを経由することで往復遅延（ping）が150ms〜250msほど増加することが日常的であり、混雑時のスループットも15〜20Mbps未満に制限されることが少なくありません。
  • 静的ポートフォワーディングとUPnP： エッジルーターで固定のUDPポート範囲（41641/udpなど）を開放すれば、直接のハンドシェイクを確実に維持できます。しかし、アップストリームのルーターが厳格に管理されているモバイル回線、クラウドVPC、企業のゲストネットワークではこの回避策は利用できません。
  • 専用のカスタムDERPノード： ユーザーの物理的拠点に近い安価なクラウドVMを用意し、Tailscale公式のオープンソースデーモンderperを稼働させるアプローチです。ペイロードデータはWireGuardの暗号化キーによってエンドツーエンドで完全に保護されたまま維持されます。帯域を専有でき、予測可能なスループットと1桁ミリ秒台のローカルレイテンシが得られます。

トレードオフ：セルフホスト型リレーの導入判断基準

プライベートリレーを導入すれば、接続の安定性は即座に改善されます。一方で、独自のノードを運用することは、インフラ管理の責務をチーム自身が負うことを意味します。

主なメリット

  • 圧倒的な低レイテンシ： たとえばオフィスがシンガポールにあり、トラフィックが東京のパブリックリレーを経由している場合、レイテンシは80〜120ms前後になります。シンガポールのデータセンターにローカルDERPノードを配置すれば、往復pingを4〜12msまで劇的に短縮できます。
  • スループット制限の排除： 共有インフラにおけるノイジーネイバー（他ユーザーの負荷影響）による帯域制限を回避できます。大容量のrsyncジョブ、データベースレプリケーション、大量のデータ転送でも、サーバーの1Gbpsアップリンク性能をフルに発揮できます。
  • 明確な診断と可視性： ホストのログを自社で完全に管理できます。接続が切断された場合でも、サードパーティ製リレー内部の挙動を推測することなく、インターフェース上でtcpdumpを実行して直接トラブルシューティングが可能です。
  • 設計段階からのゼロトラストセキュリティ： DERPインスタンスは、HTTPSでカプセル化されたWireGuardフレームを中継します。リレー自体は秘密暗号鍵を一切保持しないため、中継するデータストリームを復号することは構造上不可能です。

運用コストと考慮すべき課題

  • インフラコスト： 固定IPv4アドレスを備えた専用クラウドVMの維持には、通常月額4〜6ドル程度のホスティング費用が発生します。
  • メンテナンスの手間： OSのセキュリティパッチ適用、アップストリームのderperアップデートの追従、TLS証明書の自動更新の監視などを継続的に行う必要があります。
  • オープンリレー化のリスク： クライアントの厳格な認証を行わずにインスタンスを公開すると、悪用の対象となります。認証なしの状態では、443ポートをスキャンされてノードを無料のプロキシとして乗っ取られる危険があります。

ハードウェアおよびネットワーク要件

小規模なインスタンスであっても、本番環境のワークロードを驚くほど軽快に処理できます。ベンチマークテストでは、最小構成の1コアノードでも何十もの同時トンネル接続を問題なく安定して捌くことができました。

OSには最小構成のUbuntu 22.04またはDebian 12仮想マシンを選定し、最低1 vCPU、1GB RAMを確保します。インスタンスには以下の要件が必要です：

  • 静的でパブリックルーティング可能なIPv4アドレス（可能であればネイティブIPv6も）。
  • ホストを指すFQDNのA/AAAAレコード（例：derp.example.com）。
  • Let’s EncryptのHTTP-01チャレンジ用に開放されたポート80/TCP。
  • HTTPS DERPリレートンネル用に開放されたポート443/TCP。
  • STUNアドレス検出用に開放されたポート3478/UDP。
  • derperが--verify-clientsを介してピアの身元を検証できるように、同一ホスト上でTailscaleデーモンが稼働していること。

Linuxへの段階的なデプロイ手順

1. システムの事前準備とDNS設定

DNSレコードを設定してサーバーのIPアドレスを紐付け、dig +short derp.example.comで浸透を確認します。次に、サーバーにログインして基本的なビルドツールをインストールします：

sudo apt update && sudo apt install -y curl git ufw build-essential

2. Goのインストールとリレーデーモンのビルド

Tailscaleは、公式のGoモジュールリポジトリの一部としてderperを提供しています。最新のGoリリースを取得して/usr/localに展開し、バイナリをビルドします：

# Goのダウンロードと展開
wget https://go.dev/dl/go1.22.4.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.22.4.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

# derperバイナリのコンパイル
go install tailscale.com/cmd/derper@latest
sudo cp ~/go/bin/derper /usr/local/bin/derper
sudo chmod +x /usr/local/bin/derper

3. Tailnet上でリレーホストを認証

DERPリレーをオープンプロキシとして運用してはなりません。ローカルのtailscaledプロセスと並行してderperを起動すると、ローカルのTailscaleソケットへ問い合わせが行われます。これにより、Tailnet内の認証済みマシンからではないリレー要求はすべて破棄されます。

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

4. Systemdサービスユニットの作成

Let’s Encrypt証明書用の保存ディレクトリを作成し、derperをバックグラウンドのsystemdサービスとして登録します：

sudo mkdir -p /var/lib/derper

サービス定義を/etc/systemd/system/derper.serviceに記述します。derp.example.comの部分は実際のホスト名に置き換えてください：

sudo tee /etc/systemd/system/derper.service > /dev/null <<EOF
[Unit]
Description=Tailscale カスタムDERPサーバー
After=network.target tailscaled.service
Wants=tailscaled.service

[Service]
Type=simple
User=root
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/derper \
  -hostname derp.example.com \
  -certmode letsencrypt \
  -certdir /var/lib/derper \
  -a :443 \
  -stun-port 3478 \
  -verify-clients

[Install]
WantedBy=multi-user.target
EOF

デーモンを起動し、ログ出力を確認してTLS証明書の発行が正常に完了したことを確認します：

sudo systemctl daemon-reload
sudo systemctl enable --now derper
sudo journalctl -u derper -f

5. UFWファイアウォールルールの設定

ホストのファイアウォールを有効化する前に、必要なHTTP、HTTPS、およびSTUNポートの通信を許可します：

sudo ufw allow 22/tcp comment "SSH管理"
sudo ufw allow 80/tcp comment "Let's Encrypt認証"
sudo ufw allow 443/tcp comment "DERP HTTPSリレートラフィック"
sudo ufw allow 3478/udp comment "Tailscale STUNポート"
sudo ufw enable

6. Tailscale ACLポリシーへのリレー登録

Tailscaleの管理コンソールを開き、Access Controlsを選択します。トップレベルのderpMap属性内に独自のノードを追加します。公式のTailscaleリレー番号との衝突を避けるため、カスタムリージョンのIDには900〜999の範囲を指定してください：

"derpMap": {
  "Regions": {
    "901": {
      "RegionID": 901,
      "RegionCode": "custom-sg",
      "RegionName": "シンガポール プライベートDERP",
      "Nodes": [
        {
          "Name": "901a",
          "RegionID": 901,
          "HostName": "derp.example.com",
          "DERPPort": 443,
          "STUNPort": 3478
        }
      ]
    }
  }
}

7. リレールーティングの検証とレイテンシ測定

Tailnet上の任意のリモートクライアントに切り替え、ネットワーク診断を実行します：

tailscale netcheck

コンソールのレポートに、利用可能なリージョンとそれぞれの往復pingが一覧表示されます。追加したcustom-sgのエントリを確認し、UDP STUNでパケットロスが発生していないことを確かめてください。実際にリレーがパケットを中継している様子を確認するには、Symmetric NATの背後にあるターゲットノードへpingを送信します：

tailscale ping --verbose 100.115.82.44

エッジファイアウォールによって直接のNATホールパンチングが遮断されている場合、pingのトレース結果にderp-901a経由でパケットが転送されていることが明示されます。共有パブリックインフラによる180msもの遅延に悩まされることなく、自前のプライベートインスタンスを経由して8〜12msという極めて快適な応答速度で通信できるようになります。

Share:
Tags: