7Days To Die サーバの建て方
こちらの記事は一応a19(最近追ってないので間違いあるかも)の情報です。
Ubuntu版はこちらをご覧ください。
最終更新日: 2021/12/15

これら一式を担うサーバソフトを公開しています。そちらもご検討ください。

はじめに

まず、サーバを建てるための前提スキルとして
  1. 自分で解決できる能力
  2. 使用しているOSを問題なく使える
  3. ネットワークに関する最低限の知識
が必要であるということを把握しておいてください。
また、PC初心者を対象とした記事ではないため基礎的内容の細かい説明は省きます。
わからない部分は各自でお調べください。

Youtube動画版解説

Youtubeにて実演動画をアップロードしておきました。


サーバの種類

まず、7dtdサーバには2通り、細かく分けて3通りあります。
  1. ゲーム内からサーバを建てるサーバ
  2. ゲームクライアントを独立させたサーバ
  3. 完全サーバ専用の独立サーバ
まず1つ目が様々なゲームでも用いられている「ゲーム内からサーバを建てるサーバ」です。
これは普通にプレイするだけでサーバが開けられるというものですごく簡単です。
ただし、デメリットもあるため注意が必要です。(後述)
次に「独立させたサーバ」です。
一般的にサーバといえばこの方法を用います。 独立しているため安定性が高く、やり方によればカスタマイズも可能です。 ただし、こちらにもデメリットがあります。(後述)

さらに詳しく見てみましょう。
  • ゲーム内サーバ

  • 非常に簡単にマルチプレイができる方法です。
    設定も簡単に行えることからスキルがなくてもサーバ構築することができます。

    ただし、ゲーム自体をサーバとするためエラーなどによる強制終了で、データのロールバックや破損が起こる可能性があります。
    また、ホストが抜けるとサーバも終了します。
  • ゲームを独立させたサーバ

  • こちらはゲーム内サーバと違い、独立したサーバで、Dedicated Serverといいます。
    ゲームとは別で動作するため、ホストが抜けようがエラー落ちしようが終了することはありません。

    ただし、ゲームをするマシンと同一のマシンで行う場合はマシンスペックに注意が必要です。
    ゲームとサーバを2つ動かすことになるのでメモリの大消費などが懸念されます。
    完全独立サーバとの違いはゲームクライアントを使用する点です。
    そのため、サーバ用Modが提供されていない場合はゲーム環境にModを入れて、こちらの方法でサーバを構築するとModサーバが立てられます。
  • 完全独立サーバ

  • こちらも上のサーバと同じです。
    違うところとしては完全サーバ専用であり、Server Fixes(Modのようなもの)の使用も可能です。
    サーバ専用のModが提供されていない場合はこちらでは動作しません。
    なお、こちらは64bit OS専用となります。

    クライアントの独立サーバよりこちらを使うメリットと言えば現状64bitなのとServer Fixesのマップくらいしか思いつきませんが、今後サーバ用途はこちらに一本化するとかどっかで見かけた気がする。
今回は一番下の「完全独立サーバ」を使用した解説を行います。
なお、ゲームを独立させたサーバもゲーム本体でやるだけなので全く同じです。



下準備

まずDedicatedサーバのインストールを行います。
Steamのツールより7 Days to Die Dedicated Serverのインストールを行ってください。

下準備はこれで完了です。
ただし、こちらのサーバは64bit OS専用であるため32bit OSの場合はこの手順を飛ばしてゲームクライアントにて同様の動作を行ってください。
どちらでも動きます。


ポート開放と転送の必要性

サーバを構築し、外部に公開(友達を誘って遊ぶ場合も)する場合に必ず出てくるワードがポート開放と転送です。
一般的にはどちらもポート開放と表現されることが多いのですが、ここではファイアウォールの設定をポート開放とし、ルータの設定をポート転送とします。
なお、技術的な話は可能な限り省いているので本当の動作としてはここまで単純な動作ではありません。
IPv6環境下でのサーバ公開はIPv6 DS-Lite環境下で特定のポートのサーバを公開するを御覧ください。

