Tailscale または WireGuard を介したリモート Ollama アクセス、公開ポートなし

公開ポートを使用せずに Ollama にリモートアクセスする

目次

Ollama は、ローカルデーモンとして扱われるときに最も安定した状態になります。CLI とアプリケーションがループバック HTTP API と通信し、ネットワークの残りはその存在に気づかない状態です。

デフォルトでは、まさにそのようになります。一般的なローカルベースアドレスは localhost の 11434 ポートです。

ollama remote access

この記事は、リモートアクセス（ラップトップ、別のオフィス機器、あるいはスマートフォンなど）が必要になった瞬間についてです。しかし、認証なしのモデルランナーをインターネット全体に公開したくないという状況です。その意図は重要です。なぜなら、最も簡単なスケーリング手法（ポートを開けて転送するだけ）が、結果的に混乱を招く選択にもなるからです。

実践的な指針は単純です。Ollama API をプライベートに保ち、プライベートなネットワーク経路を退屈な（変化の少ない）ものにします。Tailscale と WireGuard はそのための一般的な方法の 2 つです。残りは、ホストが適切な場所でのみリッスンし、ファイアウォールがそれを許可するようにすることです。

Remote device
  |
  | (private VPN path: tailscale or wireguard)
  v
VPN interface on host (tailscale0 or wg0)
  |
  | (local hop)
  v
Ollama server (HTTP API on localhost or VPN IP)

脅威モデルと API へのアクセス権限

Ollama を公開インターネットに露出することなくリモートからアクセスするにはどうすればよいでしょうか。答えは特定のツールよりも、「誰が接続することを許可するか」「どこから接続することを許可するか」を明確にすることにあります。

役立つメンタルモデルは、3 つの同心円として考えることです。

  • ローカルのみ：ボックス上のプロセスだけが API を呼び出せます。
  • LAN のみ：同じローカルネットワーク上のデバイスだけが API を呼び出せます。
  • VPN のみ：プライベートオーバーレイネットワーク上の選択されたデバイスとユーザーだけが API を呼び出せます。

最初のリングがデフォルトです。多くのガイド（Postman などのツールも）は、ベース URL が localhost 11434 であると想定しており、これは利便性が高く、驚くほど強力な安全境界線でもあります。

リングが重要な理由は、Ollama がローカル HTTP API に対して組み込みの認証を持たないことがよく説明されているためです。つまり、localhost を超えて移動する場合、ネットワーク露出とアクセス制御はあなた自身の責任になります。

もう一つの理由はコストと悪用です。「プライベート」な LLM エンドポイントであっても、それは依然として API エンドポイントです。OWASP API Security Top 10 は、セキュリティ設定ミスやリソース消費の制限なしといったカテゴリを指摘しています。モデルランナーは、カジュアルに露出された場合、「リソース消費」の典型例と言えます。

したがって、基本的な脅威モデルは「攻撃者が私のデータを読む」だけではありません。「誰かが私の CPU と GPU をレンタカーのように駆る」こと、「意図しないユーザーが発見し、それを基に構築し始める」ことも含まれます。

OLLAMA_HOST とバインドのセマンティクス（90 秒解説）

OLLAMA_HOST は何をするもので、最も安全なデフォルト値は何でしょうか。OLLAMA_HOST は、Ollama サーバーがどこでリッスンするかを制御するスイッチです。ollama serve では、この環境変数はサーバーの IP アドレスとポートとして説明されており、デフォルトは 127.0.0.1 とポート 11434 です。

平たく言うと、バインドアドレスはどのネットワークが TCP 接続を試みるかを決めます。

  • 127.0.0.1 は localhost のみを意味します。
  • LAN IP（192.168.x.y など）は、LAN からアクセス可能であることを意味します。
  • 0.0.0.0 は、ファイアウォールがブロックしない限り、すべてのインターフェース（LAN、VPN、すべて）からアクセス可能であることを意味します。

