リモートアクセス: ログインとIP許可リスト

このガイドでは、スマートフォン、ラップトップ、Dockerコンテナーなど、別のデバイスからMarinara Engineに接続する方法を説明します。主な選択肢はログインです。あわせて、IP許可リスト、ログイン用プロキシ、HTTPS、Admin Access、そして「save blocked」というCSRFのメッセージについても取り上げます。ここで扱う設定はほぼすべて、アプリではなくサーバーの.envファイルにあります。

このガイド全体で使う言葉を先に整理します。

Tailscaleでどこからでも接続する

Tailscaleは、自分のデバイス同士をつなぐプライベートネットワークです。これを使うと、自宅でも外出先でも、ルーターのポートを開けたりMarinaraを公開インターネットに出したりせずに、スマートフォンやラップトップでMarinaraを開けます。MarinaraはTailscale経由で直接接続するデバイスを信頼するため、ログインを設定する必要はありません。

  1. Marinaraを動かしているコンピューターと、もう一方のデバイスの両方にTailscaleをインストールします。tailscale.com/downloadから入手できます。
  2. 両方のデバイスで、同じアカウントを使ってTailscaleにサインインします。
  3. start.sh、start.bat、start-termux.sh、またはWindowsインストーラーでMarinaraを起動します。これらの起動方法なら、ほかのデバイスから接続できます。代わりにpnpm startを実行する場合は、先に.envファイルへHOST=0.0.0.0を追加してください(.envファイルの場所を参照)。
  4. Marinaraを動かしているコンピューターのTailscaleのアドレスを調べます。そのコンピューターでTailscaleアプリを開くか、tailscale ip -4を実行します。アドレスは100.で始まります。たとえば100.101.102.103のような形式です。
  5. もう一方のデバイスでTailscaleをオンにし、ブラウザーでhttp://100.101.102.103:7860を開きます。アドレスは自分のものを使い、PORTを変更している場合はその番号を使ってください。サインインページは表示されず、そのままMarinaraが開きます。

ページが読み込まれない場合は、両方のデバイスでTailscaleがオンになっていること、そしてサーバーがHOST=0.0.0.0で待ち受けていることを確認してください。

Note: この方法はDockerでのインストールでは使えません。Tailscaleの通信はDockerゲートウェイを経由してコンテナーに届くため、MarinaraはそれがTailscaleから来たものだと判別できません。先にログインを設定してから(方法1)、ポートを127.0.0.1の外へ公開してください。

バックアップ、インポート、アップデートなどの危険を伴う操作をリモートのデバイスから行うには、引き続き管理者用シークレットが必要です。Admin Accessと特権が必要な操作を参照してください。

Marinaraがデフォルトで遮断するもの

データを守るため、インストール直後のMarinaraは、アクセス制御を設定するまで他のデバイスからの接続を拒否します。デフォルトで信頼されるのは、次の3種類のクライアントだけです。

  1. ループバック(127.0.0.1または::1)、つまりサーバーを動かしているコンピューター自身。同じコンピューター上のリバースプロキシやトンネルが中継した訪問者は含まれません。同じコンピューター上のリバースプロキシとトンネルを参照してください。
  2. tailnet内のTailscaleデバイス。Tailscaleはプライベートネットワークを作るツールで、アドレスは100.64.0.0/10の範囲を使います。
  3. 同じホスト上のDockerクライアント。Marinaraは一般的な172.16.0.0/12のブリッジ範囲と、コンテナーの正確なデフォルトゲートウェイを認識します。これによりDocker Desktopや独自のアドレスプールにも対応します。

それ以外は、同じWi-Fiにつないだスマートフォンでもインターネット上のクライアントでも、ログインを設定するまで遮断されます。遮断されたデバイスでブラウザーからMarinaraを開くと、暗い色のセットアップページが表示されます。タイトルはThis Marinara Engine install needs a login before remote devices can connect.です。このページには、サーバーのログに出る1回限りのセットアップコードを入力するフォームがあり、そのデバイスからログインを設定できます。

