Dostęp do Ollamy zdalnie przez Tailscale lub WireGuard bez otwartych portów publicznych.

Ollama jest najbardziej szczęśliwa, gdy traktuje się ją jak lokalnego demona: wiersz poleceń (CLI) i Twoje aplikacje komunikują się z interfejsem HTTP na pętli lokalnej, a reszta sieci nigdy nie dowiaduje się o jej istnieniu.

Domyślnie dzieje się dokładnie to: wspólny lokalny adres bazowy znajduje się na localhost na porcie 11434.

Ten artykuł dotyczy momentu, gdy potrzebujesz dostępu zdalnego (do laptopa, innego komputera w biurze, może do telefonu), ale nie chcesz udostępniać nieautoryzowanego uruchamiającego model całej sieci. Ta intencja ma znaczenie, ponieważ najprostszy ruch skalowania (otwarcie portu, przekierowanie, koniec) jest również tym, który tworzy bałagan.

Pragmatycznym kierunkiem jest coś prostego: utrzymuj interfejs API Ollama prywatny, a następnie spraw, aby ścieżka prywatnej sieci była nudna. Tailscale i WireGuard to dwa powszechne sposoby na to, a reszta polega na upewnieniu się, że host nasłuchuje tylko tam, gdzie powinien, i że zapora sieciowa się z tym zgadza.

Urządzenie zdalne
  |
  | (prywatna ścieżka VPN: tailscale lub wireguard)
  v
Interfejs VPN na hoście (tailscale0 lub wg0)
  |
  | (lokalny hop)
  v
Serwer Ollama (interfejs HTTP na localhost lub IP VPN)

Model zagrożeń i kto powinien mieć dostęp do API

Jak uzyskać zdalny dostęp do Ollama bez wystawiania jej na publiczny internet? Odpowiedź polega mniej na konkretnym narzędziu, a bardziej na byciu jawnym co do tego „kto może się połączyć" i „skąd".

Przydatnym modelem mentalnym są trzy koncentryczne pierścienie:

• Tylko lokalnie: tylko procesy na danym urządzeniu mogą wywoływać API.
• Tylko w LAN: urządzenia w tej samej sieci lokalnej mogą wywoływać API.
• Tylko przez VPN: wybrane urządzenia i użytkownicy w prywatnej sieci nakładkowej mogą wywoływać API.

Pierwszy pierścień jest domyślnym. Wiele poradników (i narzędzi takich jak Postman) zakłada, że adres URL bazowy to localhost 11434, co jest zarówno wygodne, jak i zaskakująco silną granicą bezpieczeństwa.

Powód, dla którego pierścienie mają znaczenie, polega na tym, że Ollama jest często opisywana jako nieposiadająca wbudowanego uwierzytelniania dla swojego lokalnego interfejsu HTTP, co oznacza, że ekspozycja sieciowa i kontrola dostępu stają się Twoją pracą, jeśli wyjdź poza localhost.

Drugim powodem jest koszt i nadużycia: nawet „prywatny" punkt końcowy LLM to nadal punkt końcowy API. OWASP API Security Top 10 wskazuje kategorie takie jak nieprawidłowa konfiguracja bezpieczeństwa i nieograniczone zużycie zasobów; uruchamiający model jest praktycznie dzieckiem plakatu dla „zużycia zasobów", jeśli zostanie wystawiony w sposób przypadkowy.

Zatem podstawowy model zagrożeń to nie tylko „atakujący czyta moje dane". To również „ktoś może prowadzić mój CPU i GPU jak wypożyczony samochód" oraz „niezamierzeni użytkownicy odkrywają go i zaczynają budować na jego podstawie".

OLLAMA_HOST i semantyka wiązania w 90 sekund

Co robi OLLAMA_HOST i jaka jest najbezpieczniejsza wartość domyślna? OLLAMA_HOST to przełącznik, który kontroluje, gdzie serwer Ollama nasłuchuje. W ollama serve zmienna środowiskowa jest opisana jako adres IP i port serwera, z domyślnym 127.0.0.1 i portem 11434.

W prostych słowach, adres wiązania decyduje, które sieci mogą nawet próbować nawiązać połączenie TCP:

• 127.0.0.1 oznacza tylko localhost.
• IP LAN (jak 192.168.x.y) oznacza, że LAN może do niego dotrzeć.
• 0.0.0.0 oznacza wszystkie interfejsy (LAN, VPN, wszystko) mogą do niego dotrzeć, chyba że zapora sieciowa je blokuje.

Dlatego większość poradników „jak to udostępnić" sugeruje przełączenie z 127.0.0.1 na 0.0.0.0, ale ta rada jest niekompletna bez zapory sieciowej świadomej interfejsów.