ポート開放

まずはポート開放です。
Windows OSには標準でファイアウォールが導入されており、密かに不正な通信を防御しています。
通常使用の範囲内であれば特に気にすることはないはずですが、サーバとなると他者から接続されることになります。
この時、外部に公開しないサービスが動作していると悪意のある者に接続されて情報が抜かれたり破壊されたり、踏み台にされるわけです。
そんな状況を防止するのがこのファイアウォールという機能で、許可されていない通信は全て遮断されるのが一般的です。

しかしながら、それではサーバを立てても外部に公開できないので、立てたいサーバの条件だけファイアウォールに追加し、許可するように設定します。
こうすることでクラッキングの脅威を最小限に抑えることができます。
間違ってもファイアウォールをオフにするなんてことはしてはいけませんよ。

ちなみに、ハマチなどのVPN技術を使うとこのファイアウォールは迂回されます。(もちろん設定によるが)
次に述べるポート転送もVPNでは迂回されるので安易に使用することは推奨しません。
本当に身内同士で安心できる間で使うなら、一通りポート開放・転送ができてVPNも理解した上で使うと良いでしょう。

ポート転送

そしてここが大抵詰まるポイントです。
ポート転送はポート開放と同じ振る舞いをするように見えますが、実は全く原理が異なります。
なお、モデムやONU(光回線終端装置)だけで運用している場合はポート転送は必要ありません。
また、IPv6でも話は変わってくるので以下のポート転送はIPv4のみの説明です。

まずはインターネットの仕組みを解説しないといけません。
例えば、Googleの検索サイトを見ているとしましょう。
まずは検索サイトの情報が光回線に乗って自宅まで届きます。
その後、そのままパソコンに繋がるのではなく、一度ONU(ADSLはモデム)に届けられます。
光はいわゆるアナログ信号なので一度デジタル信号に変換する必要があり、ONUは光をデジタル信号に変換する役割を担います。
あとはパソコンに繋げれば検索結果が見られるわけですね。


というのは過去の話で、一台だけならこれで済むんですよ。
しかしながら、近年はスマホだったりパソコン自体複数持つのが当たり前になったため一つの光回線を複数台で共有する必要が出てきました。
じゃあ数増やして挿せば動くんじゃねーかって気がしますが、そんな甘くはないんですよね。
光回線にはIPアドレスというインターネット上の住所みたいなもの(グローバルIPアドレス)が一つだけ割り当てられるのですが、それを複数台で繋げると住所が複数存在することになり、受信がうまくできないんです。(実際は送信すらできないと思うけど)


そこで出てくるのがルータです。
ルータはまず、スマホなどの複数端末にルータ内だけで使えるIPアドレスを割り当てます。(この時のIPアドレスをローカルIPアドレスと言い、ルータ内だけのネットワークをローカルエリアネットワークと言います)
これで各端末それぞれに唯一のIPアドレスが割り当てられることになります。
あとはルータにONUの光回線を繋ぐことでルータに光回線のIPアドレスが割り当てられることになり、ルータはスマホなどのLANからの通信をいい感じに変換(NATやNAPT)し、外部との通信を実現します。


じゃあサーバもいい感じにやってくれるかっていうとそう甘くはありません。
LAN内から外部への接続の場合は始まりの端末がわかるためいい感じに変換ができますが、外からの接続の場合は光回線のIPアドレスを指定するだけになるため、複数台あるうちのどれが対象のサーバかわかりません


そこでルータのポート転送にてどのサーバへ接続を転送するかを設定することで初めてサーバへ通信が飛んできます。


ちなみに、自分のサーバに入るのに友達に教えるグローバルIPアドレスではなく、ローカルIPアドレスになるのは正にルータがあるからなんです。
ルータ内のローカルネットワークで完結するため、ルータから外には出ず、ローカルIPでしか繋がりません。
NATループバックという機能でルータが対応していればグローバルIPでローカルに接続することができます。
グローバルIPで参加するメリットはフレンドリストにグローバルIPで登録されるので、参加者がわざわざIPを直打ちして参加する必要がありません。
7dtdではドメイン名での参加ができるのでドメインを保有しているならhosts書き換えでも対応できるのでどちらにせよ同じことはできたり。
ちょっと逸れますが、L4D2なんかはIP以外受け付けないのでNATループバックが対応されていないとコンソールから入って貰う必要があってかなりめんどくさいです。


