SDL logoSDL

ドキュメント

Linux、macOS、Windows で SDL をインストールし、デバイスを認証し、接続状態を確認するためのガイドです。

Overview

SDL (Software Defined LAN) は、WAN、インターネット、NAT をまたいだ複数のマシンを、ひとつのオーバーレイ LAN として接続します。中央の コントロールプレーン がデバイス認証と仮想 IP の割り当てを行い、データ通信は独立した ゲートウェイ インスタンスで中継されます。これにより、制御面とデータ面を分離してスケールできます。

リリースパッケージには、各マシンで使う 2 つのバイナリが含まれます。

  • sdl-service は常駐するローカルサービスです。TUN インターフェイス、コントロール接続、P2P とリレー経路、ローカルコマンドソケットを管理します。
  • sdl は CLI フロントエンドです。ローカルソケット経由で sdl-service と通信し、status、auth、gateway 選択、rename、suspend、resume などを実行します。

sdl-service は仮想ネットワークインターフェイスを作成するため、インストールとサービス管理には管理者権限または root 権限が必要です。日常的な CLI 操作、たとえば sdl status や sdl list には通常管理者権限は不要です。

Getting Started

新しいユーザーが SDL ネットワークへ参加する最短手順です。

  1. SDL をダウンロードします。 ダウンロードページ を開き、利用するプラットフォームのリリースアーカイブを選択します。
  2. ローカルサービスをインストールします。 アーカイブを展開し、OS 用のインストーラを実行します。Linux と macOS は sudo ./install.sh、Windows は管理者 PowerShell から .\install.ps1 を実行します。
  3. この Web サイトにサインインします。 Google または Microsoft で登録またはログインし、ダッシュボード を開きます。
  4. 認証チケットを生成します。 Generate auth ticket をクリックします。チケットは短時間で失効するため、デバイスを認証する直前に生成してください。
  5. デバイスを認証します。 ダッシュボードに表示されるコマンドをコピーするか、ローカルで sdl auth --userId <user-id> <ticket> を実行します。
  6. 状態を確認します。 sdl status を実行します。正常なデバイスでは、ローカルサービス、認証状態、仮想 IP、ゲートウェイ状態が表示されます。機械処理しやすい出力が必要な場合は sdl status --json を使います。

sdl status が auth_pending のままの場合は、新しいチケットを発行して sdl auth を再実行してください。サービスが起動していない場合は、利用 OS のサービス管理ツールで sdl-service を再起動してください。

System Requirements

SDL のリリースパッケージは、次のプラットフォーム向けにビルドされています。その他の環境はソースからビルドできる可能性がありますが、現在公開している公式リリース対象には含まれません。

プラットフォーム 公式リリースターゲット 対応 OS バージョン 必要な OS 機能 権限 実行時依存
Linux x86_64 x86_64-unknown-linux-musl systemd ベースの x86_64 ディストリビューション。Ubuntu 20.04/22.04/24.04、Debian 11/12、Rocky Linux / AlmaLinux / RHEL 8 または 9、Fedora 38 以降、openSUSE Leap 15.x、Arch Linux など Linux kernel の TUN サポート (/dev/net/tun)、systemd と /run/systemd/system、systemctl、/bin/sh、iproute2 の ip コマンド。従来の route コマンドはフォールバックとしてのみ使用されます。 インストール、サービス登録、TUN 作成、ルート変更には sudo による root 権限が必要 公式パッケージは musl static build のため glibc 要件はありません。
macOS Apple Silicon aarch64-apple-darwin Apple Silicon 上の macOS 12 Monterey 以降を想定しています。macOS 13 Ventura、14 Sonoma、15 Sequoia で動作する想定です。 launchd / launchctl、組み込み utun サポート、/bin/sh、システムの route コマンド インストール、LaunchDaemon 登録、utun 設定、ルート変更には sudo による root 権限が必要 追加のサードパーティ実行時依存はありません。Intel macOS 向け公式リリース成果物は現在公開していません。
Windows x86_64 x86_64-pc-windows-msvc Windows 10 1809 以降、Windows 11 21H2 以降、Windows Server 2016 / 2019 / 2022 / 2025 Windows Service Control Manager、install.ps1 実行用の PowerShell 5.1 以降、cmd.exe、IPv4 ルート管理 インストール、サービス登録、Wintun ドライバ利用、ルート変更には Administrator 権限が必要。インストール後の日常的な sdl CLI 操作は通常ユーザーで実行できます。 wintun.dll はリリース zip に同梱され、実行ファイルと同じ場所にインストールされます。