何もせず、パスワードも設定しなければ、Marinaraはこの3つの信頼済みの経路だけに限定されたままです。これが安全なデフォルトです。

.envファイルの場所

アクセスに関わる設定はすべて、プロジェクトのルートにある.envファイル、つまりpackage.jsonと同じ場所に置きます。まだ用意していない場合は、サンプルをコピーします。

cp .env.example .env

.envは好きなテキストエディターで開けます。Basic Auth、IP許可リスト、管理者用シークレット、CSRFのオリジンなど、アクセスに関わる設定はほとんどが数秒で反映され、再起動は要りません。ただしPORT、HOST、HTTPS証明書のパスなど、一部の低レベルな設定は再起動が必要です。

403ではなくタイムアウトになり、他のデバイスからそもそもサーバーに届かないこともあります。その場合、サーバーがローカルのコンピューターだけで待ち受けている可能性があります。すべてのネットワークインターフェイスで待ち受けるように設定します。

HOST=0.0.0.0

シェル用の起動スクリプト(start.bat、start.sh)はHOST=0.0.0.0を自動で設定します。pnpm startを直接実行した場合は設定されません。

起動方法ごとのデフォルトのバインドアドレスは次のとおりです。

起動方法HOSTのデフォルト
pnpm start、start-local.bat127.0.0.1
start.sh、start.bat、Windowsインストーラー、start-termux.sh0.0.0.0
Dockerイメージコンテナー内で0.0.0.0
docker-compose.ymlポートを127.0.0.1だけに公開します

どの方法を選ぶか

上から順に読み、最初に当てはまったところで止めてください。

  1. Tailscale経由で直接接続するだけ、または同じホスト上のDockerコンテナーからだけ接続する場合。pnpm startでは、直接接続するTailscaleクライアントはログインを省略できます。サーバーに届くようHOST=0.0.0.0を設定してください。デフォルトのComposeファイルは127.0.0.1だけに公開します。Tailscaleのデバイスから届くようにポートをループバックの外へ公開する場合は、先にログインを設定してください。するとDockerは、Tailscaleのデバイスを含むすべてのデバイスにログインを求めます。Dockerはそれらをゲートウェイのアドレスから来たものとして扱うためです。TailscaleとDockerのバイパスを参照してください。
  2. 自宅のWi-Fiにつないだスマートフォン、タブレット、ラップトップからMarinaraに接続したい場合。ログインを設定します(下記の方法1)。
  3. Marinaraをインターネットに公開する場合。ログインを設定し、HTTPSを使います。
  4. ネットワーク上のログイン用プロキシ(tinyauth、Authelia、Authentikなど)が、すでにすべての訪問者にログインを求めている場合。ログイン用プロキシ(forward auth)を読んでください。

いちばん融通が利くのはログインです。どのIPアドレスからでも使え、デバイスごとの設定も要らず、ブラウザーはサインインしたままになります。

方法1: ログイン(推奨)

ログインとは、リモートのデバイスすべてに求めるユーザー名とパスワードです。設定方法は3つあります。

BASIC_AUTH_USER=alice
BASIC_AUTH_PASS=correct-horse-battery-staple

.envのログインは、アプリで設定したログインより優先され、変更も.envでしか行えません。.envを保存します。変更は数秒で反映され、再起動は要りません。

パスワードは強力で、ほかに使い回していないものにしてください。アプリは10文字以上を求めます。ランダムな文字列は次のように生成できます。

openssl rand -base64 24

