Accès distant à Ollama via Tailscale ou WireGuard, sans ports publics.

Accès distant à Ollama sans ports publics

Sommaire

Ollama est à son meilleur lorsque l’on le traite comme un démon local : la CLI et vos applications communiquent avec une API HTTP en boucle locale (loopback), et le reste du réseau ignore son existence.

Par défaut, c’est exactement ce qui se passe : l’adresse de base locale commune se trouve sur localhost au port 11434.

ollama remote access

Cet article traite du moment où vous souhaitez un accès distant (ordinateur portable, autre machine de bureau, peut-être un téléphone), mais où vous ne souhaitez pas publier un exécuteur de modèle non authentifié sur l’ensemble d’Internet. Cette intention est cruciale, car la méthode de mise à l’échelle la plus simple (ouvrir un port, le rediriger, et c’est fini) est aussi celle qui crée le plus de désordre.

Une boussole pratique est simple : gardez l’API Ollama privée, puis rendez le chemin du réseau privé ennuyeux. Tailscale et WireGuard sont deux méthodes courantes pour y parvenir, et le reste consiste à s’assurer que l’hôte écoute uniquement là où il le doit et que le pare-feu est d’accord.

Appareil distant
  |
  | (chemin VPN privé : tailscale ou wireguard)
  v
Interface VPN sur l'hôte (tailscale0 ou wg0)
  |
  | (saut local)
  v
Serveur Ollama (API HTTP sur localhost ou IP VPN)

Pour comprendre comment Ollama s’intègre aux côtés de vLLM, Docker Model Runner, LocalAI et les compromis d’hébergement cloud, consultez Hébergement LLM en 2026 : Comparaison des infrastructures locales, auto-hébergées et cloud.

Guides connexes :

Modèle de menace et qui doit accéder à l’API

Comment accéder à Ollama à distance sans l’exposer à Internet public ? La réponse repose moins sur un outil spécifique que sur l’explicite de “qui est autorisé à se connecter” et “d’où”.

Un modèle mental utile consiste en trois cercles concentriques :

  • Local uniquement : seules les processus sur la machine peuvent appeler l’API.
  • LAN uniquement : les appareils du même réseau local peuvent appeler l’API.
  • VPN uniquement : les appareils et utilisateurs sélectionnés sur un réseau de superposition privé peuvent appeler l’API.

Le premier cercle est la valeur par défaut. De nombreux guides (et des outils comme Postman) supposent que l’URL de base est localhost 11434, ce qui est à la fois pratique et constitue une frontière de sécurité surprenante.

La raison pour laquelle les cercles importent est qu’Ollama est communément décrit comme n’ayant pas d’authentification intégrée pour son API HTTP locale, ce qui signifie que l’exposition réseau et le contrôle d’accès deviennent votre responsabilité si vous dépassez le localhost.

L’autre raison est le coût et l’abus : même une extrémité LLM “privée” reste une extrémité d’API. Le Top 10 de la sécurité API OWASP met en évidence des catégories comme la mauvaise configuration de sécurité et la consommation de ressources illimitée ; un exécuteur de modèle est pratiquement l’archétype de la “consommation de ressources” s’il est exposé négligemment.

Ainsi, le modèle de menace de base n’est pas seulement “un attaquant lit mes données”. C’est aussi “quelqu’un peut conduire mon CPU et ma GPU comme une voiture de location” et “des utilisateurs non intentionnels le découvrent et commencent à construire dessus”.

Sémantique de liaison OLLAMA_HOST en 90 secondes

Que fait OLLAMA_HOST et quelle est la valeur par défaut la plus sûre ? OLLAMA_HOST est l’interrupteur qui contrôle où le serveur Ollama écoute. Dans ollama serve, la variable d’environnement est décrite comme l’adresse IP et le port du serveur, avec une valeur par défaut de 127.0.0.1 et le port 11434.

En termes simples, l’adresse de liaison décide quels réseaux peuvent même tenter une connexion TCP :

  • 127.0.0.1 signifie localhost uniquement.
  • Une IP LAN (comme 192.168.x.y) signifie que le LAN peut l’atteindre.
  • 0.0.0.0 signifie toutes les interfaces (LAN, VPN, tout) peuvent l’atteindre à moins qu’un pare-feu ne les bloque.