Linux に関する注意:

  • インストーラは non-systemd ホストを明示的に拒否します。コンテナ、WSL、OpenRC ベースのディストリビューション、/run/systemd/system のない最小イメージは install.sh の対象外です。
  • 公式 Linux 成果物は x86_64 のみです。ARM64 Linux は将来のソースビルド対象として扱えますが、現在のリリースワークフローでは公開していません。
  • サービスはデフォルトで sdl-tun という TUN デバイスを作成し、ip route replace でルートを設定します。既存のローカルルートと SDL 仮想ルートが衝突する可能性はあります。

Windows に関する注意:

  • インストーラは管理者 PowerShell が必要です。これはネイティブ Windows サービスの登録、C:\Program Files\SDL への書き込み、wintun.dll の配置、machine PATH の設定を行うためです。
  • 32-bit Windows と Windows on ARM は現在のリリースパッケージではサポートしていません。
  • Windows 7/8/8.1 は現在のインストーラおよびリリースポリシーの対象外です。

ネットワークとディスク:

  • コントロールプレーンへの outbound HTTPS。デフォルトは https://control.middlescale.net/control です。
  • コントロールプレーンが選択するゲートウェイポリシーとローカルネットワーク状況に応じて、SDL ゲートウェイリレーへの UDP、QUIC、または HTTPS アクセスが必要です。
  • バイナリ、identity file、profile、ローテーションログ用に数 MB 程度のディスク容量が必要です。

Download

ダウンロードページ からプラットフォームに合うリリースアーカイブを取得してください。各アーカイブには次のファイルが含まれます。

  • Linux / macOS: sdl, sdl-service, install.sh, README.txt
  • Windows: sdl.exe, sdl-service.exe, wintun.dll, install.ps1, README.txt

Install on Linux

展開したリリースフォルダで次を実行します。

sudo ./install.sh

インストーラは sdl と sdl-service を /opt/sdl にコピーし、/usr/local/bin にシンボリックリンクを作成します。また /opt/sdl/env に永続的なデバイス ID を生成し、すぐに起動する sdl-service という systemd unit を登録します。

インストール後の構成:

/opt/sdl/
  sdl
  sdl-service
  env/                         # マシン ID と永続サービス状態
    config.json                # アクティブプロファイル、またはマルチユーザー時の active_user_id ポインタ
    device-id                  # マシン ID
    device.key                 # マシンの秘密 ID キー
    service-state.json         # CLI 用のサービス、認証、実行時状態
    command.sock               # ローカル CLI からサービスへのソケット。実行時に作成されます
    service.lock               # ローカルサービスロック。実行時に作成されます
  profiles/                    # sdl switch で使う保存済みプロファイル
    hxm.json
    sdl-cdba6d9b6ebb53ca.json
    ent-acme-admin.json
  log/
    sdl-service.log            # macOS のローテーションログ。Linux は通常 journald を使います

profiles ディレクトリには SDL ユーザーごとの保存済みプロファイルが入ります。env/config.json には、古い単一ユーザー構成のアクティブプロファイル、またはマルチユーザー構成の active_user_id ポインタが入ります。sdl switch --userId <user-id> はアクティブユーザーを切り替え、sdl-service に profiles/ 配下の該当ファイルを読み込ませます。アップグレード時にデバイス ID と保存済みプロファイルを維持したい場合は、env と profiles の両方を保持してください。