そのため、多くの「アクセス可能にする」ハウツーでは、127.0.0.1 から 0.0.0.0 への切り替えを提案していますが、インターフェースを意識したファイアウォールなしではこの助言は不完全です。

私が頭の中で持っているチートシートは以下の通りです。

# Local only (baseline)
export OLLAMA_HOST=127.0.0.1:11434

# All interfaces (powerful, easy to regret)
export OLLAMA_HOST=0.0.0.0:11434

# VPN interface only (preferred when the VPN has a stable IP on the host)
export OLLAMA_HOST=100.64.0.10:11434   # example tailscale IP
export OLLAMA_HOST=10.10.10.1:11434    # example wireguard IP

# Different port (useful when 11434 is already taken)
export OLLAMA_HOST=127.0.0.1:11435

「異なるポート」のケースは、OLLAMA_HOST を使用してリッスンポートを変更する例として、Ollama のイシュートラッカーで明確に議論されています。

人々を悩ませる運用上の注記があります。Ollama が管理サービスとして実行されている場合、インタラクティブシェルで環境変数を設定しても、サービス設定が必ずしも変更されるわけではありません。そのため、多くの「ターミナルでは動いたが、再起動後は動かない」という物語は、systemd ユニットの上書きやサービスマネージャの設定へと収束します。

パターン A：Tailscale を使った VPN 優先

Tailscale はアクセスをマシンの特定のサービスポートに制限できますか？はい、それが Tailscale が「公開せずにリモートアクセス」に適している大きな理由です。

Tailscale は、中央で管理されたアクセス制御（ACL）を持つプライベートネットワーク（tailnet）を提供します。ACL は、デバイスの権限を管理し、ネットワークをセキュリティ化するために存在します。

公開ポートがないため、ルーターの振興が不要

最もクリーンなパターンは、Ollama 向けのインターネットに面したポートを一切開けず、VPN だけをイングリッジ（入口）として扱うことです。Tailscale では、デバイスが可能な限りピアツーピアで直接接続しようとし、直接接続ができない場合はリレー機構にフォールバックします。

これ自体が魔法のようなセキュリティではありませんが、「ルーターで 11434 ポートを転送した」場合と比較して、被害範囲（ブラストレディウス）を劇的に縮小します。

分割ホライズンと MagicDNS によるネーミング

現実でよく出る 2 つ目の質問は、「自宅では LAN IP で接続し、外出先では VPN IP で接続するか」というものです。これは基本的に分割ホライズンの問題です。

Tailscale MagicDNS は、各デバイスに安定した tailnet ホスト名を与えることでこれを助けます。裏側では、MagicDNS はマシン名と tailnet DNS 名を組み合わせた FQDN を各デバイスに生成し、最新の tailnet 名は .ts.net で終わります。

意見としては、名前は IP をハードコードするよりも通常は良い選択です。なぜなら、tailnet IP が変更されても名前はデバイスに付随するからです。ただし、意図的にシンプルさを好み、小さい hosts ファイルや単一の内部 DNS レコードを維持するのでも問題ありません。MagicDNS は、あなたがそれをしなくても済むように存在します。

直接ポートアクセスと tailnet 専用プロキシング

サービスに到達するための一般的な Tailscale の方法は 2 つあります。

  • 直接ポートアクセス：サービスが tailnet インターフェースでリッスンし、クライアントはその IP とポートに接続します。
  • Tailscale Serve：Tailscale が、他の tailnet デバイスからのトラフィックをホスト上のローカルサービスへルーティングします。

Serve は、Ollama を localhost に保ちつつ、Tailscale を通じて制御されたイングリッジ経路のみを公開できるため魅力的です。また、ブラウザフレンドリーなエンドポイントを望む場合、tailnet 内で HTTPS と自然にペアリングできます。

ここで名前を挙げ、心のどこかに棚卸ししておくべき関連機能に Funnel があります。Funnel は、より広いインターネットからのトラフィックを tailnet デバイスのサービスへルーティングするように設計されており、「Tailscale を使用しない人々でもアクセスできる」ことを明確に意図しています。これはこの記事の目的とは逆です。