ポート開放 (ファイアウォール)

サーバに付き物なのがこのポート開放・転送設定です。
こちらをしなければローカルネットワーク外からの接続はできません。
通常はサーバを初めて起動するとアラートが出て(プライベートかパブリックを選ぶやつ)、そのまま許可をしていれば設定されているので既にある場合はスルーでいいでしょう
ポート転送含めてやったものの繋がらず、ファイアウォールを一時的にオフにすると繋がる場合はファイアウォールの設定が必要です。


やり方は知ってるけれど、プロトコルがわからない方は以下を参考に。
なお、ポートの各用途は「https://7dtd.illy.bz/wiki/Ports」にて掲載されています。
TCP 26900
UDP 26900, 26901
UDP 26902 (RakNetを使用する場合 a17以降は不要)
UDP 26903 (UNETを使用する場合 a17以降は不要)


ポート開放はファイアウォールで行います。
ファイアウォールを開き、詳細設定を開いてください。


受信の規則に7 Days to Dieの規則が無ければ「新しい規則」で規則の追加を行います


「プログラム」を選択して次へ。


「このプログラムのパス」に7daystodie.exeのパスを。


「接続を許可する」


こちらは任意ですが、プライベートでいいでしょう。


あとは適当に名前を付けてOK。


ポート転送 (ポートフォワード)

一応自宅で使ってるルータ(Archer C7)の設定方法だけ載せますが、あくまで参考例としてご覧ください。
ルータの機種によって設定が異なり、最悪の場合こういったポートフォワードの設定ができない場合もあるので注意してください。

詳細設定より、「NAT転送 -> 仮想サーバ」を開きます。
この辺りは機器によって表記が異なり、昔使ってたCoregaのCG-WLBARAGNDは「バーチャルサーバ」でした。
その他にもNTTのモデム内蔵ルータとかは「静的IPマスカレード」って表記みたい。
技術的にはPort ForwardingもしくはPort Mappingと言うのでポートフォワードと説明しますが、いずれも同じです。

設定を開くと外部ポート・内部IP・内部ポート・プロトコルの設定があるため、適当に入力します。
この辺りは設定できるルータならほぼ変わりませんが、外部と内部ポートが別れてないなど細かい違いはあるかと思います。

外部ポート 外部から接続されるポート番号。
要するに外部からアクセスする際に指定するポート番号のことです。
内部ポート ローカルネットワーク内のポート番号。
基本的には外部ポート番号と内部ポート番号は同一で問題ありませんが、異なるポート番号を指定することも可能です。
例えば、サーバ内だけで動作するプロセスにて26900ポートがすでに使われており、27900を割り当てたとします。でも外部からは26900でアクセスして欲しい場合は外部ポートに26900を指定し、内部ポートには27900を指定します。
要するに、「外部ポート -> 内部ポート」へと変換します。
内部IP パケットを転送する端末のローカルIPアドレスを指定します。
サーバのローカルIPを指定すればOK。
内部ポートも合わせて、「グローバルIP:外部ポート」から「内部IP:内部ポート」へ転送されることになります。
プロトコル TCP/UDPいずれかもしくはAll(両方)を指定します。

あとは以下の手順よりサーバ起動してCMAN社の提供する「ポートチェック【外部からポート開放確認】」などを利用して繋がるかどうか確認します。
ちなみにUDPはチェックここではできず、するにしても結構めんどくさいのでTCPだけ繋がってたら問題ないでしょう。

サーバ設定

続いてサーバ設定を行います。
先程インストールした7 Days to Die Dedicated Serverの保存されている場所を開けてください。
serverconfig.xmlをテキストエディタなどで開き、以下の設定を行います。