systemd でサービスを管理します。

systemctl status sdl-service
systemctl restart sdl-service
journalctl -u sdl-service -f

Install on macOS

macOS でも同じ install.sh を使います。インストーラがプラットフォームを検出し、systemd unit の代わりに launchd plist を作成します。

sudo ./install.sh

サービスラベルは net.middlescale.sdl-service で、KeepAlive により自動維持されます。管理には launchctl を使います。

sudo launchctl kickstart -k system/net.middlescale.sdl-service
sudo launchctl bootout system /Library/LaunchDaemons/net.middlescale.sdl-service.plist

バイナリは Linux と同じく /opt/sdl に配置され、/usr/local/bin へシンボリックリンクされます。

Install on Windows

リリースアーカイブを展開し、PowerShell を右クリックして Run as Administrator を選択します。展開したフォルダで次を実行します。

.\install.ps1

インストーラは sdl.exe、sdl-service.exe、wintun.dll を C:\Program Files\SDL にコピーし、env\ と log\ を作成します。また永続的なデバイス ID を生成し、sdl-service という Windows サービスを登録します。サービスは遅延自動起動で、失敗時に再起動されます。インストールディレクトリはマシン PATH に追加されます。

インストール後の構成:

C:\Program Files\SDL\
  sdl.exe
  sdl-service.exe
  wintun.dll
  env\                         # マシン ID と永続サービス状態
    config.json                # アクティブプロファイル、またはマルチユーザー時の active_user_id ポインタ
    device-id                  # マシン ID
    device.key                 # マシンの秘密 ID キー
    service-state.json         # CLI 用のサービス、認証、実行時状態
  profiles\                    # sdl switch で使う保存済みプロファイル
    hxm.json
    sdl-cdba6d9b6ebb53ca.json
    ent-acme-admin.json
  log\
    sdl-service.log            # ローテーションサービスログ

env\ は共有ディレクトリです。通常ユーザーは sdl status、sdl auth などを実行できるように読み取りとトラバース権限を持ちます。一方、秘密鍵 device.key は SYSTEM と Administrators に制限されます。共有設定や状態への書き込みは、昇格済みサービスのローカルコマンドソケット経由で行われます。

サービス管理:

Get-Service sdl-service
Restart-Service sdl-service
Stop-Service sdl-service
Start-Service sdl-service

Exit Node

SDL exit node は、あるデバイスの通常の IPv4 インターネット向け通信を、別の SDL デバイス経由で外へ出す機能です。典型的には、ノート PC やデスクトップからリモートの Linux サーバーを出口として使いながら、通常の SDL mesh への接続も維持します。

現在の対応状況:

  • 利用側クライアント: Linux、macOS、Windows は承認済み SDL exit node を利用できます。
  • exit node 側: 現在は Linux のみ対応です。
  • 通信範囲: IPv4 の full-tunnel routing です。IPv6 の exit-node routing は現在のリリース対象外です。

仕組み

SDL exit-node mode には 2 つの側があります。

  • Node A、クライアント側: 0.0.0.0/1 と 128.0.0.0/1 の split default route を sdl-tun に向けて設定します。これにより通常の IPv4 インターネット通信が SDL に入ります。
  • Node B、exit node 側: SDL から届いたパケットを受け取り、Linux forwarding を有効にし、指定された egress interface で NAT/MASQUERADE を行います。

クライアントはすべてを無条件に tunnel へ入れるわけではありません。SDL は overlay 自体を維持するために必要なアドレスを自動的に除外します。

  • control-plane endpoint;
  • 有効な gateway relay endpoint;
  • SDL peer への direct P2P underlay endpoint;
  • --exclude でユーザーが追加したアドレス。