C’est pourquoi la plupart des tutoriels “le rendre accessible” suggèrent de passer de 127.0.0.1 à 0.0.0.0, mais ce conseil est incomplet sans un pare-feu conscient des interfaces.

Voici le mémo que je garde en tête :

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

# Toutes les interfaces (puissant, facile à regretter)
export OLLAMA_HOST=0.0.0.0:11434

# Interface VPN uniquement (préféré lorsque le VPN a une IP stable sur l'hôte)
export OLLAMA_HOST=100.64.0.10:11434   # exemple d'IP tailscale
export OLLAMA_HOST=10.10.10.1:11434    # exemple d'IP wireguard

# Port différent (utile lorsque 11434 est déjà occupé)
export OLLAMA_HOST=127.0.0.1:11435

Le cas “port différent” est explicitement discuté dans le suivi des problèmes Ollama comme exemple d’utilisation d’OLLAMA_HOST pour modifier le port d’écoute.

Une note opérationnelle qui mord : si Ollama s’exécute en tant que service géré, définir des variables d’environnement dans un shell interactif ne modifie pas nécessairement la configuration du service. C’est pourquoi de nombreuses histoires “ça marchait dans mon terminal mais pas après le redémarrage” se terminent par des overrides d’unités systemd ou une configuration de gestionnaire de service.

Modèle A : VPN d’abord avec Tailscale

Tailscale peut-il restreindre l’accès à un seul port de service sur une machine ? Oui, et c’est une grande partie de la raison pour laquelle Tailscale est bien adapté à “l’accès distant sans publication”.

Tailscale vous offre un réseau privé (un tailnet) avec des contrôles d’accès gérés centralement (ACL). Les ACL existent spécifiquement pour gérer les permissions des appareils et sécuriser le réseau.

Aucun port public signifie pas de chorégraphie de routeur

Le modèle le plus propre consiste à éviter d’ouvrir quel que soit le port orienté Internet pour Ollama et traiter le VPN comme la seule entrée. Avec Tailscale, les appareils tentent de se connecter directement pair-à-pair lorsque c’est possible, et peuvent basculer vers des mécanismes de relais lorsque la connectivité directe n’est pas possible.

Ce n’est pas une sécurité magique en soi, mais cela réduit radicalement le rayon d’explosion par rapport à “j’ai redirigé 11434 sur mon routeur”.

Horizon divisé et nommage avec MagicDNS

Une deuxième question qui apparaît dans la réalité est “est-ce que je me connecte via l’IP LAN quand je suis à la maison et via l’IP VPN quand je suis absent”. C’est essentiellement un problème d’horizon divisé.

Tailscale MagicDNS aide en donnant à chaque appareil un nom d’hôte tailnet stable. Sous le capot, MagicDNS génère un FQDN pour chaque appareil qui combine le nom de la machine et votre nom DNS tailnet, et les noms de tailnet modernes se terminent par .ts.net.

L’avis tranché est que l’utilisation d’un nom est généralement meilleure que le codage d’une IP en dur, car le nom suit l’appareil même si votre IP tailnet change. Mais il est également tout à fait acceptable d’être intentionnellement ennuyeux et de conserver un petit fichier hôtes ou un seul enregistrement DNS interne si vous préférez. MagicDNS existe pour que vous n’ayez pas à le faire.

Port direct versus proxying tailnet-only

Il existe deux façons courantes de Tailscale pour atteindre un service :

  • Accès direct au port, où le service écoute sur l’interface tailnet et les clients se connectent à cette IP et ce port.
  • Tailscale Serve, où Tailscale achemine le trafic d’autres appareils tailnet vers un service local sur l’hôte.

Serve est explicitement décrit comme l’acheminement du trafic d’autres appareils tailnet vers un service local exécuté sur votre appareil.

Pour Ollama, Serve peut être attrayant car il vous permet de garder Ollama sur localhost et d’exposer uniquement un chemin d’entrée contrôlé via Tailscale. Il s’associe également naturellement avec HTTPS à l’intérieur du tailnet si vous souhaitez des extrémités conviviales pour les navigateurs.

Une fonctionnalité connexe à nommer puis à ranger mentalement est Funnel. Funnel est conçu pour acheminer le trafic du reste d’Internet vers un service sur un appareil tailnet et est explicitement destiné à “n’importe qui peut accéder même s’ils n’utilisent pas Tailscale”. C’est le contraire de cet article.