記述内容についてですが、xmlで記述されています。
<property name="XXX" value="YYY" />
こうあるとすれば、YYYを書き換えることで設定の変更ができます。
XXXはプロパティ名です。

※アップデートで項目が消えたり増えたりして収拾つかなくなったので以下のテーブルは更新してません。


サーバ起動

設定が終了しましたら起動していきます。
serverconfig.xmlと同一のディレクトリにstartdedicated.batというファイルがあるため、そちらを実行。
パスワード入力画面が出ましたら完了です。

ただし、環境によってはこの画面に行き着かない場合があります。
その場合は次の項をご覧下さい。

パスワード入力に行きつかない

スペックの事情やTelnetの有無によってパスワード入力に行き着かない場合が多々あります。
私もその口です。
これはbatがサーバ起動させたあとに15秒間待機し、Telnet接続を試みるといった単純な処理が書かれているために起こります。
15秒間の間にサーバが起動していなければTelnet接続は失敗します。
Telnetクライアントが未インストールであれば起動が完了していても失敗します。
なお、記事執筆当時の話なので2020年4月1日現在はもうちょっと複雑なバッチファイルになっていますのでマシにはなってるのかも。

この場合はとりあえずTelnetがインストールされているか確認しましょう。
確認方法は「Windowsキー + R⇒telnetでエンター」で

こちらのようなエラーが出た場合はTelnetがインストールされていません。
*当環境にはインストールされているため敢えて打ち間違えています。
その場合はTelnetをインストールしましょう。
Telnetクライアントのインストール方法についてはWindowsにおけるTelnetのセットアップをご覧下さい。
なお、XPには元からTelnetクライアントはインストールされています。

別でTelnetをインストールしている場合は各自設定をしてください。

スペックの問題や別のTelnetがある場合はTelnet接続エラーの後コマンドラインを閉じ、起動が完了してからTelnetクライアントにて接続を試みてください。
Telnetコマンドの例は以下のとおりです。

telnet [host] [port]
例:telnet localhost 8081

                
目安としてはおおよそ7DaysToDie.exeが1.5-2.0GBほどのメモリを使用していると起動が完了しています。
ただし、環境によっては異なる値を示すため何度かトライしてみましょう。


Server Fixesの導入

はじめに

こちらからはサーバ拡張作業になります。
必ず必要な手順ではないため省いても問題ありませんが、通常のサーバでは物足りない部分や不具合が修正されているので筆者は導入をおすすめします。

ただし、こちらからは拡張であるためリネームなどの作業は各自必要だと思った場合行ってください。
その説明は一切しません。

サーバ環境に関する注意

こちらの拡張はゲームクライアント版のDedicatedサーバでは一切動作しません。
SteamのツールにあるDedicatedサーバをベースに行いましょう。

基礎の導入

こちらからserver_fixes.tar.gzをダウンロードします。
※tar.gzファイルはWindows標準のソフトウェアでは展開できないため、WinRARや7zipなどを用意しておきましょう。

ダウンロードしてきたファイルを展開し、出てきたModsフォルダをそのまま7 Days To Die Dedicated Serverに移動させます。 これでインストールが完了しました。
このままサーバを起動して問題なく起動できたら完了です。

マップを開く

マップは解凍時にModsフォルダ内のAllocs_WebAndMapRenderingを導入した場合のみ利用できます。
まず、serverconfig.xmlのTelnetPortのポート番号を控えておきましょう。
次に、ウェブブラウザにて「http://127.0.0.1:TelnetPort + 1」にアクセスします。
ポート番号には先程控えておいたポート番号に1を足したものになります。
8080なら、「http://127.0.0.1:8082」となります。

なお、初期設定ではSteamアカウントでログインしていないと利用できないため、必要な場合はマップの設定を御覧ください。

マップの設定

マップは7dtdサーバと同じく、以下の設定ファイルにてパーミッション管理がされています。
C:\Users\*UserName*\AppData\Roaming\7DaysToDie\Saves\webpermissions.xml
なお、AppDataは隠しファイルですので表示設定を行うか「ファイル名を指定して実行」にて「%AppData%」と入力してください。