これらの除外により、exit node に到達するための transport packet が exit-node tunnel 自身へ戻ってしまうループを防ぎます。別の SDL デバイスの virtual IP への通信など、SDL mesh 内の通信は exit node 有効中も維持されます。

DNS も exit-node behavior の一部です。クライアントが exit node を選択すると、SDL は SDL DNS をクライアントの global resolver として設定します。これにより通常の DNS lookup はローカルネットワーク resolver へ漏れず、SDL 経路を使えます。選択を clear すると、SDL は保存していた DNS 状態へ戻します。

Linux で exit node を有効化する

インターネット出口として使う Linux デバイスで次を実行します。

sdl exit-node enable --egress-interface eth0

eth0 はインターネットへ出られる interface に置き換えてください。

このコマンドはローカル Linux 側の routing を準備します。

  • 必要であれば IPv4 forwarding を有効化します。
  • egress interface から出る通信に NAT/MASQUERADE rule を追加します。
  • このデバイスが exit-node capability を advertise したいことを control plane に報告します。

SDL は IPv4 forwarding を後で自動的に無効化しません。net.ipv4.ip_forward=1 は、それ単体では通常大きな問題になりません。実際に転送が意味を持つのは firewall/NAT rule が通信を許可している場合です。Docker、router、VPN software、その他の service が同じ設定に依存している可能性があるため、SDL は有効化した forwarding を戻しません。

他のクライアントが利用する前に、control plane 側でこのデバイスを承認する必要があります。

sdl-admin exit-node list --id <user-id>
sdl-admin exit-node approve --device-id <device-id>

ローカル状態を確認します。

sdl exit-node status

ローカルマシンを exit node として advertise するのを止めるには次を実行します。

sdl exit-node disable

disable は、この exit-node 設定で追加した SDL NAT/FORWARD rule を削除します。管理者承認は自動的には削除されません。承認を revoke するか残すかは管理ポリシーに従ってください。

クライアントから exit node を使う

利用可能な exit node を一覧します。

sdl exit-node list

名前、virtual IP、または device ID で選択します。

sdl exit-node use <exit-node-name|virtual-ip|device-id>

たとえば sdl exit-node list に office-hk という exit node が表示されている場合は、sdl exit-node use office-hk を実行できます。

現在の選択状態を確認します。

sdl exit-node status

選択を解除し、ローカル routing/DNS を戻します。

sdl exit-node clear

選択した exit node の名前または device は、active SDL profile に last selection として保存されます。ただし active な full-tunnel state は sdl-service の再起動後に自動復元されません。これは意図的な動作です。sdl exit-node use は system default route と DNS を変更するため、service restart や system restart の後に exit node を再度有効化するには、明示的なユーザー操作が必要です。

sdl-service が停止または再起動すると、SDL は client-side exit-node route と DNS state を reset します。sdl exit-node status は利便性のため last selected exit node を表示することがありますが、Using exit node は sdl exit-node use <target> を再実行するまで disabled と扱ってください。

別の VPN がすでに full-tunnel split route を設定している場合、sdl exit-node use は警告を出して処理を拒否することがあります。その場合は、先に別の full-tunnel route を無効化してから再実行してください。

Tailscale との互換性

SDL は Tailscale と共存できます。ただし full-tunnel DNS を所有する product は 1 つだけにするべきです。

Routing compatibility:

  • Tailscale exit node を使っていない状態であれば、SDL は sdl exit-node use のための split default route を設定できます。
  • 100.x.y.z のような Tailscale peer route は、Tailscale interface 経由で引き続き利用できます。
  • SDL は control、gateway、peer underlay endpoint を SDL full tunnel から除外し、SDL transport path が自分自身へ戻ることを防ぎます。
  • 同じクライアントで Tailscale exit node と SDL exit node を同時に有効化しないでください。どちらも default route を所有しようとします。