Oto ściągawka, którą trzymam w głowie:

# Tylko lokalnie (bazowe)
export OLLAMA_HOST=127.0.0.1:11434

# Wszystkie interfejsy (potężne, łatwe do żałowania)
export OLLAMA_HOST=0.0.0.0:11434

# Tylko interfejs VPN (preferowany, gdy VPN ma stabilny IP na hoście)
export OLLAMA_HOST=100.64.0.10:11434   # przykładowy IP tailscale
export OLLAMA_HOST=10.10.10.1:11434    # przykładowy IP wireguard

# Inny port (przydatny, gdy 11434 jest już zajęty)
export OLLAMA_HOST=127.0.0.1:11435

Przypadek „innego portu" jest jawnie omawiany w śledzeniu problemów Ollama jako przykład używania OLLAMA_HOST do zmiany portu nasłuchującego.

Jedna operacyjna uwaga, która ugryza ludzi: jeśli Ollama działa jako zarządzana usługa, ustawienie zmiennych środowiskowych w interaktywnym powłoce niekoniecznie zmieni konfigurację usługi. Dlatego wiele historii „działało to w moim terminalu, ale nie po restarcie" kończy się w nadpisaniach jednostek systemd lub konfiguracji menedżera usług.

Wzór A: Najpierw VPN z Tailscale

Czy Tailscale może ograniczyć dostęp tylko do jednego portu usługi na maszynie? Tak, i to jest dużą częścią tego, dlaczego Tailscale jest dobrym dopasowaniem dla „zdalnego dostępu bez publikowania".

Tailscale daje Ci prywatną sieć (tailnet) z centralnie zarządzaną kontrolą dostępu (ACLs). ACLs istnieją specjalnie do zarządzania uprawnieniami urządzeń i zabezpieczania sieci.

Brak publicznego portu oznacza brak tańczenia z routerem

Najczystszy wzór polega na unikaniu otwierania jakiegokolwiek portu skierowanego na internet dla Ollama w ogóle i traktowaniu VPN jako jedynego wejścia. Z Tailscale urządzenia próbują połączyć się bezpośrednio peer-to-peer, gdy to możliwe, i mogą cofnąć się do mechanizmów przesyłania, gdy bezpośrednie połączenie nie jest możliwe.

To nie jest magiczne bezpieczeństwo samo w sobie, ale radykalnie zmniejsza promień wybuchu w porównaniu do „przekierowałem 11434 na moim routerze".

Split horizon i nazewnictwo z MagicDNS

Drugim pytaniem, które pojawia się w prawdziwym życiu, jest „czy łączę się przez IP LAN, gdy jestem w domu, i przez IP VPN, gdy jestem poza domem". To jest w zasadzie problem split-horizon.

Tailscale MagicDNS pomaga, dając każdemu urządzeniu stabilną nazwę hosta tailnet. Pod spodem MagicDNS generuje FQDN dla każdego urządzenia, które łączy nazwę maszyny i nazwę DNS tailnet, a nowoczesne nazwy tailnet kończą się na .ts.net.

Subiektywne podejście jest takie, że używanie nazwy jest zazwyczaj lepsze niż hardkodowanie IP, ponieważ nazwa podąża za urządzeniem, nawet jeśli Twój IP tailnet się zmieni. Ale też jest w porządku być celowo nudnym i utrzymać mały plik hosts lub pojedynczy rekord DNS wewnętrzny, jeśli wolisz. MagicDNS istnieje, abyś nie musiał.

Bezpośredni port versus tylko proxy tailnet

Są dwa powszechne sposoby Tailscale na dotarcie do usługi:

• Bezpośredni dostęp do portu, gdzie usługa nasłuchuje na interfejsie tailnet, a klienci łączą się z tym IP i portem.
• Tailscale Serve, gdzie Tailscale kieruje ruch z innych urządzeń tailnet do lokalnej usługi na hoście.

Serve jest jawnie opisany jako kierowanie ruchu z innych urządzeń tailnet do lokalnej usługi działającej na Twoim urządzeniu.

Dla Ollama, Serve może być atrakcyjne, ponieważ pozwala utrzymać Ollama na localhost i udostępnić tylko kontrolowaną ścieżkę wejściową przez Tailscale. Łączy się również naturalnie z HTTPS wewnątrz tailnet, jeśli chcesz punkty końcowe przyjazne przeglądarce.