Modèle B : WireGuard pour ceux qui veulent les primitives brutes

WireGuard est la primitive sous-jacente qui alimente de nombreux produits VPN, et il est délibérément minimal : vous configurez une interface, définissez des pairs et décidez quel trafic est autorisé de circuler.

Le démarrage rapide WireGuard montre la forme de base : créer une interface telle que wg0, attribuer des IP et configurer des pairs avec wg.

Le concept clé pour limiter l’accès est AllowedIPs. Dans la documentation Red Hat, WireGuard lit l’IP de destination d’un paquet et la compare à la liste des adresses IP autorisées ; si le pair n’est pas trouvé, WireGuard rejette le paquet.

Pour un hôte Ollama, la traduction pratique est :

  • Mettez l’hôte sur un sous-réseau WireGuard privé.
  • Liez Ollama soit au localhost et redirigez vers lui, soit liez directement à l’IP WireGuard.
  • Seuls les pairs qui possèdent les clés correctes et AllowedIPs peuvent acheminer le trafic vers cette IP privée.

C’est moins de pièces mobiles qu’un overlay commercial, mais cela signifie aussi que vous êtes responsable de la distribution des clés, du cycle de vie des pairs et de la façon dont les pairs distants atteignent votre réseau.

Pare-feu : autoriser uniquement l’interface VPN ou tailnet

Comment un pare-feu peut-il limiter Ollama au trafic de l’interface VPN uniquement ? L’objectif est d’empêcher une exposition accidentelle même si l’adresse de liaison devient plus large que prévu.

Le modèle général est :

  • Autoriser le port TCP Ollama uniquement sur l’interface VPN (tailscale0 ou wg0).
  • Interdire le même port partout ailleurs.
  • Préférez “refuser l’entrée par défaut” si vous opérez de cette manière pour l’hôte.

Tailscale a des conseils explicites sur l’utilisation de UFW pour restreindre le trafic non-Tailscale vers un serveur, ce qui est essentiellement l’approche “verrouiller tout sauf le tailnet”.

Une nuance qui compte spécifiquement pour Tailscale est que les attentes du pare-feu de l’hôte peuvent ne pas correspondre à la réalité si vous supposez que UFW bloquera le trafic tailnet. Le projet Tailscale a discuté du fait qu’il installe intentionnellement une règle pour autoriser le trafic sur tailscale0 et s’appuie sur un filtre contrôlé par ACL à l’intérieur de tailscaled.

Ce n’est pas un argument contre un pare-feu d’hôte. C’est un argument pour être délibéré sur quel plan de contrôle applique réellement la politique. Si vous voulez “seuls ces appareils peuvent atteindre le port 11434”, les ACL Tailscale sont conçues pour cela.

Si vous voulez quand même des contrôles d’hôte au niveau de l’interface, les exemples ressemblent généralement à ceci :

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

# Ou pour wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Même si vous vous fiez principalement à la politique VPN, le pare-feu d’hôte fournit toujours une “ceinture de sécurité” utile contre une liaison accidentelle à 0.0.0.0 ou des enveloppes de service inattendues.

Proxy inverse optionnel uniquement sur l’entrée VPN

Quand est-ce qu’un proxy inverse est utile pour l’accès distant à Ollama ? Un proxy est utile lorsque vous souhaitez une ou plusieurs de ces propriétés :

  • Une passerelle d’authentification standard (authentification de base, OIDC, certificats clients).
  • Terminaison TLS avec un certificat que les clients font confiance.
  • Limites de requêtes et temporisations.
  • URL plus propres pour les outils qui n’aiment pas les ports bruts.

C’est là que l’intention “ne pas publier sur Internet” doit rester vraie : le proxy inverse n’est accessible que via le VPN, pas sur l’interface WAN publique.

Le TLS est-il nécessaire lorsque le trafic passe déjà par un VPN ? Pas toujours pour la cryptographie, mais souvent pour l’ergonomie. Tailscale souligne que les connexions entre nœuds sont déjà chiffrées de bout en bout, mais les navigateurs n’en sont pas conscients car ils s’appuient sur des certificats TLS pour établir la confiance HTTPS.