DNS compatibility:

  • SDL exit-node mode は、SDL DNS をクライアントの global resolver (~.) として設定します。
  • Tailscale の accept-dns=true は、Tailscale が system DNS configuration を書き換え、通常 100.100.100.100 経由の global DNS route (~.) を設定できる状態です。
  • SDL exit-node mode も、通常の domain lookup を SDL exit-node 経路へ流すために global DNS を所有する必要があります。SDL と Tailscale の両方が global DNS route を設定すると、system resolver は interface priority、cache state、OS 固有の resolver behavior によってどちらかを選ぶ可能性があります。
  • その結果、DNS query が SDL exit node を通らず Tailscale や local DNS 側へ抜けたり、SDL の routing は正しく見えるのに再起動やネットワーク変更後に DNS の挙動だけ変わったりします。
  • SDL exit node と Tailscale を同時に使う場合の推奨設定:
sudo tailscale set --accept-dns=false

これは Tailscale 自体を停止する設定ではありません。Tailscale に system resolver を管理させないだけです。これにより SDL は exit-node DNS route を設定でき、Tailscale peer connectivity は Tailscale interface 経由で引き続き利用できます。

現在の Tailscale DNS 状態は次で確認できます。

tailscale dns status

accept-dns=false でも Tailscale の data-plane connectivity は維持できます。ただし Tailscale MagicDNS 名は system resolver では解決できなくなる場合があります。その場合は Tailscale IP address を直接使うか、MagicDNS を SDL exit-node DNS より優先したいときだけ一時的に Tailscale DNS を戻してください。

sudo tailscale set --accept-dns=true

Common Commands

sdl status              # ローカルサービス、認証、ネットワーク、経路、ゲートウェイ状態
sdl status --json       # 機械処理向け。auth_pending / last_error を含みます
sdl list                # ピアと到達性
sdl gateway --json      # ゲートウェイ候補とアクティブ選択
sdl gateway --set auto  # ゲートウェイ選択を自動に戻す
sdl gateway --set <name> # 特定ゲートウェイに固定
sdl route --json        # 現在の転送経路
sdl channel_change --type relay   # リレーチャネルを強制
sdl channel_change --json
sdl rename <new-name>   # 表示名を更新。ローカル反映には sdl-service の再起動が必要です
sdl suspend             # サービスを終了せずにトラフィック処理を一時停止
sdl resume              # 既存ランタイムを再開、または保存設定から再作成

Logs

ログの保存先はプラットフォームごとに異なります。

  • Linux: sdl-service は stderr に出力し、journald が取得します: journalctl -u sdl-service -f
  • macOS: /opt/sdl/log/sdl-service.log にローテーションログを出力します (10 MB x 5 世代)。
  • Windows: C:\Program Files\SDL\log\sdl-service.log にローテーションログを出力します (10 MB x 5 世代)。

デフォルトレベルは info です。RUST_LOG 環境変数で上書きできます。Linux/macOS ではサービス環境に設定し、Windows では HKLM\SYSTEM\CurrentControlSet\Services\sdl-service\Environment の MultiString 値でサービス環境を設定します。バイナリの隣に任意の log4rs.yaml を置くと、全プラットフォームで組み込みログ設定より優先されます。

Uninstall

Linux

sudo systemctl disable --now sdl-service
sudo rm /etc/systemd/system/sdl-service.service
sudo systemctl daemon-reload
sudo rm -rf /opt/sdl /usr/local/bin/sdl /usr/local/bin/sdl-service

macOS

sudo launchctl bootout system /Library/LaunchDaemons/net.middlescale.sdl-service.plist
sudo rm /Library/LaunchDaemons/net.middlescale.sdl-service.plist
sudo rm -rf /opt/sdl /usr/local/bin/sdl /usr/local/bin/sdl-service

Windows

管理者 PowerShell で、展開したリリースフォルダから次を実行します。

.\install.ps1 -Uninstall

これによりサービスを停止して削除し、インストールディレクトリを削除し、マシン PATH からインストールディレクトリを外します。