あとはリモートのデバイスで次の手順を行います。

  1. サーバーのアドレス(たとえばhttp://192.168.1.50:7860)を使って、ブラウザーでMarinaraを開きます。
  2. サインインページで、ユーザー名とパスワードを入力してサインインします。
  3. アプリが読み込まれるはずです。ブラウザーは、サインアウトするまで最長1年間サインインしたままになります。スクリプトやAPIクライアントは、リクエストのたびにユーザー名とパスワードを送ります(Basic Auth)。

パスワードを入力せずに別のデバイスでサインインするには、ペアリングコードを使います。サインイン済みのデバイスでSettings → Advanced → Accessを開き、Add a deviceを選びます。続いて、新しいデバイスのサインインページでそのコードを入力します。コードは数分間、1回だけ使えます。期限切れのコードには専用のメッセージが表示されるので、新しく作ってください。Signed-in devicesには、各デバイスがサインイン方法と初めてサインインした日付とともに表示されます。使用中のデバイスを含め、どのデバイスもサインアウトできます。パスワードの変更や削除もできます。その際、Marinaraを動かしているコンピューターで操作している場合かADMIN_SECRETを設定している場合を除き、現在のパスワードを求められます。

パスワードを忘れた場合は、Marinaraを動かしているコンピューターのMarinaraフォルダーでnode scripts/reset-login.mjsを実行します。Dockerではdocker exec <container> node scripts/reset-login.mjsを実行します。これでアプリで設定したログインが削除され、すべてのブラウザーがサインアウトされます。サーバーがループバックの外でも待ち受けている場合は、続いて新しいセットアップコードを出力します。このコマンドが動かない場合にかぎり、代わりにデータフォルダーから.remote-login.jsonと.remote-sessions.jsonを削除してください。デフォルトの/app/dataならdocker exec <container> rm -f /app/data/.remote-login.json /app/data/.remote-sessions.jsonを実行します。DATA_DIRを変更している場合は、そのフォルダーを使ってください。.envのログインは、.envで変更します。

ブラウザーのないヘッドレスサーバーの場合は? ヘッドレスサーバーへのネイティブインストールは、ループバックだけで待ち受け、セットアップコードを出力しません。自分のコンピューターでssh -L 7860:127.0.0.1:7860 user@serverを実行します。続いてそこでhttp://localhost:7860を開き、Settingsを使います。

15分以内に10回、異なる間違ったパスワードやコードが入力されると、Marinaraはそのアドレスからのサインインを、15分が過ぎるまで429 Too Many Requestsで拒否します。それまでに正しいパスワードが入力されれば、回数はリセットされます。ホスト上のリバースプロキシやトンネルが中継した訪問者は1つの回数を共有し、そのうちの誰かがサインインしても回数はリセットされません。サーバーを再起動しても回数はリセットされます。以前にサインインしたことのあるブラウザーは、正しいパスワードを入力すれば引き続き入れるため、ほかの人が入力した間違ったパスワードのせいで、すでに使っているデバイスから締め出されることはありません。サインインページには、あと何分待てばよいかが表示されます。パスワードを忘れた場合、サインインページにはForgot the password?というヒントが表示されます。

ブラウザーでは/loginページからサインインします。BASIC_AUTH_REALMで変更できるのは、スクリプトやAPIクライアント向けのBasic Auth認証要求に含まれるレルムで、サインインページは変わりません。

Basic Authを有効にしても、パスワードを求められないクライアントがあります。

重要: Basic Authはパスワードをエンコードするだけで、暗号化はしません。暗号化されていない接続を覗いている相手には読み取れます。Marinaraをインターネットに公開する場合は、Basic AuthとHTTPSを組み合わせてください(後述)。

方法2: IP許可リスト

IP許可リストを使うと、指定したアドレスからはパスワードなしで入れます。デバイスのIPアドレスが安定している環境に向いています。アドレスや範囲をカンマ区切りで並べます。

IP_ALLOWLIST=192.168.1.0/24,203.0.113.42

例に出てくる/24はCIDR表記です。CIDRは、まとまったアドレスの範囲を1つの記述で表す書き方です。たとえば192.168.1.0/24は、192.168.1.0から192.168.1.255までのすべてのアドレスを含みます。203.0.113.42のようにスラッシュのないアドレスは、その1台だけに一致します。

0.0.0.0/0のような広い公開範囲は、インターネット上のクライアントをログインなしで入れてしまうことがあります。信頼できるアドレスだけを記載してください。

IP許可リストの動作は次のとおりです。

許可リストでは、載っているデバイスはパスワードなし、それ以外はパスワードでログイン、という混在の設定はできません。他のデバイスにもパスワードでログインさせたい場合は、IP_ALLOWLISTを設定せず、Basic Authだけを使ってください。

リストを消さずに、適用だけを一時的に止めることもできます。新しいIPアドレスから接続して問題を調べるときに便利です。有効化のフラグをfalseにします。

IP_ALLOWLIST_ENABLED=false

プライベートネットワークのバイパス(参考)

いくつかのフラグを使うと、信頼できるプライベートネットワークに対する遮断を解除できます。これは特殊な構成向けです。ログインを使うほうが適切です。フラグとそのリスクについては、アクセス制御を参照してください。

TailscaleとDockerのバイパス

デフォルトでは、MarinaraはTailscaleネットワーク経由で直接接続したデバイスを信頼します。また、Dockerコンテナー自身のホストも信頼します。ログイン、IP許可リスト、TRUSTED_AUTH_PROXYのいずれかを設定すると、Dockerの自動的な信頼は止まり、すべてのデバイスにログインか許可リストへの登録が必要になります。これを変更するフラグについては、アクセス制御を参照してください。

Docker Desktop、OrbStack、rootless Dockerでは、公開したポートを使うすべてのデバイスが、Dockerゲートウェイのアドレスから接続したように見えます。ポートをすべてのインターフェースで公開し(-p 7860:7860)、ログインを設定していない場合、ネットワーク上の誰でも入れます。ポートは127.0.0.1にとどめるか、先にログインを設定してください。サーバーログは起動時にこの点を警告します。

同じコンピューター上のリバースプロキシとトンネル

nginx、Caddy、Traefik、Cloudflare Tunnel、Tailscale ServeやFunnel、ngrokなど、Marinaraを動かしているコンピューター上のリバースプロキシやトンネルは、ループバックからMarinaraに接続します。Marinaraは、プロキシが付け加える転送用のヘッダーからこれを見分けます。対象はForwarded、X-Forwarded-For、X-Real-IP、X-Forwarded-Host、X-Forwarded-Proto、CF-Connecting-IP、True-Client-IP、Tailscaleの身元を示すヘッダー、Viaです。MarinaraはHTTP/1.0で届くリクエストも見分けます。ブラウザーはHTTP/1.0を使いませんが、デフォルトのnginxのproxy_passは使うためです。Marinaraは、プロキシがヘッダーを追加しない場合でも、HostがドメインやLANアドレスなど別のコンピューターを指すリクエストを認識します。見分けたリクエストは、実際のとおりリモートからの訪問者として扱います。

そのコンピューター上で自分のブラウザーからhttp://127.0.0.1:7860またはhttp://localhost:7860を開いた場合は、引き続きパスワードは不要です。

Caddy、Traefik、Cloudflare Tunnel、Tailscale、ngrokは、デフォルトで転送用のヘッダーを付け加えます。nginxでは、locationブロックに次の行を入れておくことを引き続き推奨します。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

socatやssh -Rのように接続をそのまま転送するツールはヘッダーを付け加えないため、その通信はローカルからのものに見えます。Marinaraの公開にはこうしたツールを使わないでください。

プロキシ自体が、転送する前にすべての訪問者にログインを求めている場合は、ログイン用プロキシ(forward auth)を参照してください。

ログイン用プロキシ(forward auth)

tinyauth、Authelia、Authentik、oauth2-proxyなどのforward authプロキシは、リクエストを転送する前にすべての訪問者にログインを求めます。このようなプロキシがMarinaraへ届く唯一の経路であれば、Marinara側の2つ目のログインを省略できます。このようなプロキシがない場合は、設定しないでください。

プロキシのアドレスを.envに書きます。

TRUSTED_AUTH_PROXY=192.168.1.5

Marinaraは、その接続元のアドレスから来るリクエストをすべて通します。そのリクエストに対してMarinara自身のログインは求めず、セットアップコードも出力しません。Marinaraは接続そのもののアドレスを確認します。この判断では、X-Forwarded-Forなどの転送用のヘッダーは無視します。プロキシからのリクエストはIP_ALLOWLISTも通ります。誰を通すかはプロキシが決めるためです。ローカルとは見なされないので、特権が必要な操作には引き続き管理者用シークレットが必要です。この設定が有効なあいだ、Settings → Advanced → AccessにはTrusted login proxy: Setと表示されます。

設定する前に確認してください。

TRUSTED_AUTH_PROXYを設定すると、Marinaraは自動的なDockerの信頼も止めます。プロキシ以外から直接来る訪問者には、Marinaraのログインか、IP許可リストが必要です。また、Marinaraは「まだログインがない」というバナーも表示しません。

プロキシがMarinaraと同じコンピューターで動いている場合は、TRUSTED_AUTH_PROXY=127.0.0.1を設定し、プロキシの転送先はlocalhost:7860ではなく127.0.0.1:7860にします。localhostへ接続するプロキシは::1から接続することがあり、これは127.0.0.1と一致しません。この設定では、そのコンピューター上のほかのプロキシやトンネルもすべて信頼されます。そのため、ログイン用プロキシがそのコンピューター上で唯一のプロキシである場合にだけ使ってください。プロキシ経由の訪問者に、ローカルのコンピューターと同じアクセスが与えられるわけではありません。

Marinaraが192.168.1.20:7860にある場合の、Caddyの例です。

marinara.example.com {
  forward_auth tinyauth:3000 {
    uri /api/auth/caddy
  }
  reverse_proxy 192.168.1.20:7860
}

Autheliaの場合は、forward_auth authelia:9091にuri /api/authz/forward-authを組み合わせます。Authentikは、独自のサインインページもプロキシ経由で配信します。その行はrouteブロックの中に入れてください。そうすると、Caddyが順序を保ち、outpostのパスがforward auth自体を通らなくなります。

marinara.example.com {
  route {
    reverse_proxy /outpost.goauthentik.io/* authentik-server:9000
    forward_auth authentik-server:9000 {
      uri /outpost.goauthentik.io/auth/caddy
    }
    reverse_proxy 192.168.1.20:7860
  }
}

Traefikやnginxの場合は、お使いのプロキシのforward authのガイドに従ってください。Marinaraに必要なのは、プロキシのアドレスだけです。

HTTPSでの公開

HTTPSはTLSを使って通信を暗号化します。TLSは、ふつうのhttpのアドレスを安全なhttpsに変える暗号化の仕組みです。完全に信頼できるプライベートネットワークの外から接続できるインストールでは、特にBasic Authを使う場合、必ずHTTPSを使ってください。

追加の方法は2つあります。

  1. 内蔵のTLSを使います。証明書と秘密鍵のファイルをサーバーに指定します。
SSL_CERT=/path/to/cert.pem
SSL_KEY=/path/to/key.pem
  1. リバースプロキシを使います。Marinaraをnginx、Caddy、Traefik、Cloudflare Tunnelの背後に置きます。HTTPSの処理はプロキシが受け持ち、同じコンピューター上のMarinaraへはふつうのHTTPで転送します。先に同じコンピューター上のリバースプロキシとトンネルを読んでください。

SSL_CERTとSSL_KEYを設定する前に、証明書と鍵を用意しておく必要があります。ローカルで使うならmkcert、公開ドメインならcertbotのようなツールで作成できます。ファイルが見つからない、または読み取れない場合、サーバーは起動時に停止し、探したパスをそのまま表示します。

Admin Accessと特権が必要な操作

特に慎重な扱いが必要な操作があります。データの消去、バックアップの作成とダウンロード、設定プロファイルのインポートとエクスポート、テーマとエージェントのインストール、Local Modelランタイムのインストールです。これらには、上で選んだアクセス方法とは別に、管理者用シークレットと呼ばれる共有の秘密の文字列が必要です。

ループバックのコンピューターでは、管理者用シークレットなしでもたいてい実行できます。リモートのデバイスから行う場合は、シークレットを設定する必要があります。シークレットはアプリで作ることも、.envで設定することもできます。

ホーム画面にあるものなど、インストール済みのエージェントには管理者用シークレットは要りません。ログインでサインインしたデバイスなら使えます。ただし、エージェントのインストール、アップデート、削除には引き続きシークレットが必要です。

アプリで管理者用シークレットを作る

  1. Marinaraを動かしているコンピューターでSettings(設定)を開き、Advanced(詳細設定)タブ、さらにAdmin Access(管理者アクセス)セクションへ進みます。
  2. Make admin secret(管理者用シークレットを作成)をクリックします。Marinaraは新しいシークレットを一度だけ表示し、このブラウザーに保存します。
  3. 各リモートのデバイスでSettings → Advanced → Admin Accessを開き、入力欄にシークレットを入力してSave(保存)をクリックします。大文字小文字、スペース、ダッシュは区別されません。

すでにシークレットを持っているデバイスからも作れます。ログインでサインインしているだけのデバイスからは作れません。これにより、盗まれたサインインでリスクのある操作が乗っ取られるのを防ぎます。

Dockerでは、ブラウザーはDockerのネットワークを通してMarinaraにアクセスするため、Marinaraはそれを同じコンピューターとして扱いません。最初のシークレットは、代わりに.envで設定してください(後述)。

シークレットを変更するには、Replace admin secret(管理者用シークレットを置き換え)をクリックします。古いシークレットは、すべてのデバイスで使えなくなります。オフにするには、Remove admin secret(管理者用シークレットを削除)をクリックします。Marinaraが保持するのはシークレットのフィンガープリントだけで、データフォルダー内の.admin-secret.jsonに保存されます。このファイルを削除することでも、シークレットを削除できます。

.envで管理者用シークレットを設定する

  1. .envに強力なランダムの値を設定して保存します。数秒で反映され、再起動は要りません。
ADMIN_SECRET=some-long-random-string
  1. リモートのデバイスでSettings(設定) → Advanced(詳細設定) → Admin Access(管理者アクセス)を開きます。
  2. 同じ値を入力欄(プレースホルダーはADMIN_SECRET)に貼り付け、Saveをクリックします。
  3. Admin secret saved for this browserというメッセージが表示されるはずです。

.envのADMIN_SECRETは、アプリで作ったシークレットより優先されます。設定されているあいだはAdmin Accessにその旨が表示され、シークレットは.envでしか変更できません。

知っておきたいこと

リモートのデバイスで特権が必要な操作に失敗すると、Marinaraは対処法を2つ添えたエラーメッセージを表示します。1つはlocalhost経由でアプリを開く方法、もう1つは上で説明したとおりに管理者用シークレットを設定する方法です。

保存が遮断されるのはなぜですか(CSRF)

CSRFはcross-site request forgery(クロスサイトリクエストフォージェリ)の略です。同時に開いている別のWebサイトが、許可なく勝手にMarinaraの内容を書き換えるのを防ぐ仕組みです。自動で働くため、オンにするための設定はありません。

自分の保存操作がCSRFで遮断されることもあります。多くは、サーバーがまだ信頼していない公開ドメイン名や、通常とは異なるポート番号でMarinaraに接続したときに起こります。そのときは2つの形で知らせます。

これを解消するには、接続に使っているアドレスを.envの信頼リストに追加します。

CSRF_TRUSTED_ORIGINS=https://chat.example.com,http://203.0.113.10:7831

公開ドメインやリバースプロキシのドメインを使う場合は、ホスト名も許可します。

TRUSTED_HOSTS=chat.example.com

LAN、Tailscale、IPv4、IPv6のアドレスに直接つなぐ場合、TRUSTED_HOSTSは必要ありません。ローカルの.local/.home.arpaという名前や、ドットを含まないコンピューター名は自動的に受け付けます。CSRF_TRUSTED_ORIGINSにすでに載っているホスト名も、そのまま受け付けます。

ループバック、通常のLANのアドレス、Tailscale(100.64.0.0/10)、Dockerブリッジ(172.16.0.0/12)のオリジンは自動的に信頼します。書き出す必要があるのは、公開されたIPアドレスとドメイン名だけです。変更は数秒で反映され、再起動は要りません。

ローカルのプロバイダーが遮断される場合について

Marinaraを、たとえば自分のコンピューターで動かしているローカルのAIプロバイダーに接続したとします。このとき「private, loopback, metadata, or reserved IP range」というメッセージとともにリクエストが拒否されることがあります。これはSSRF保護と呼ばれる別の安全機能です。SSRFはserver-side request forgery(サーバーサイドリクエストフォージェリ)の略で、許可しない限りサーバーがプライベートなアドレスを呼び出さないようにします。エラーにはPROVIDER_LOCAL_URLS_ENABLEDのように、設定すべき.envの変数名がそのまま示されます。全一覧はサーバー設定リファレンスを参照してください。

スマートフォンやタブレットからのアクセス

同じネットワークにあるスマートフォンやタブレットからMarinaraを開く手順は次のとおりです。

  1. .envにHOST=0.0.0.0を設定し、サーバーがすべてのインターフェイスで待ち受けているか確かめます。
  2. ログインを設定します(上記の方法1)。スマートフォンからは、遮断されているページで、サーバーのログにあるセットアップコードを使って設定することもできます。
  3. サーバーを動かしているコンピューターのローカルIPアドレス(たとえば192.168.1.50)を調べます。
  4. スマートフォンのブラウザーでhttp://192.168.1.50:7860を開きます。デフォルトのポート番号は7860です。
  5. ユーザー名とパスワードでサインインします。

ページがまったく開かない場合は、サーバーに届いていない可能性があります。HOST=0.0.0.0とPORTの値を確認してください。403が返る場合は、サーバーには届いているものの、まだ許可されていない状態です。選んだ方法の設定をもう一度見直してください。

アップデート後にログインできなくなった場合

新しいバージョンでは、リバースプロキシ、トンネル、Tailscale Serve、Tailscale Funnel経由のアクセスにログインを求めます。古いバージョンでは、こうしたアクセスをパスワードなしで通していました。ログインページ、セットアップページ、または403が表示される場合は、これが理由です。

アップデートに関する注意: Tailscale Serveや、同じコンピューター上のほかのプロキシを使っていて、パスワードを一度も設定していない場合、アップデート後はほかのデバイスから入れなくなります。同じコンピューター上のプロキシは、ふつうループバックだけで待ち受けるサーバーに接続するため、サーバーはセットアップコードを出力しません。代わりに、Marinaraを動かしているコンピューターでログインを設定してください。

再び入るには:

  1. Marinaraを実行しているコンピューターで、http://localhost:7860(または自分で設定したPORT)を開きます。ローカルでの利用にパスワードは不要です。ヘッドレスサーバーでは、まず自分のコンピューターでssh -L 7860:127.0.0.1:7860 user@serverを実行し、そこでhttp://localhost:7860を開きます。Dockerでこれが当てはまるのは、ログインもIP_ALLOWLISTも設定していないあいだだけです。そうでない場合は、サーバーのログにあるセットアップコード(docker logs <container> 2>&1 | grep "setup code")を、遮断されているページで入力するか、Settings → Advanced → Accessで入力するか、まだサインインしているブラウザーを使ってください。
  2. Settings → Advanced → Accessを開き、Remote loginの下でユーザー名とパスワードを設定します。または、そのコンピューターで.envファイルを開き、BASIC_AUTH_USERとBASIC_AUTH_PASSを設定します。IP_ALLOWLISTを設定している場合は、別のデバイスのアドレスを追加するか、設定を削除してください。リストにないデバイスは、ログインしても403になります。
  3. 別のデバイスから、そのユーザー名とパスワードでサインインします。

検索エンジン

Marinaraは、検索エンジンにページのインデックス登録をしないよう求めます(X-Robots-Tag: noindex, nofollow)。これはお使いのインストールを保護するものではなく、すでにインデックス登録されたページを削除するものでもありません。インストールを非公開に保つには、上記のアクセス制御を使用してください。

関連ガイド