Si vous êtes dans le monde Tailscale, vous pouvez activer des certificats HTTPS pour votre tailnet, ce qui nécessite MagicDNS et note explicitement que les noms de machines et le nom DNS tailnet seront publiés sur un registre public (journaux de transparence des certificats).

Ce détail de registre public n’est pas une raison pour éviter le TLS, mais c’est une raison pour nommer les machines comme un adulte (éviter d’intégrer des noms de projets privés ou des identifiants de clients dans les noms d’hôte).

Cet article n’inclut intentionnellement pas de configuration de proxy inverse complète ; pour Caddy ou Nginx, le streaming et l’authentification à la périphérie, consultez Ollama derrière un proxy inverse avec Caddy ou Nginx pour le streaming HTTPS. L’idée qui compte ici est le placement :

  • Ollama écoute sur localhost ou l’IP VPN.
  • Le proxy inverse écoute uniquement sur l’interface VPN.
  • Le proxy redirige vers Ollama.

Liste de contrôle de sécurité pour l’accès distant à l’API Ollama

Voici la liste de contrôle que j’utilise pour empêcher “distant” de devenir silencieusement “public”.

Liaison et accessibilité

  • Confirmez que le serveur écoute là où vous pensez qu’il écoute. La valeur par défaut documentée est 127.0.0.1 et le port 11434, et OLLAMA_HOST modifie cela.
  • Traitez 0.0.0.0 comme un choix délibéré, pas comme un interrupteur de commodité.
  • Préférez la liaison à une IP d’interface VPN lorsqu’elle est stable et correspond à la topologie.

Contrôle d’accès

  • Si vous utilisez Tailscale, implémentez des ACL qui n’autorisent que les utilisateurs spécifiques ou les appareils étiquetés vers le port Ollama. Les ACL existent pour gérer les permissions des appareils.
  • Si vous utilisez WireGuard, gardez AllowedIPs serrés et traitez les clés comme la véritable frontière d’identité. WireGuard rejette les paquets qui ne correspondent pas à une cartographie AllowedIPs valide pour un pair.

Pare-feu

  • Ajoutez une règle au niveau de l’hôte qui autorise le port Ollama uniquement sur tailscale0 ou wg0 et le bloque partout ailleurs.
  • Si vous attendez que UFW bloque le trafic tailnet, vérifiez comment Tailscale interagit avec votre pare-feu. Tailscale a discuté de l’autorisation du trafic tailscale0 et de la dépendance au filtrage ACL à l’intérieur de tailscaled.

TLS et proxying

  • Utilisez le TLS lorsque les clients sont des navigateurs ou lorsque les outils s’attendent à HTTPS, même si le VPN chiffre déjà le transport. Tailscale documente cet écart entre le chiffrement VPN et la confiance HTTPS du navigateur.
  • Si vous activez des certificats HTTPS Tailscale, rappelez-vous l’implication de transparence des certificats pour les noms d’hôte.
  • Si vous ajoutez un proxy inverse, gardez-le uniquement sur le VPN et utilisez-le pour l’authentification et les limites, pas pour l’exposition Internet.

Évitez une exposition publique accidentelle

  • Soyez méfiant envers les fonctionnalités conçues explicitement pour publier des services sur Internet. Tailscale Funnel achemine le trafic du reste d’Internet vers un appareil tailnet, ce qui n’est pas le chemin par défaut sécurisé pour une API Ollama.
  • Si quelque finit par être accessible sur Internet, ne laissez pas une surface /api anonyme. À ce stade, les catégories de risques OWASP API “mauvaise configuration de sécurité” et “consommation de ressources” cessent d’être théoriques.

Observabilité et contrôle des dégâts

  • Journalisez les requêtes au niveau d’entrée (journaux de politique VPN, journaux de proxy, ou les deux).
  • Ajoutez des limites de requêtes et de concurrence si votre proxy les prend en charge, car l’inférence de modèle est un événement de ressource, pas un appel d’API normal.

Le thème constant est l’ennui intentionnel : gardez l’API Ollama privée par défaut, ajoutez un chemin privé pour l’accès distant, puis appliquez cette politique deux fois (identité VPN plus pare-feu d’hôte) pour qu’une seule erreur ne se transforme pas en extrémité publique.