パターン B：WireGuard（生きたプリミティブを求める方へ）

WireGuard は多くの VPN 製品を裏で支えるプリミティブであり、あえて最小限に設計されています。インターフェースを設定し、ピアを定義し、どのトラフィックが流れを許可するかを決定します。

WireGuard のクイックスタートは基本的な形を示しています。wg0 のようなインターフェースを作成し、IP を割り当て、wg でピアを設定します。

アクセス範囲を制限するための鍵となる概念は AllowedIPs です。Red Hat のドキュメントによると、WireGuard はパケットから宛先 IP を読み取り、許可された IP アドレスのリストと比較します。ピアが見つからない場合、WireGuard はパケットをドロップします。

Ollama ホストにとっての実践的な意味は以下の通りです。

  • ホストをプライベートな WireGuard サブネットに配置します。
  • Ollama を localhost にバインドして転送するか、または WireGuard IP に直接バインドします。
  • 正しいキーと AllowedIPs を持つピアのみが、そのプライベート IP へのトラフィックをルーティングできます。

これは商用のオーバーレイよりも移動部品が少ないですが、同時に鍵の配布、ピアのライフサイクル、リモートピアがあなたのネットワークに到達する方法の責任はあなたにあることを意味します。

ファイアウォールで VPN インターフェースまたは tailnet へのアクセスのみ許可

ファイアウォールが Ollama を VPN インターフェースのトラフィックにのみ制限するにはどうすればよいでしょうか。目標は、バインドアドレスが意図よりも広くなった場合でも、誤った露出を防ぐことです。

一般的なパターンは以下の通りです。

  • Ollama TCP ポートを、VPN インターフェース（tailscale0 または wg0）でのみ許可します。
  • 他のすべてのインターフェースで同じポートを拒否します。
  • ホストの運用方針として「デフォルトで入力を拒否」を優先します。

Tailscale には、UFW を使用してサーバーへの非 Tailscale トラフィックを制限する明確なガイダンスがあり、これは本質的に「tailnet 以外をすべてロックダウンする」アプローチです。

Tailscale 特有の重要なニュアンスがあります。UFW が tailnet トラフィックをブロックすると仮定した場合、ホストファイアウォールの期待値が現実と一致しない可能性があります。Tailscale プロジェクトは、tailscale0 のトラフィックを許可するルールを意図的にインストールし、tailscaled 内の ACL 制御フィルターに依存すると議論しています。

これはホストファイアウォールに反対する議論ではありません。実際にはどのコントロールプレーンがポリシーを強制しているかを意図的にすることの議論です。「これらのデバイスだけがポート 11434 に到達できる」なら、Tailscale ACL はそのために設計されています。

それでもインターフェースレベルのホスト制御を望む場合、例は次のようになります。

# UFW style logic (illustrative)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Or for wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

VPN ポリシーに主に依存する場合でも、ホストファイアウォールは、0.0.0.0 への誤ったバインドや予期せぬサービスラッパーに対する有用な「シートベルト」として機能します。

オプション：VPN イングリッジでのみリバースプロキシ

リモート Ollama アクセスにリバースプロキシが役立つのはいつでしょうか。プロキシは、以下のプロパティの 1 つ以上を望む場合に役立ちます。

  • 標準的な認証ゲート（基本認証、OIDC、クライアント証明書）。
  • クライアントが信頼する証明書を使用した TLS 終端。
  • リクエスト制限とタイムアウト。
  • 生のポートを嫌うツール向けのクリーンな URL。

ここで、「インターネットに公開しない」という意図は依然として真実でなければなりません。リバースプロキシは VPN 経由でのみ到達可能で、公開 WAN インターフェース上にはありません。

トラフィックがすでに VPN を通っている場合、TLS は必要でしょうか？暗号化の観点からは常に必要ではありませんが、使いやすさの観点からはしばしば必要です。Tailscale は、ノード間の接続はすでにエンドツーエンドで暗号化されていると指摘していますが、ブラウザは TLS 証明書を使用して HTTPS の信頼を確立するため、その事実を認識していません。