設定ファイルの中はXMLで記述されており、7dtd本体のサーバ設定と同じ言語が用いられています。
また、すべてコメントアウトされていますが、恐らくこれが初期設定であると考えられます。

パーミッションですが、1000まではゲーム内のAdminまたはWhitelistのパーミッションと同期しています。
何も設定していないかパーミッションレベルを1000で設定している場合1000として扱われ、こちらのマップでも1000として扱われます。
また、1000までの場合Steamアカウントでのログインが必要となります。
全く関係のない第三者の場合は2000として扱われ、2000としたものに関してはログインの必要はありません。

permissions
プロパティ名 説明
web.map マップ表示に関する権限
webapi.getlog サーバコンソールのログの表示に関する権限
webapi.executeconsolecommand プロパティ名から推測するとコンソールコマンドを実行する権限
webapi.getstats
webapi.getplayersonline オンラインのプレイヤーを取得する権限
webapi.getplayerslocation プレイヤーの位置を取得する権限
webapi.viewallplayers
webapi.getlandclaims LandClaimを取得する権限
webapi.viewallclaims
webapi.getplayerinventory プレイヤーのインベントリを取得する権限
webapi.gethostilelocation ゾンビの位置を取得する権限
webapi.getanimalslocation 動物の位置を取得する権限

コマンドの.(ドット)以前を見るとwebとwebapiがありますが、webはウェブブラウザ上で表示されるもので、webapiの場合はウェブブラウザ上のマップでも反映されますが、それ以前にウェブAPIとして機能しているため外部アプリケーションやプログラム制御でデータだけの取得が可能です。
なお、Web APIは成功時にJSONで戻ってきます。

Web API

ここからは情報がほぼないのでちょくちょく解析してるデータを書いていきます。
正確性が微妙なので正常に動作しない場合もあるかもしれませんのでご注意ください。

Web APIはwebpermissions.xmlのパーミッションに基づいて動作します。
今回は例として全部0で動作してることにします。

今回はすべて権限内で動作するのでトークンの発行が必要となります。
トークンはadmintokensタグの子要素のtokenタグで設定します。
なお、2000の場合はトークンの発行は必要ありません。

admintokens
プロパティ名 説明
name トークンの名前です。
トークン判別で利用するので判別可能な名称をつけてください。
token トークン本体です。
パスワードといった認識でいいと思います。
permission_level パーミッションレベルです。
0から1000で指定します。

今回は「<token name="adminuser1" token="supersecrettoken" permission_level="0" />」とします。

設定が終わりましたら試しにアクセスしてみましょう。
ウェブブラウザで「http://127.0.0.1:8082/api/getstats?adminuser=adminuser1&admintoken=supersecrettoken」でアクセスしてみてください。
getstats.jsonで以下の様なデータが取れたとおもいます。
{
    "gametime":{
        "days":1,
        "hours":9,
        "minutes":22
    },
    "players":0,
    "hostiles":0,
    "animals":0
}
                
こちらのデータの扱いは今回述べないとして、取得方法がパターン化されているのでURLを分解していきます。

公式ページでも書かれていますが、
http://[Address]:[Port]/api/[property]?adminuser=[name]&admintoken=[token]」といった形で取得します。
アドレスとポートは既知であるとして、[property]はwebapi.[ここ]の[ここ]の部分が当てはまります。
今回の例だとwebapi.getstatsをターゲットにしていたのでgetstatsが入りました。

次に、adminuser=[name]ですが、先ほど設定したtokenタグのname属性の値が入ります。
更に、それのセットとして、admintoken=[token]にはtoken属性の値が入ります。
これを指定することでログインなしに指定されたパーミッションでjsonの取得ができます。

これを応用すると、同じように他のjsonも取得することができます。
例えば、プレイヤーの位置を取得したい場合は
http://127.0.0.1:8082/api/getplayerslocation?adminuser=adminuser1&admintoken=supersecrettoken
で取得することができます。

ここまで書きましたが、結構わからない部分が多いので分かり次第追記していきます。