Funkcja powiązana, warta nazwania, a następnie umieszczenia w umyśle, to Funnel. Funnel jest zaprojektowany do kierowania ruchu z szerszego internetu do usługi na urządzeniu tailnet i jest jawnie dla „dla każdego, nawet jeśli nie używa Tailscale". To jest przeciwieństwo tego artykułu.

Wzór B: WireGuard dla tych, którzy chcą surowych elementów

WireGuard to podstawowy element zasilający wiele produktów VPN i jest celowo minimalny: konfigurujesz interfejs, definiujesz peerów i decydujesz, jaki ruch jest dozwolony.

Szybki start WireGuard pokazuje podstawowy kształt: stwórz interfejs taki jak wg0, przypisz IP i skonfiguruj peerów z wg.

Kluczowym koncepcją dla zakresu dostępu jest AllowedIPs. W dokumentacji Red Hat, WireGuard odczytuje IP docelowe z pakietu i porównuje je z listą dozwolonych adresów IP; jeśli peer nie zostanie znaleziony, WireGuard odrzuca pakiet.

Dla hosta Ollama, praktyczne tłumaczenie to:

• Umieść hosta w prywatnej podsieci WireGuard.
• Zwiąż Ollama albo z localhost i przekieruj do niego, albo bezpośrednio z IP WireGuard.
• Tylko peerzy, którzy mają poprawne klucze i AllowedIPs, mogą kierować ruch do tego prywatnego IP.

To jest mniej ruchomych części niż komercyjna nakładka, ale też oznacza, że jesteś odpowiedzialny za dystrybucję kluczy, cykl życia peerów i jak zdalni peerzy docierają do Twojej sieci.

Zaporę sieciową tylko dla interfejsu VPN lub tailnet

Jak zapora sieciowa może ograniczyć Ollama tylko do ruchu interfejsu VPN? Celem jest zapobieganie przypadkowej ekspozycji, nawet jeśli adres wiązania stanie się szerszy niż zamierzony.

Ogólny wzór to:

• Dozwól port TCP Ollama tylko na interfejsie VPN (tailscale0 lub wg0).
• Zablokuj ten sam port na wszystkim innym.
• Preferuj „domyślnie blokuj przychodzące" jeśli tak działasz dla hosta.

Tailscale ma jawną wskazówkę dotyczącą używania UFW do ograniczenia ruchu nie-Tailscale do serwera, co jest w zasadzie podejściem „zablokuj wszystko poza tailnet".

Jednym odcieniem, który ma znaczenie dla Tailscale, jest to, że oczekiwania hosta zapory sieciowej mogą nie pasować do rzeczywistości, jeśli zakładasz, że UFW zablokuje ruch tailnet. Projekt Tailscale omawiał, że celowo instaluje regułę pozwalającą ruch na tailscale0 i polega na filtrze kontrolowanym przez ACL wewnątrz tailscaled.

To nie jest argument przeciwko zaporze sieciowej hosta. To jest argument za byciem przemyślanym co do tego, który plan kontrolny faktycznie egzekwuje politykę. Jeśli chcesz „tylko te urządzenia mogą dotrzeć do portu 11434", ACLs Tailscale są zaprojektowane do tej pracy.

Jeśli jednak chcesz kontroli hosta na poziomie interfejsu, przykłady wyglądają mniej więcej tak:

# Logika stylu UFW (ilustracyjna)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

# Albo dla wireguard
ufw allow in on wg0 to any port 11434 proto tcp
ufw deny  in to any port 11434 proto tcp

Nawet jeśli w głównej mierze polegasz na polityce VPN, zapora sieciowa hosta nadal zapewnia użyteczny „pas bezpieczeństwa" przeciwko nieprawidłowemu wiązaniu z 0.0.0.0 lub nieoczekiwanym nakładkom usług.

Opcjonalny proxy odwrotny tylko na wejściu VPN

Kiedy proxy odwrotne jest przydatne dla zdalnego dostępu do Ollama? Proxy jest przydatne, gdy chcesz jedną lub więcej z tych właściwości:

• Standardową bramę uwierzytelniania (basic auth, OIDC, certyfikaty klienta).
• Terminację TLS z certyfikatem, któremu klienci ufają.
• Limity żądań i czasy oczekiwania.
• Czystsze URL dla narzędzi, które nie lubią surowych portów.

To jest miejsce, gdzie intencja „nie publikuj do internetu" powinna pozostać prawdziwa: proxy odwrotne jest osiągalne tylko przez VPN, nie na publicznym interfejsie WAN.

Czy TLS jest potrzebny, gdy ruch już przechodzi przez VPN? Nie zawsze dla kryptografii, ale często dla ergonomii. Tailscale wskazuje, że połączenia między węzłami są już szyfrowane end-to-end, ale przeglądarki nie są świadome tego, ponieważ polegają na certyfikatach TLS do ustanowienia zaufania HTTPS.