Tailscale の世界にいる場合、tailnet に対して HTTPS 証明書を使用可能にできます。これには MagicDNS が必要で、マシン名と tailnet DNS 名が公開元帳（証明書透明性ログ）に公開されることを明確に示しています。

その公開元帳の詳細は、TLS を避ける理由ではありませんが、マシンの命名には大人らしさを持つ理由です（ホスト名にプライベートプロジェクト名や顧客識別子を埋め込まないようにする）。

この記事は意図的に完全なリバースプロキシ構成を含んでいません（そのためには A1 記事をご覧ください）。ここで重要なのは配置のみです。

  • Ollama は localhost または VPN IP でリッスンします。
  • リバースプロキシは VPN インターフェースでのみリッスンします。
  • プロキシは Ollama へ転送します。

リモート Ollama API アクセスのためのセキュリティチェックリスト

これは、「リモート」が静かに「公開」にならないようにするために私が使用しているチェックリストです。

バインドと到達可能性

  • サーバーが思い通りにリッスンしていることを確認します。ドキュメントのデフォルトは 127.0.0.1 とポート 11434 で、OLLAMA_HOST がそれを変更します。
  • 0.0.0.0 を利便性のためのトグルではなく、意図的な選択として扱います。
  • 安定しておりトポロジーに適している場合は、VPN インターフェース IP へのバインドを優先します。

アクセス制御

  • Tailscale を使用している場合、Ollama ポートへのアクセスを特定のユーザーまたはタグ付きデバイスのみに許可する ACL を実装します。ACL はデバイス権限を管理するために存在します。
  • WireGuard を使用している場合、AllowedIPs を厳密に保ち、キーを実際のアイデンティティの境界として扱います。WireGuard は有効なピア AllowedIPs マッピングに一致しないパケットをドロップします。

ファイアウォール

  • tailscale0 または wg0 でのみ Ollama ポートを許可し、他のすべてでブロックするホストレベルのルールを追加します。
  • UFW が tailnet トラフィックをブロックすると期待している場合、Tailscale がファイアウォールとどのように相互作用するかを確認します。Tailscale は tailscale0 トラフィックを許可し、tailscaled 内の ACL フィルターに依存すると議論しています。

TLS とプロキシング

  • クライアントがブラウザである場合、またはツールが HTTPS を期待する場合、VPN がすでにトランスポートを暗号化していても TLS を使用します。Tailscale は、VPN 暗号化とブラウザ HTTPS 信頼の間のこのギャップを文書化しています。
  • Tailscale HTTPS 証明書を有効にする場合、ホスト名の証明書透明性への影響を思い出してください。
  • リバースプロキシを追加する場合、VPN のみに保ち、インターネットへの露出ではなく認証と制限のために使用します。

意図しない公開露出の回避

  • サービスをインターネットに公開するように明示的に設計された機能に警戒します。Tailscale Funnel は、より広いインターネットからのトラフィックを tailnet デバイスへルーティングしますが、これは Ollama API にとってデフォルトで安全なパスではありません。
  • 何かがインターネットから到達可能になった場合、匿名の /api サーフェスを残さないでください。その時点で、OWASP API の「セキュリティ設定ミス」と「リソース消費」のリスクカテゴリは理論的なものではなくなります。

可視性と被害制御

  • 入層（VPN ポリシーログ、プロキシログ、またはその両方）でリクエストをログ記録します。
  • プロキシがサポートしている場合、リクエストと並行処理の制限を追加します。モデル推論は通常の API 呼び出しではなく、リソースイベントだからです。

一貫したテーマは、あえて退屈であることです。Ollama API をデフォルトでプライベートに保ち、リモートアクセスのためのプライベートパスを追加し、次にそのポリシーを 2 回強制します（VPN アイデンティティ plus ホストファイアウォール）。これにより、単一のミスステップが公開エンドポイントになることを防ぎます。