Tailscale 또는 WireGuard를 통한 원격 Ollama 접근, 공개 포트 없음
공용 포트를 사용하지 않는 원격 Ollama 접근
Ollama 는 로컬 데몬으로 취급될 때 가장 잘 작동합니다. CLI 와 애플리케이션이 루프백 HTTP API 와 통신하고, 나머지 네트워크는 그 존재를 전혀 알지 못하는 상태입니다.
기본적으로 이것이 바로 일어나는 일입니다. 공통 로컬 기본 주소는 localhost 포트 11434 입니다.
이 글은 원격 접근 (노트북, 다른 사무실 기기, 아마도 휴대폰 등) 이 필요한 순간에 대해 다루지만, 인증되지 않은 모델 실행기를 전체 인터넷에 공개하고 싶지 않을 때의 시나리오입니다. 그 의도가 중요한 이유는 가장 쉬운 확장 방법 (포트 열기, 포워딩, 완료) 이 동시에 가장 큰 혼란을 초래하는 방법이기 때문입니다.
실용적인 방정식은 간단합니다: Ollama API 를 비공개로 유지한 뒤, 사설 네트워크 경로를 지루하게 만드세요. Tailscale 과 WireGuard 는 이를 수행하는 두 가지 일반적인 방법이며, 나머지는 호스트가 필요한 곳에서만 수신하도록 하고 방화벽이 이를 승인하도록 하는 것입니다.
원격 기기
|
| (사설 VPN 경로: tailscale 또는 wireguard)
v
호스트의 VPN 인터페이스 (tailscale0 또는 wg0)
|
| (로컬 홉)
v
Ollama 서버 (localhost 또는 VPN IP 의 HTTP API)
위협 모델 및 API 접근 권한
공인 인터넷에 노출하지 않고 Ollama 를 원격으로 접근하는 방법은 무엇일까요? 답은 특정 도구보다는 “누가 연결할 수 있는가” 와 “어디에서 연결할 수 있는가” 를 명시적으로 정의하는 것에 더 가깝습니다.
유용한 정신 모델은 세 개의 동심원입니다:
- 로컬만: 박스 내부의 프로세스만 API 를 호출할 수 있습니다.
- LAN 만: 동일한 로컬 네트워크의 기기만 API 를 호출할 수 있습니다.
- VPN 만: 사설 오버레이 네트워크의 선택된 기기와 사용자만 API 를 호출할 수 있습니다.
첫 번째 고리가 기본값입니다. 많은 가이드 (및 Postman 과 같은 도구) 는 기본 URL 이 localhost 11434 임을 가정하며, 이는 편리하면서도 놀라울 정도로 강력한 안전 경계입니다.
이 고리들이 중요한 이유는 Ollama 가 로컬 HTTP API 에 내장된 인증 기능이 없다고 흔히 설명되므로, localhost 를 벗어나면 네트워크 노출과 접근 제어가 사용자의 책임이 되기 때문입니다.
또 다른 이유는 비용과 남용입니다: “사설” LLM 엔드포인트조차도 여전히 API 엔드포인트입니다. OWASP API 보안 최상위 10 대 위협 중 보안 잘못된 설정과 제한 없는 리소스 소비와 같은 범주를 지적하며, 모델 실행기는 부주의하게 노출될 경우 “리소스 소비"의 대표적인 예가 될 수 있습니다.
따라서 기본 위협 모델은 단순히 “공격자가 데이터를 읽는다"가 아닙니다. 또한 “누군가가 내 CPU 와 GPU 를 렌터카처럼 사용할 수 있다” 와 “의도하지 않은 사용자가 이를 발견하고 이를 기반으로 개발을 시작한다"는 점도 포함됩니다.
90 초 내의 OLLAMA_HOST 와 바인딩 세맨틱
OLLAMA_HOST 는 무엇을 하는 것이며 가장 안전한 기본값은 무엇일까요? OLLAMA_HOST 는 Ollama 서버가 수신할 위치를 제어하는 스위치입니다. ollama serve에서 환경 변수는 서버의 IP 주소와 포트로 설명되며, 기본값은 127.0.0.1 과 포트 11434 입니다.
간단히 말해, 바인딩 주소는 TCP 연결을 시도할 수 있는 네트워크를 결정합니다:
- 127.0.0.1 은 로컬호스트만 의미합니다.
- LAN IP(예: 192.168.x.y) 는 LAN 이 이를 도달할 수 있음을 의미합니다.
- 0.0.0.0 은 방화벽이 차단하지 않는 한 모든 인터페이스 (LAN, VPN, 모든 것) 가 도달할 수 있음을 의미합니다.
대부분의 “접근 가능하게 하기” 가이드가 127.0.0.1 에서 0.0.0.0 으로 전환하라고 제안하는 이유입니다. 하지만 인터페이스 인식 방화벽 없이 이러한 조언은 불완전합니다.
제 머릿속에 있는 치트 시트는 다음과 같습니다:
# 로컬만 (기준선)
export OLLAMA_HOST=127.0.0.1:11434
# 모든 인터페이스 (강력하지만 후회하기 쉬움)
export OLLAMA_HOST=0.0.0.0:11434
# VPN 인터페이스만 (호스트에서 VPN 이 안정적인 IP 를 가질 때 선호됨)
export OLLAMA_HOST=100.64.0.10:11434 # 예시 tailscale IP
export OLLAMA_HOST=10.10.10.1:11434 # 예시 wireguard IP
# 다른 포트 (11434 가 이미 사용 중일 때 유용함)
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 에서 기기는 가능하면 직접 peer-to-peer 로 연결을 시도하며, 직접 연결이 불가능할 경우 중계 메커니즘으로 넘어갑니다.
이는 그 자체로 마법 같은 보안이 아니지만, “라우터에서 11434 포트를 포워딩했다"는 경우와 비교했을 때 폭발 반경을 극적으로 줄입니다.
MagicDNS 를 통한 스플릿 호라이즌과 네이밍
실제 생활에서 나타나는 두 번째 질문은 “집에서는 LAN IP 로, 외출 시에는 VPN IP 로 연결해야 하는가"입니다. 이는 기본적으로 스플릿 호라이즌 문제입니다.
Tailscale MagicDNS 는 각 기기에 안정적인 tailnet 호스트명을 제공함으로써 이를 해결합니다. 내부적으로 MagicDNS 는 기기명과 tailnet DNS 이름을 결합한 FQDN 을 모든 기기에 생성하며, 최신 tailnet 이름은 .ts.net으로 끝납니다.
주관적인 의견은 IP 를 하드코딩하는 것보다 이름을 사용하는 것이 일반적으로 더 낫다는 것입니다. tailnet IP 가 변경되더라도 이름이 기기를 따라가기 때문입니다. 하지만 의도적으로 지루하게 하고 작은 hosts 파일이나 단일 내부 DNS 레코드를 유지하는 것을 선호할 수도 있습니다. MagicDNS 는 이것이 필요 없도록 존재합니다.
직접 포트 접근 대 tailnet 전용 프록싱
서비스에 도달하는 두 가지 일반적인 Tailscale 방법이 있습니다:
- 직접 포트 접근: 서비스가 tailnet 인터페이스에서 수신하고 클라이언트가 해당 IP 와 포트에 연결합니다.
- Tailscale Serve: Tailscale 이 다른 tailnet 기기로부터의 트래픽을 호스트의 로컬 서비스로 라우팅합니다.
Serve 는 Ollama 를 localhost 에 유지하고 Tailscale 을 통한 통제된 진입 경로만 노출할 수 있기 때문에 매력적입니다. 또한 브라우저 친화적인 엔드포인트를 원한다면 tailnet 내에서 HTTPS 와 자연스럽게 결합됩니다.
명기하고 정신적으로 주차해야 할 관련 기능으로 Funnel 이 있습니다. Funnel 은 더 넓은 인터넷으로부터 tailnet 기기의 서비스로 트래픽을 라우팅하도록 설계되었으며, 명시적으로 “Tailscale 을 사용하지 않더라도 누구나 접근"할 수 있도록 하는 것입니다. 이는 이 글의 목적과 정반대입니다.
패턴 B: 원시 기능을 원하는 사람을 위한 WireGuard
WireGuard 는 많은 VPN 제품을 구동하는 기반 원시 기능이며, 의도적으로 최소주의적입니다: 인터페이스를 구성하고 peer 를 정의하며 어떤 트래픽이 흐를지 결정합니다.
WireGuard 빠른 시작은 기본 형태를 보여줍니다: wg0와 같은 인터페이스를 생성하고 IP 를 할당하며 wg로 peer 를 구성합니다.
접근 범위를 설정하는 핵심 개념은 AllowedIPs 입니다. Red Hat 문서에 따르면 WireGuard 는 패킷에서 목적지 IP 를 읽고 허용된 IP 주소 목록과 비교합니다. peer 가 발견되지 않으면 WireGuard 는 패킷을 드롭합니다.
Ollama 호스트의 경우 실용적인 해석은 다음과 같습니다:
- 호스트를 사설 WireGuard 서브넷에 배치합니다.
- Ollama 를 localhost 에 바인딩하고 이를 포워딩하거나, WireGuard IP 에 직접 바인딩합니다.
- 올바른 키와 AllowedIPs 를 가진 peer 만 해당 사설 IP 로 트래픽을 라우팅할 수 있습니다.
이는 상업용 오버레이보다 움직이는 부품이 적지만, 키 배포, peer 수명 주기, 원격 peer 가 네트워크에 도달하는 방식에 대해 스스로 책임져야 함을 의미합니다.
방화벽: VPN 인터페이스 또는 tailnet 만 허용
방화벽이 Ollama 를 VPN 인터페이스 트래픽으로만 제한할 수 있을까요? 목표는 바인딩 주소가 의도보다 넓어져도 우연한 노출을 방지하는 것입니다.
일반적인 패턴은 다음과 같습니다:
- Ollama TCP 포트를 VPN 인터페이스 (tailscale0 또는 wg0) 에서만 허용합니다.
- 모든 다른 곳에서 동일한 포트를 차단합니다.
- 호스트 운영 방식이 “기본 들어오는 트래픽 차단"이라면 이를 선호합니다.
Tailscale 은 UFW 를 사용하여 서버의 비-Tailscale 트래픽을 제한하는 방법에 대해 명시적인 지침을 제공하며, 이는 본질적으로 “tailnet 을 제외한 모든 것을 잠그는” 접근 방식입니다.
Tailscale 에 대해 특히 중요한 뉘앙스는 UFW 가 tailnet 트래픽을 차단할 것이라고 가정하면 호스트 방화벽 기대치가 현실과 맞지 않을 수 있다는 것입니다. Tailscale 프로젝트는 의도적으로 tailscale0에서 트래픽을 허용하는 규칙을 설치하고 tailscaled 내부의 ACL 제어 필터에 의존한다고 논의했습니다.
이는 호스트 방화벽에 대한 반론이 아닙니다. 이는 실제로 정책을 강제하는 제어 평면에 대해 의도적으로 행동해야 한다는 주장입니다. “이 기기들만 포트 11434 에 도달할 수 있다"고 원한다면, Tailscale ACL 은 그 작업을 위해 설계되었습니다.
그래도 인터페이스 수준의 호스트 제어를 원한다면 예시는 다음과 같습니다:
# UFW 스타일 로직 (설명용)
ufw allow in on tailscale0 to any port 11434 proto tcp
ufw deny in to any port 11434 proto tcp
# 또는 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 접근에 언제 유용할까요? 프록시는 다음 중 하나 이상의 속성을 원할 때 유용합니다:
- 표준 인증 게이트 (기본 인증, OIDC, 클라이언트 인증서).
- 클라이언트가 신뢰하는 인증서로 TLS 종료.
- 요청 제한 및 시간 제한.
- 원시 포트를 싫어하는 도구를 위한 깔끔한 URL.
여기서 “인터넷에 게시하지 않는다"는 의도도 여전히 유지되어야 합니다: 리버스 프록시는 VPN 을 통해서만 도달 가능하며 공개 WAN 인터페이스에서는 도달할 수 없습니다.
트래픽이 이미 VPN 을 통해 이동하는 경우 TLS 가 필요한가요? 암호화 측면에서는 항상 그렇지 않지만, 사용성 측면에서는 종종 필요합니다. Tailscale 은 노드 간 연결이 이미 종단 간 암호화되어 있지만, 브라우저는 HTTPS 신뢰를 확립하기 위해 TLS 인증서에 의존하므로 이를 인식하지 못한다고 지적합니다.
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 는 유효한 peer AllowedIPs 매핑과 일치하지 않는 패킷을 드롭합니다.
방화벽
- Ollama 포트를 tailscale0 또는 wg0 에서만 허용하고 다른 곳에서는 차단하는 호스트 수준 규칙을 추가하세요.
- UFW 가 tailnet 트래픽을 차단할 것으로 기대한다면, Tailscale 이 방화벽과 상호 작용하는 방식을 확인하세요. Tailscale 은 tailscale0 트래픽을 허용하고 tailscaled 내부의 ACL 필터링에 의존하는 것을 논의했습니다.
TLS 와 프록싱
- VPN 이 이미 전송을 암호화하더라도 클라이언트가 브라우저이거나 도구가 HTTPS 를 기대할 때 TLS 를 사용하세요. Tailscale 은 VPN 암호화와 브라우저 HTTPS 신뢰 간의 이 간극을 문서화합니다.
- Tailscale HTTPS 인증서를 활성화하면 호스트명에 대한 인증서 투명성 영향을 기억하세요.
- 리버스 프록시를 추가하면 인터넷 노출이 아닌 인증 및 제한을 위해 VPN 전용으로 유지하세요.
우연한 공개 노출 방지
- 서비스에 인터넷을 게시하도록 명시적으로 설계된 기능에 주의하세요. Tailscale Funnel 은 더 넓은 인터넷으로부터 tailnet 기기로 트래픽을 라우팅하며, 이는 Ollama API 에 대한 기본 안전한 경로가 아닙니다.
- 무엇이든 인터넷에 도달 가능하게 되면 익명
/api표면을 남기지 마세요. 그 시점에 OWASP API “보안 잘못된 설정"과 “리소스 소비” 위험 범주는 더 이상 이론적이지 않습니다.
가시성 및 피해 통제
- 진입 계층 (VPN 정책 로그, 프록시 로그, 또는 둘 다) 에서 요청을 기록하세요.
- 모델 추론이 일반적인 API 호출이 아닌 리소스 이벤트이므로 프록시가 지원한다면 요청 및 동시성 제한을 추가하세요.
일관된 주제는 의도적으로 지루한 것입니다: 기본적으로 Ollama API 를 비공개로 유지하고 원격 접근을 위한 사설 경로를 추가한 뒤, 단일 실수가 공개 엔드포인트로 이어지지 않도록 정책을 두 번 강제합니다 (VPN 식별자 плюс 호스트 방화벽).