Jeśli jesteś w świecie Tailscale, możesz włączyć certyfikaty HTTPS dla swojego tailnet, co wymaga MagicDNS i jawnie wskazuje, że nazwy maszyn i nazwa DNS tailnet będą opublikowane w publicznym rejestrze (logi transparentności certyfikatów).

Tę szczegółowość publicznego rejestru nie jest powodem do unikania TLS, ale jest powodem do nazwania maszyn jak dorosły (unikaj umieszczania prywatnych nazw projektów lub identyfikatorów klientów w nazwach hostów).

Ten artykuł celowo nie zawiera pełnej konfiguracji proxy odwrotnego (zobacz Twój artykuł A1 dla tego). Jedyną ideą, która ma znaczenie tutaj, jest lokalizacja:

• Ollama nasłuchuje na localhost lub IP VPN.
• Proxy odwrotne nasłuchuje tylko na interfejsie VPN.
• Proxy przekierowuje do Ollama.

Kontrola bezpieczeństwa dla zdalnego dostępu do API Ollama

To jest lista kontrolna, którą używam, aby utrzymać „zdalność" od cichego stania się „publiczną".

Wiązanie i osiągalność

• Potwierdź, że serwer nasłuchuje tam, gdzie myślisz, że nasłuchuje. Zdokumentowany domyślny to 127.0.0.1 i port 11434, a OLLAMA_HOST to zmienia.
• Traktuj 0.0.0.0 jako świadomy wybór, nie wygody.
• Preferuj wiązanie do IP interfejsu VPN, gdy jest stabilne i pasuje do topologii.

Kontrola dostępu

• Jeśli używasz Tailscale, wdroż ACLs, które pozwalają tylko konkretnym użytkownikom lub oznaczonym urządzeniom do portu Ollama. ACLs istnieją do zarządzania uprawnieniami urządzeń.
• Jeśli używasz WireGuard, utrzymuj AllowedIPs ciasno i traktuj klucze jako prawdziwą granicę tożsamości. WireGuard odrzuca pakiety, które nie pasują do mapowania AllowedIPs ważnego peerza.

Zapora sieciowa

• Dodaj regułę na poziomie hosta, która pozwala port Ollama tylko na tailscale0 lub wg0 i blokuje go wszędzie indziej.
• Jeśli oczekujesz, że UFW zablokuje ruch tailnet, zweryfikuj, jak Tailscale oddziałuje z Twoją zaporą. Tailscale omawiał pozwalanie na ruch tailscale0 i poleganie na filtrowaniu ACL wewnątrz tailscaled.

TLS i proxy

• Używaj TLS, gdy klienci są przeglądarkami lub gdy narzędzia oczekują HTTPS, nawet jeśli VPN już szyfruje transport. Tailscale dokumentuje tę lukę między szyfrowaniem VPN a zaufaniem HTTPS przeglądarki.
• Jeśli włączysz certyfikaty HTTPS Tailscale, pamiętaj o implikacji transparentności certyfikatów dla nazw hostów.
• Jeśli dodasz proxy odwrotne, utrzymaj je tylko w VPN i użyj go do uwierzytelniania i limitów, nie do ekspozycji w internecie.

Unikaj przypadkowej publicznej ekspozycji

• Bądź ostrożny z funkcjami jawnie zaprojektowanymi do publikowania usług w internecie. Tailscale Funnel kieruje ruch z szerszego internetu do urządzenia tailnet, co nie jest domyślnie bezpieczną ścieżką dla API Ollama.
• Jeśli cokolwiek stanie się osiągalne w internecie, nie zostawiaj anonimowej powierzchni /api. W tym momencie kategorie ryzyka OWASP API „nieprawidłowa konfiguracja bezpieczeństwa" i „zużycie zasobów" przestają być teoretyczne.

Obserwowalność i kontrola szkód

• Rejestruj żądania na warstwie wejściowej (logi polityki VPN, logi proxy lub oba).
• Dodaj limity żądań i konkurencyjności, jeśli Twoje proxy to obsługuje, ponieważ wnioskowanie modelu to zdarzenie zasobowe, nie zwykłe wywołanie API.

Spójny temat to celowa nudność: utrzymuj API Ollama prywatne domyślnie, dodaj prywatną ścieżkę do zdalnego dostępu, a następnie wymuś tę politykę dwukrotnie (tożsamość VPN plus zapora sieciowa hosta), aby pojedynczy błąd nie zamienił się w publiczny punkt końcowy.