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

Ollama est le plus heureux lorsqu’il est traité comme un démon local : la CLI et vos applications communiquent avec une API HTTP sur la boucle locale, et le reste du réseau n’a aucune raison de savoir qu’il existe.

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

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 exposer un exécuteur de modèle non authentifié à tout Internet. Cette intention est importante, 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 étoile polaire 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 n’écoute que là où il le devrait et que le pare-feu est d’accord.

Périphérique 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)

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

Comment accéder à Ollama à distance sans l’exposer à Internet public ? La réponse dépend moins d’un outil spécifique que de la clarté sur « qui est autorisé à se connecter » et « depuis où ».

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

• Local uniquement : seuls les processus sur la machine peuvent appeler l’API.
• LAN uniquement : les appareils sur le 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 anneau est le paramètre 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 une frontière de sécurité surprenante.

La raison pour laquelle les anneaux importent est qu’Ollama est communément décrit comme ne possédant aucune 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 localhost.

L’autre raison est le coût et les abus : même un point de terminaison LLM « privé » reste un point de terminaison API. Les 10 principales menaces de sécurité API d’OWASP mettent en avant 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 utiliser mon CPU et ma GPU comme une voiture de location » et « des utilisateurs non prévus le découvrent et commencent à construire dessus ».

OLLAMA_HOST et la sémantique de liaison 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 y accéder.
• 0.0.0.0 signifie toutes les interfaces (LAN, VPN, tout) peuvent y accéder à moins qu’un pare-feu ne les bloque.

C’est pourquoi la plupart des tutoriels « 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 la fiche de triche 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érable 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 registre de problèmes d’Ollama comme exemple d’utilisation de OLLAMA_HOST pour modifier le port d’écoute.

Une note opérationnelle qui mord les gens : si Ollama fonctionne comme un 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 en premier 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 un bon choix pour « l’accès distant sans publication ».

Tailscale vous donne un réseau privé (un tailnet) avec des contrôles d’accès gérés centralement (ACLs). Les ACLs 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 le seul point d’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 vie réelle est « dois-je me connecter 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 de domaine DNS tailnet, et les noms de tailnet modernes se terminent par .ts.net.

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

Port direct versus proxying tailnet uniquement

Il existe deux méthodes courantes Tailscale pour accéder à 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 acheminant le trafic d’autres appareils tailnet vers un service local s’exécutant 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 points de terminaison compatibles avec les navigateurs.

Une fonctionnalité connexe à nommer puis à ranger mentalement est Funnel. Funnel est conçu pour acheminer le trafic de l’Internet plus large vers un service sur un appareil tailnet et est explicitement destiné à « permettre l’accès à n’importe qui, 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é à circuler.

Le démarrage rapide de 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 l’étendue de l’accès est AllowedIPs. Dans la documentation Red Hat, WireGuard lit l’IP de destination depuis un paquet et la compare à la liste des adresses IP autorisées ; si le pair n’est pas trouvé, WireGuard abandonne 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 à localhost et faites un forward, soit liez directement à l’IP WireGuard.
• Seuls les pairs qui possèdent les bonnes clés 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 accèdent à votre réseau.

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

Comment un pare-feu peut-il limiter Ollama au trafic de l’interface VPN uniquement ? L’objectif est de prévenir 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.
• Privilégier « refus par défaut des entrées » si vous opérez ainsi pour l’hôte.

Tailscale a des directives 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 compte 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é quant au plan de contrôle qui applique réellement la politique. Si vous voulez « seuls ces appareils peuvent accéder au port 11434 », les ACLs de Tailscale sont conçues pour cela.

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

# Logique de 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 incorrecte à 0.0.0.0 ou des wrappers de service inattendus.

Proxy inverse optionnel uniquement sur l’entrée VPN

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

• Une porte d’authentification standard (auth basique, OIDC, certificats clients).
• Terminaison TLS avec un certificat que les clients font confiance.
• Limites de requêtes et délais d’attente.
• Des URL plus propres pour les outils qui n’aiment pas les ports bruts.

C’est ici que l’intention « ne pas publier sur Internet » doit rester vraie : le proxy inverse est accessible uniquement 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 ne sont pas conscients de cela car ils s’appuient sur des certificats TLS pour établir la confiance HTTPS.

Si vous êtes dans le monde Tailscale, vous pouvez activer les certificats HTTPS pour votre tailnet, ce qui nécessite MagicDNS et note explicitement que les noms de machines et le nom de domaine 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 d’éviter le TLS, mais c’est une raison de nommer les machines comme des adultes (éviter d’incorporer des noms de projets privés ou des identifiants clients dans les noms d’hôte).

Cet article n’inclut intentionnellement pas de configuration complète de proxy inverse (voir votre article A1 pour cela). La seule idée qui compte ici est l’emplacement :

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

Checklist de sécurité pour l’accès distant à l’API Ollama

Voici la checklist que j’utilise pour éviter que « distant » ne devienne 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 s’inscrit dans la topologie.

Contrôle d’accès

• Si vous utilisez Tailscale, implémentez des ACLs qui autorisent uniquement les utilisateurs spécifiques ou les appareils balisés vers le port Ollama. Les ACLs existent pour gérer les permissions des appareils.
• Si vous utilisez WireGuard, maintenez AllowedIPs serrés et traitez les clés comme la véritable frontière d’identité. WireGuard abandonne les paquets qui ne correspondent pas à une mappage AllowedIPs de pair valide.

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 vous attendez à ce 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 du fait de s’appuyer sur le 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 les certificats HTTPS Tailscale, rappelez-vous l’implication de la 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.

Éviter une exposition publique accidentelle

• Méfiez-vous des fonctionnalités conçues explicitement pour publier des services sur Internet. Tailscale Funnel achemine le trafic de l’Internet plus large vers un appareil tailnet, ce qui n’est pas le chemin par défaut sûr pour une API Ollama.
• Si quelque chose finit par être accessible depuis Internet, ne laissez pas de surface /api anonyme. À ce stade, les catégories de risque OWASP API « mauvaise configuration de sécurité » et « consommation de ressources » cessent d’être théoriques.

Observabilité et contrôle des dommages

• 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 API normal.

Le thème constant est ennuyeux par intention : 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 point de terminaison public.