Ngày nào tôi cũng dùng cả hai. Ollama chạy trên laptop của tôi và trên máy trạm có GPU ở văn phòng, phục vụ việc phát triển và mấy công cụ tôi tự làm cho mình. Còn vLLM thì phục vụ một mô hình chat cho một dự án freelance, trên một GPU 96 GB duy nhất, lúc đầu chạy bằng Docker Compose và bây giờ chạy trong một cụm Kubernetes nhỏ. Bài này nói về thế mạnh của từng công cụ, cách cài đặt chúng, và những chỗ đã khiến tôi mất thời gian ở phía vLLM.

So sánh nhanh vLLM và Ollama

#

Ollama là gì

#

Trong những cách tôi biết, Ollama là cách dễ nhất để có một mô hình trả lời được ngay trên máy của bạn. Nó phát triển từ llama.cpp và chạy các mô hình GGUF đã lượng tử hóa, vì vậy một mô hình 8B chỉ chiếm khoảng 5 GB và chạy thoải mái trên một chiếc MacBook. Bạn tải mô hình về theo tên, mô hình được nạp vào bộ nhớ ở lần gọi đầu tiên, và sau năm phút không có việc gì làm thì nó tự rời khỏi bộ nhớ. Nhờ vậy, Ollama chia sẻ máy một cách lịch sự với mọi thứ khác bạn đang chạy.

Nhưng chính sự lịch sự đó cũng là cái giá phải trả. Ollama được thiết kế xoay quanh việc phục vụ từng người một. Nó có thể trả lời song song vài yêu cầu, nhưng mỗi khe xử lý song song đều tốn thêm bộ nhớ, và ngay từ đầu nó không được làm ra để gộp hàng chục người dùng lên cùng một GPU.

vLLM là gì

#

vLLM là một engine phục vụ mô hình (serving engine), và nó được làm ra chính là để gộp lô như vậy. Phần lớn sức mạnh của nó đến từ hai ý tưởng. Thứ nhất là PagedAttention: nó lưu KV cache của mỗi yêu cầu (bộ nhớ đệm chứa trạng thái attention mà mô hình tích lũy dần trong lúc đọc và sinh token) thành những khối nhỏ có kích thước cố định, nhờ đó bộ nhớ GPU không bị hao phí vì phần đệm (padding) và phân mảnh. Thứ hai là gộp lô liên tục: yêu cầu mới được đưa vào lô giữa các bước sinh token, thay vì phải chờ lô hiện tại chạy xong. Kết hợp hai ý tưởng này, một GPU chạy vLLM phục vụ được số người dùng đồng thời nhiều hơn hẳn so với chính GPU đó khi xử lý lần lượt từng yêu cầu một.

Cái giá phải trả là vLLM cư xử như thể nó là chủ của cả card GPU. Vừa khởi động, nó đã chiếm phần bộ nhớ GPU dành cho mình, dùng toàn bộ phần mà trọng số mô hình không cần đến để làm KV cache, và giữ hết chỗ đó dù có ai gọi tới hay không. Nó cũng đòi trọng số đầy đủ từ Hugging Face, hoặc một kiểu lượng tử hóa thân thiện với GPU như FP8, chứ không dùng các tệp GGUF như Ollama.

Một API, hai máy chủ

#

Vì cả hai đều cung cấp API chat completions của OpenAI, code của tôi không cần biết nó đang nói chuyện với bên nào. URL và tên mô hình được lấy từ biến môi trường:

import os
from openai import OpenAI

# Laptop:      LLM_URL=http://localhost:11434/v1  LLM_MODEL=qwen3:8b
# Máy chủ GPU: LLM_URL=http://localhost:8000/v1   LLM_MODEL=qwen3-8b
client = OpenAI(base_url=os.environ["LLM_URL"], api_key="not-needed")

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Say hello in Korean."}],
)
print(reply.choices[0].message.content)

Trên laptop, vốn không có GPU mạnh, ứng dụng trỏ tới Ollama. Trên máy chủ thì nó trỏ tới vLLM. Ngoài hai biến đó ra không có gì thay đổi, và tôi có thể phát triển ứng dụng mà không cần bật máy GPU lên chút nào. Ở phía vLLM, --served-model-name đặt cho mô hình một cái tên ngắn, để client không phải gửi nguyên đường dẫn Hugging Face đầy đủ.

Có một điều cần lưu ý, vì rất dễ quên: cùng một mô hình nhưng chạy trên hai bên sẽ không cho ra cùng câu trả lời. qwen3:8b của Ollama là bản lượng tử hóa 4-bit, trong khi trên vLLM bạn thường chạy trọng số 16-bit hoặc FP8. Một prompt đã được tinh chỉnh trên bên này có thể cư xử khác trên bên kia, nên bất cứ thứ gì bạn đang đo, dù là chất lượng câu trả lời, việc mô hình có từ chối trả lời hay không, hay JSON có parse được không, đều phải được kiểm tra trên đúng máy chủ mà môi trường production sẽ thật sự dùng.

Cách cài đặt Ollama

#

Trên Mac hoặc Windows, hãy tải ứng dụng về từ ollama.com. Trên Linux thì chạy:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

Thế là xong. API giờ đã có ở http://localhost:11434. Nó chỉ lắng nghe trên localhost, trừ khi bạn đặt OLLAMA_HOST, và như thế là đúng điều bạn muốn. Ollama của tôi chạy trên máy trạm ở văn phòng, bind vào 127.0.0.1, và tôi truy cập nó từ bất cứ đâu qua một đường hầm (cách tôi thiết lập việc đó bằng Cloudflare WARP).

Cách cài đặt vLLM

#

Trên Linux, với GPU NVIDIA và driver đời mới:

python -m venv .venv && source .venv/bin/activate
pip install vllm
vllm serve Qwen/Qwen3-8B --served-model-name qwen3-8b --max-model-len 16384

Lần chạy đầu tiên sẽ tải trọng số mô hình về từ Hugging Face. Khi log hiện dòng Application startup complete, lệnh curl localhost:8000/v1/models sẽ liệt kê mô hình, và đoạn Python ở trên chạy được với nó.

Chạy vLLM bằng Docker

#

Với bất cứ thứ gì phải chạy liên tục, tôi dùng image chính thức thay vì cài bằng pip, chủ yếu để CUDA, PyTorch và vLLM đi kèm nhau với phiên bản đã được ghim cố định. Dưới đây là một service Compose dạng chung chung:

services:
  vllm:
    image: vllm/vllm-openai:v0.30.0   # ghim một tag cụ thể; image nặng khoảng 30 GB
    restart: unless-stopped
    ipc: host                          # PyTorch cần bộ nhớ dùng chung (shared memory)
    command: >
      --model Qwen/Qwen3-8B
      --served-model-name qwen3-8b
      --gpu-memory-utilization 0.85
      --max-model-len 16384
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    ports:
      - "127.0.0.1:8000:8000"          # truy cập qua ssh -L, không qua mạng LAN
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 10s
      timeout: 5s
      retries: 90
      start_period: 120s

Hãy ghim tag. vLLM thay đổi rất nhanh, các cờ (flag) và giá trị mặc định thay đổi giữa các bản phát hành, và bạn muốn chính mình là người quyết định khi nào những thay đổi đó xảy ra. ipc: host (hoặc một shm_size thật rộng rãi) có sẵn trong hướng dẫn Docker của chính vLLM. Còn lý do start_period dài như vậy chính là điều đầu tiên trong phần tiếp theo.

Những chỗ khiến tôi vấp khi chạy vLLM

#

Khởi động mất vài phút. Nạp trọng số, biên dịch và ghi lại (capture) các CUDA graph mất 190 giây trên máy chủ của tôi, và với một mô hình lớn thì ba đến năm phút là chuyện bình thường. Một bài kiểm tra sức khỏe (health check) viết theo kiểu dành cho ứng dụng web sẽ giết nó trước khi nó kịp sẵn sàng. Trong Compose, điều đó có nghĩa là cần một start_period dài; trong Kubernetes thì cần một startup probe. Nó cũng có nghĩa là mỗi lần khởi động lại là vài phút không có mô hình nào phục vụ, nên đừng khởi động lại một cách tùy tiện.

Bạn cho bao nhiêu bộ nhớ GPU, nó lấy bấy nhiêu, ngay từ lúc khởi động. --gpu-memory-utilization là tỉ lệ bộ nhớ trên card mà vLLM được phép dùng, ở các bản gần đây mặc định là 0.92, và toàn bộ phần mà trọng số không cần đến sẽ trở thành KV cache. Như vậy không sao nếu vLLM chạy một mình trên card. Card của tôi thì không như vậy, vì có mấy mô hình nhỏ hơn chạy bên cạnh, nên tôi đặt 0.70 trên card 96 GB. Mô hình của tôi, một mô hình hỗn hợp chuyên gia (mixture-of-experts) 35B ở định dạng FP8, chiếm 47.7 GiB khi nạp xong và để lại 15 GiB cho KV cache, quá đủ cho độ dài ngữ cảnh (context) 16k. Nếu vLLM từ chối khởi động vì độ dài chuỗi tối đa không vừa trong KV cache, hãy giảm --max-model-len trước khi đi tìm một GPU lớn hơn.

Mỗi chỗ dành cho LoRA đều tốn bộ nhớ ngay từ đầu. vLLM có thể phục vụ một mô hình gốc (base model) kèm nhiều LoRA adapter và chuyển qua lại giữa chúng theo từng yêu cầu, dựa vào tên mô hình, điều mà Ollama gần như không làm được. Nhưng lúc khởi động, nó giữ sẵn chỗ cho số adapter bằng --max-loras, mỗi adapter ở rank bằng --max-lora-rank, và trên một mô hình mixture-of-experts thì phần giữ chỗ đó bao gồm cả các expert, nên con số cộng dồn rất nhanh. Bốn adapter ở rank 64 không vừa khi đặt 0.70. Hai adapter thì vừa.

Giới hạn số chuỗi mặc định không hợp với mô hình lai. Mô hình tôi đang phục vụ trộn các lớp kiểu Mamba vào giữa các lớp attention, và mỗi chuỗi (sequence) cần một khối bộ nhớ đệm riêng cho những lớp đó. Với giá trị --max-num-seqs mặc định của vLLM trên card đó, nó không khởi động được; đặt --max-num-seqs 256 là hết lỗi. Nếu một kiến trúc mô hình mới hơn không chịu khởi động, hãy kiểm tra cờ này trước khi nghĩ tới những nguyên nhân cao siêu hơn.

Một Service Kubernetes tên vllm làm vLLM sập. Đây là vụ tôi khoái nhất. Kubernetes tự chèn biến môi trường cho mọi Service trong cùng namespace, đặt tên theo tên Service, nên một Service tên vllm sẽ đưa cho mọi pod biến VLLM_PORT=tcp://<cluster-ip>:8000. vLLM đọc VLLM_PORT như một thiết lập của chính nó, không hiểu nổi một URL nằm ở đó, và chết. Dĩ nhiên là chết sau khi đã nạp xong toàn bộ mô hình, nên mỗi lần thử tốn ba phút. Tài liệu của vLLM có cảnh báo chuyện này, nhưng tôi chỉ đọc thấy sau khi đã dính. Cách sửa là đặt enableServiceLinks: false trên pod, hoặc đặt cho Service một cái tên khác.

Dưới đây là khung của một Deployment chạy được, đã lược bớt chỉ còn những phần quan trọng:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
spec:
  replicas: 1
  strategy:
    type: Recreate               # pod cũ phải giải phóng GPU trước
  selector:
    matchLabels: {app: vllm}
  template:
    metadata:
      labels: {app: vllm}
    spec:
      enableServiceLinks: false  # không nhận VLLM_PORT=tcp://... từ Service
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.30.0
          args: ["--model=Qwen/Qwen3-8B", "--served-model-name=qwen3-8b"]
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: 32Gi       # lúc nạp cần nhiều RAM máy host hơn hẳn lúc phục vụ
          volumeMounts:
            - {name: shm, mountPath: /dev/shm}
          startupProbe:          # đừng phán xét trước khi mô hình nạp xong
            httpGet: {path: /health, port: 8000}
            initialDelaySeconds: 120
            periodSeconds: 10
            failureThreshold: 90
          livenessProbe:         # khởi động lại là nạp lại từ đầu, nên hãy kiên nhẫn
            httpGet: {path: /health, port: 8000}
            periodSeconds: 30
            timeoutSeconds: 5
            failureThreshold: 10
      volumes:
        - name: shm
          emptyDir: {medium: Memory, sizeLimit: 16Gi}

Phần đáng sao chép nhất là các probe. Startup probe chờ hai phút, rồi cho mô hình thêm mười lăm phút nữa để khởi động xong, trước khi Kubernetes coi nó là đã chết. Liveness probe chỉ khởi động lại pod sau khoảng năm phút thất bại liên tục, vì /health có thể phản hồi chậm khi engine đang bận, và dù sao thì mỗi lần khởi động lại cũng tốn một lần nạp lại toàn bộ. Recreate rất quan trọng khi chỉ có một GPU: cập nhật cuốn chiếu (rolling update) sẽ khởi động pod mới trước, và pod đó cứ nằm chờ một GPU mà pod cũ vẫn đang giữ. Giới hạn bộ nhớ trông có vẻ hào phóng, vì nó đúng là hào phóng thật; khi trọng số đã nằm trên GPU, pod của tôi ổn định ở khoảng 7 GiB RAM của máy host, nhưng riêng quá trình nạp thì cần nhiều hơn thế rất nhiều.

Những điều nên biết về Ollama

#

Với Ollama thì ít bất ngờ hơn, chủ yếu là vì nó làm ít việc hơn.

Yêu cầu đầu tiên sau một khoảng thời gian không ai dùng sẽ chậm, vì mô hình đã bị gỡ khỏi bộ nhớ và phải nạp lại. OLLAMA_KEEP_ALIVE quy định một mô hình được giữ trong bộ nhớ bao lâu sau yêu cầu cuối cùng; hãy tăng giá trị này lên nếu khoảng chờ đó làm bạn khó chịu, hoặc đặt thành -1 trên một máy không làm việc gì khác.

Cửa sổ ngữ cảnh (context window) phụ thuộc vào lượng bộ nhớ GPU bạn có. Dưới 24 GiB, Ollama mặc định chỉ dùng 4k token, ít hơn nhiều so với mức mà phần lớn mô hình hỗ trợ, và một prompt không vừa sẽ bị cắt bớt một cách lặng lẽ chứ không bị từ chối. Nếu câu trả lời có vẻ phớt lờ phần đầu của một prompt dài, hãy đặt OLLAMA_CONTEXT_LENGTH (hoặc num_ctx cho từng yêu cầu) bằng đúng mức bạn thật sự cần.

Nếu bạn chuyển tiếp (forward) một Ollama ở máy từ xa về laptop, đừng đặt nó ở cổng 11434. Đó là cổng mặc định của Ollama, và nếu có lúc một Ollama cục bộ trên laptop khởi động, hai bên sẽ tranh nhau cổng đó, và bạn có thể nói chuyện nhầm với bên kia mà không hề hay biết. Tôi chuyển tiếp Ollama của mình về cổng 11435.

Và Ollama không phải là máy chủ cho nhiều người dùng. Dùng cho một công cụ nội bộ chỉ vài người sử dụng thì ổn; khi lượng truy cập đồng thời thật sự xuất hiện, đó là lúc nên chuyển sang vLLM.

Cần bao nhiêu bộ nhớ GPU

#

Kích thước ước tính, chỉ tính riêng phần trọng số:

Tức là khoảng 2 byte cho mỗi tham số ở 16-bit, 1 byte ở 8-bit, và hơn nửa byte một chút ở Q4_K_M. Cộng thêm vào phần trọng số là KV cache, thứ tăng theo độ dài ngữ cảnh và theo số yêu cầu đang được xử lý cùng lúc. Chính yếu tố sau, tức số yêu cầu chạy cùng lúc, là lý do cùng một mô hình lại cần nhiều bộ nhớ hơn hẳn khi chạy trên vLLM phục vụ năm mươi người dùng, so với khi chạy trên Ollama chỉ phục vụ mình bạn.

Nên dùng cái nào

#

Nếu bạn chỉ muốn có một mô hình chạy trên máy của chính mình, hãy cài Ollama và dừng ở đó; trong vòng mười phút là bạn đã có thứ trả lời được. Nếu bạn có một máy chủ GPU, cùng với người dùng hoặc một ứng dụng sẽ gọi tới nó suốt cả ngày, hãy dùng vLLM, chấp nhận việc nó khởi động chậm và chiếm nhiều bộ nhớ, rồi cấu hình các probe cho đúng. Rất nhiều hệ thống cuối cùng dùng cả hai, hệ thống của tôi cũng vậy: Ollama ở nơi viết code, vLLM ở nơi các yêu cầu đổ về.

Ngoài hai cái này vẫn còn những lựa chọn khác. SGLang là phương án thay thế vLLM mà người ta hay nhắc tới, nhưng tôi chưa chạy nó trên production, nên tôi để nó ra ngoài bài này thay vì đoán mò. Còn nếu mô hình phải chạy trên điện thoại thì lại quay về llama.cpp, như tôi đã viết trong bài chạy LLM ngay trên thiết bị với React Native.

Bộ đồ nghề làm việc của tôi gồm ba cỗ máy hiếm khi ở cùng một chỗ. Thứ nhất là chiếc MacBook Air, tôi đi đâu nó theo đó. Thứ hai là một máy trạm ở văn phòng tên devbox, có GPU thật, chạy Ollama, mấy công cụ fine-tuning, một cụm Kubernetes nhỏ kèm container registry riêng, và bất kỳ agent nào tôi để lại đang cày một tác vụ dài. Thứ ba là điện thoại, nơi các ứng dụng tôi làm ra thật sự được dùng, và phần lớn thời gian trong ngày nó chạy bằng dữ liệu di động chứ không phải wifi.

Suốt một thời gian dài, ba thiết bị này gần như không nói chuyện được với nhau. Laptop chỉ kết nối được tới devbox khi đang ở trong mạng LAN văn phòng, ra ngoài là chịu. Điện thoại truy cập được dev server trên laptop khi cả hai cùng một mạng wifi, mà cũng chỉ khi tôi nhớ bind vào 0.0.0.0 và gõ đúng địa chỉ mà DHCP cấp cho chiếc Mac sáng hôm đó. Mọi thứ hay ho trên máy trạm, từ API của Ollama, các dashboard của cụm, dữ liệu trace, đến registry, đều được bind vào localhost hoặc mạng nội bộ của cụm, và tôi cố ý làm vậy, vì không thứ nào trong số đó nên nằm trên internet.

Bài này kể cách tôi nối chúng lại bằng Cloudflare WARP và một cặp Cloudflare Tunnel, điều đó đã thay đổi cách tôi làm tính năng AI và ứng dụng di động ra sao, và vài thứ đã hỏng mà chẳng hề báo cho tôi biết.

Điều tôi thật sự muốn

#

Nếu viết thành yêu cầu thì danh sách khá ngắn:

1. Laptop chỉ nên là máy khách mỏng (thin client). Việc gì cần GPU, cần nhiều RAM hay phải chạy hàng giờ thì để devbox lo, và laptop phải kết nối tới nó theo cùng một cách, dù đang ở văn phòng, ở nhà hay ở quán cà phê.
2. Điện thoại phải truy cập được dev server và shell của tôi từ bất cứ đâu, qua dữ liệu di động, mà không cần một cái VPN tôi phải nhớ bật tắt.
3. Những công cụ tôi dùng để xem hệ thống đang chạy thế nào, như dashboard, trace, docker info, danh sách mô hình, chỉ mình tôi truy cập được, và không bao giờ có URL công khai.
4. Không mở cổng vào (inbound port) nào. Không trên router văn phòng, không trên router ở nhà, không ở đâu cả.

Yêu cầu thứ tư loại bỏ luôn lời giải cũ, tức là chuyển tiếp cổng (port forward) cộng với một tên miền DNS động. Nó cũng loại bỏ khá nhiều mẹo khôn lỏi khác: cả devbox lẫn laptop đều nằm sau NAT mà tôi không kiểm soát, và cứ vài tiếng laptop lại nằm sau một NAT khác.

Trước đây: một repo toàn đường hầm SSH

#

Phiên bản đầu tiên là một repo nhỏ tôi tự viết, và đến giờ nó vẫn là lớp nền. Nó giải quyết đúng một bài toán trên laptop: đặt tên gọn gàng cho những thứ tôi truy cập qua SSH, không hơn. dnsmasq trả lời *.test bằng 127.0.0.1, Caddy định tuyến theo hostname tới một cổng cục bộ với tls internal để trình duyệt không kêu ca, còn một loạt launch agent chạy autossh giữ cho các đường hầm chuyển tiếp SSH (SSH forward) luôn mở và tự kết nối lại khi bị rớt. Chỉ cần nhìn hostname là biết thứ đó nằm ở đâu:

Vậy nên https://devbox-ollama.ssh.test/api/tags liệt kê các mô hình trên máy trạm, còn https://api.local.test là API của ứng dụng tôi đang làm, chạy ngay trên máy tôi.

Tôi dùng tên miền con của .test, chứ không tạo tên miền cấp cao mới như .ssh hay .cloud, và cũng không dùng .local. RFC 6761 dành riêng .test cho đúng mục đích này, còn .local thuộc về mDNS; chiếm nó là tính năng dò tìm Bonjour trên Mac ngừng hoạt động. dnsmasq vốn đã bắt wildcard toàn bộ *.test, nên thêm một nhãn nữa chẳng tốn gì: chỉ một tệp /etc/resolver/test trỏ vào 127.0.0.1, và từ đó về sau không phải chỉnh DNS thêm lần nào.

HTTPS trên những cái tên không hề tồn tại

#

Tất cả các tên đó đều chạy HTTPS với chứng chỉ mà trình duyệt tin tưởng, nghe thì có vẻ bất khả thi với một hostname chỉ tồn tại trên laptop của tôi. Caddy làm được nhờ tổ chức cấp chứng chỉ (CA) nội bộ của riêng nó. Khai báo tls internal cho một site nghĩa là bảo Caddy cấp chứng chỉ cho site đó từ một CA cục bộ thay vì xin Let’s Encrypt, còn caddy trust, được trình cài đặt chạy một lần, đưa chứng chỉ gốc của CA vào System keychain của macOS (Chrome và Safari đọc từ đây) và vào kho chứng chỉ riêng của Firefox. Từ lúc đó, https://anything.test mở ra mà không có cảnh báo chứng chỉ nào, http:// thường thì tự chuyển hướng sang, và không có gì rời khỏi máy.

Đây không chỉ là chuyện cho đẹp. Ngày càng nhiều tính năng của nền tảng web từ chối chạy trên HTTP thường: secure cookie, service worker, clipboard API, bất cứ thứ gì có SameSite=None. Kiểm thử một bản web build trên http://localhost thường sẽ che mất những lỗi chỉ lộ ra trên tên miền HTTPS thật. Kiểm thử trên https://app.local.test thì các lỗi ấy hiện ra ngay trên laptop của tôi.

Một khối cấu hình site, dịch vụ nào cũng giống hệt, chỉ khác số cổng:

devbox-ollama.ssh.test, devbox-ollama.test {
	tls internal
	import cors
	reverse_proxy 127.0.0.1:11435 {
		import proxyhdr
		transport http {
			keepalive off
			dial_timeout 5s
		}
	}
}

Hai snippet kia gánh những phần lắt nhắt. cors phản chiếu lại đúng Origin của bên gọi thay vì gửi *, vì * không được phép khi có dính tới thông tin xác thực (credentials), và nó tự trả lời các yêu cầu preflight OPTIONS bằng mã 204 để phía upstream không bao giờ phải lo. proxyhdr ghi đè header Host thành địa chỉ đích. Một số backend khó tính, trong đó có trang quản trị router và endpoint remote-debugging của Chrome, kiểm tra Host, và nếu không ghi đè thì chúng sẽ từ chối devbox-ollama.ssh.test như một cái tên chưa từng nghe tới. Cơ chế kiểm tra origin của chính Ollama chấp nhận loopback ở mọi cổng, nên ghi đè Host thành 127.0.0.1:11435 là lọt qua.

keepalive off là dòng mà nếu tự làm thì tôi đã sai. Phía upstream là các đường chuyển tiếp SSH mà autossh phá đi dựng lại mỗi khi mạng thay đổi. Nếu bật keep-alive, Caddy sẽ giữ một kết nối trong pool tới một đường hầm đã chết từ lâu, và cứ trả về những lỗi 404 khó hiểu cho tới khi được reload. Tắt đi thì mỗi yêu cầu đều kết nối mới, mà trên loopback thì chi phí đó không đo được.

Mỗi dịch vụ cũng trả lời ở tên phẳng cũ của nó (devbox-ollama.test), để các bookmark từ trước khi có hệ hậu tố vẫn dùng được.

Thanh menu

#

Khi đã có cả chục đường chuyển tiếp do launchd giữ mở, câu tôi cứ hỏi mãi là “nó có đang chạy không?”, và câu trả lời thì nằm ở ba chỗ: launchctl list, lsof và một lệnh curl. Thế nên tôi viết một plugin nhỏ cho thanh menu để gom về một chỗ, mỗi hostname có một chấm màu bên cạnh:

• 🟢 dịch vụ đã trả lời một yêu cầu đi qua đường hầm
• 🟡 đường hầm đang mở nhưng dịch vụ phía sau im lặng
• 🔴 không có gì lắng nghe ở cổng cục bộ, tức là chính đường hầm đã sập

Trạng thái vàng mới là cái hữu ích. Một phép kiểm tra chỉ có xanh/đỏ không phân biệt được “đường chuyển tiếp SSH đã chết” với “Ollama bị crash ở đầu bên kia”, mà hai chuyện đó có cách sửa hoàn toàn khác nhau. Plugin không giữ danh sách dịch vụ riêng mà đọc chính cấu hình proxy và cấu hình SSH mà mọi thứ khác đang dùng, nên thêm một dịch vụ ở đó là nó tự xuất hiện trên menu.

Phiên bản đầu tiên hơi tham. Nó làm mới mỗi mười giây và gọi vài tiến trình cho mỗi dịch vụ, khoảng bảy mươi tiến trình mỗi lượt, và macOS lập tức liệt nó vào danh sách “apps using significant energy”. Chỉ chụp trạng thái một lần mỗi lượt và làm mới cách vài phút là đủ kéo nó xuống còn khoảng 0.1% một nhân. Một đèn trạng thái mà ngốn pin thì chẳng giúp được ai, nên đáng tính chi phí của nó ngay từ đầu.

Nó có đúng một lỗ hổng, và lại là lỗ hổng quan trọng nhất. devbox không có tên công khai. Đường chuyển tiếp SSH tới nó kết nối vào một địa chỉ 192.168.x, nên nó chỉ chạy được khi laptop đang ở trong LAN văn phòng. Ra khỏi văn phòng là thanh menu chuyển đỏ và đỏ luôn, và mọi thứ tôi đã dời sang máy trạm để đỡ tải cho laptop đều nằm ngoài tầm với, đúng vào những lúc tôi không ngồi cạnh nó.

Hai đường hầm, quay đúng hướng

#

Cách sửa gồm ba phần, và hai phần đầu là Cloudflare Tunnel.

Một Cloudflare Tunnel là cloudflared giữ một kết nối đi ra (outbound) tới edge của Cloudflare. Cloudflare đẩy các yêu cầu ngược xuống theo chính kết nối đó, nên một máy nằm sau bao nhiêu lớp NAT cũng truy cập được mà không cần thứ gì lắng nghe trên router. Laptop mang ra wifi khách sạn nó vẫn theo, và nó sống sót được cả CGNAT.

Tôi chạy hai đường hầm, mỗi máy một cái, và lý do đáng để nói một câu. Lối tắt dễ thấy là chỉ một đường hầm trên laptop, thêm một quy tắc ingress trỏ tới cổng SSH của devbox trong LAN văn phòng. Cách đó không cần cài gì lên devbox cả. Nhưng nó cũng đi vòng qua laptop, mà laptop lại chính là cái máy rời khỏi văn phòng. Nó sẽ hỏng đúng trong trường hợp mà nó được tạo ra để xử lý. devbox thì đứng yên một chỗ, nên devbox tự giữ kết nối riêng của mình tới edge.

# config.yml on devbox (runs as a systemd service)
protocol: auto        # prefer QUIC, fall back to HTTP/2 over TCP 443
ha-connections: 4     # mains-powered, its job is to stay reachable

warp-routing:
  connectTimeout: 5s

ingress:
  - hostname: ssh-devbox.example.com
    service: tcp://127.0.0.1:22
  - service: http_status:404

Dùng tcp:// thay vì ssh:// là chỗ rất dễ làm sai. ssh:// chọn chế độ terminal hiển thị trên trình duyệt của Cloudflare, vốn bọc luồng dữ liệu lại cho một trang web; một client ssh bình thường đi qua đó sẽ nhận được banner rồi chết ngay ở bước trao đổi khóa. tcp:// mới là đường ống byte thuần mà cloudflared access ssh cần, và được thêm cái lợi là nó mang được cả scp, rsync, git qua SSH lẫn port forward.

Chính phần sau cùng ấy đã vá lỗ hổng ở lớp SSH. Cấu hình SSH giờ chọn đường đi cho từng kết nối:

Match originalhost devbox !exec "nc -z -G 1 <office-lan-ip> 22 >/dev/null 2>&1"
    ProxyCommand cloudflared access ssh --hostname ssh-devbox.example.com ...

Khi ở trong LAN văn phòng, phép thăm dò thành công và SSH đi thẳng, một bước nhảy. Ở bất kỳ đâu khác, phép thăm dò thất bại và SSH đi qua Cloudflare, xác thực bằng một service token của Access nên không có bước đăng nhập trên trình duyệt nào chắn đường. Phải là Match originalhost, không phải Match host: host so khớp sau khi HostName đã được thay vào, nên lúc đó tên đã thành IP và khối cấu hình không bao giờ kích hoạt. Kết quả là devbox-ollama.ssh.test chạy được ở văn phòng, ở nhà và trên tàu, và chấm trên thanh menu cứ xanh mãi.

Đường hầm của laptop thì đi theo chiều ngược lại. Nó cấp cho các dev server trên Mac những hostname HTTPS công khai thật: với mỗi ứng dụng tôi đang làm, đó là API, WebSocket server và bản web build của nó. Tất cả đều nằm sau Cloudflare Access, phần này tôi sẽ quay lại sau, vì chính nó biến cách làm này từ liều lĩnh thành an toàn.

Thanh menu cũng phải học cách nhận biết cả hai đường hầm, và nó không làm được bằng cách thăm dò. Một đường hầm chiều vào không có cổng cục bộ nào để kiểm tra, một trong hai connector thậm chí không chạy trên laptop, còn phép thử dễ thấy nhất, curl tới ssh-devbox.example.com, lại luôn nhận được câu trả lời từ edge của Cloudflare dù có connector nào gắn vào hay không, nên nó sẽ báo xanh cho một đường hầm đã chết. launchd cũng chẳng khá hơn: cloudflared cứ nằm đó ở trạng thái “loaded, exit 0” trong khi mọi kết nối tới edge đã rớt hết. Vậy nên với các đường hầm, menu hỏi Cloudflare API xem mỗi đường hầm có connector nào khỏe mạnh không, vì chính điều đó quyết định một lệnh ssh có tới nơi hay không. Nếu không liên lạc được với API, cả phần đó bị bỏ qua luôn thay vì vẽ màu đỏ. Thanh menu là thứ nhìn lướt qua, và một báo động giả ở đó tốn kém hơn một dòng bị thiếu.

Phần thứ ba: WARP biến nó thành một mạng

#

Đường hầm có hostname rất tuyệt cho mọi thứ nói HTTPS, và cho SSH từ một máy chạy được cloudflared. Điện thoại thì không chạy được. Hơn nữa, hostname của đường hầm không phải là một endpoint TCP: edge của Cloudflare chỉ kết thúc (terminate) HTTPS và WebSocket trên đó, nên cổng 22 tại ssh.example.com đóng, và loay hoay với Access đến mấy cũng không mở được.

Đó là việc của WARP. Cloudflare One Agent (tức client WARP bản doanh nghiệp, không phải ứng dụng “1.1.1.1” cho người dùng phổ thông, vốn không tham gia tổ chức được) được đăng ký trên laptop và điện thoại vào tổ chức Zero Trust của tôi. Mỗi đường hầm quảng bá các tuyến riêng (private route), và một thiết bị đang chạy WARP có thể mở một socket bình thường tới những địa chỉ đó và tới đúng máy. Nó không còn là “truy cập dịch vụ này qua tên” nữa, mà thành “những cỗ máy này đang ở chung một mạng với tôi”:

Những địa chỉ này là alias loopback trên từng máy, được tạo lúc khởi động, nên chúng không phụ thuộc vào DHCP hay router nào tôi đang đứng sau. 198.18.42.2 là devbox, dù đang ở văn phòng, ở nhà hay từ điện thoại dùng 5G. Địa chỉ LAN thật của chiếc Mac đổi mỗi lần tôi di chuyển; địa chỉ này thì không bao giờ đổi.

Chế độ chia tách đường hầm (split tunnel) đặt ở include mode, chỉ chứa những tuyến đó (cộng các dải của Cloudflare mà bản thân WARP cần). Chính điều này khiến client dễ sống cùng. Mặc định là exclude mode, khi đó WARP mang mọi thứ trừ một danh sách các dải riêng, nên từng byte điện thoại gửi đi đều đi vòng qua Cloudflare. Cái giá về pin và độ trễ là có thật, đủ để rốt cuộc tôi sẽ chỉ bật nó khi cần, mà như thế thì mất hết ý nghĩa. Ở include mode, lưu lượng tới ba máy của tôi đi qua WARP, còn mọi thứ khác đi theo đường bình thường, không bị động tới. Thế là client cứ bật suốt. warp-cli status trên laptop báo Connected cả ngày và tôi chẳng phải nghĩ đến nó.

Về giao thức truyền tải, tôi dùng MASQUE, tức HTTP/3 trên UDP 443 với HTTP/2 làm phương án dự phòng, thay vì WireGuard trên UDP 2408. Một số nhà mạng và mạng dành cho khách chặn 2408; gần như chẳng ai chặn 443. Chính sách của tổ chức tôi còn bật sẵn thỏa thuận khóa hậu lượng tử (post-quantum key agreement) cho MASQUE, thứ tôi không đi tìm nhưng cũng chẳng dại gì từ chối.

Vì sao là 198.18, và vì sao lại có địa chỉ IPv6

#

Các địa chỉ này trông hơi lạ, và những địa chỉ đầu tiên tôi chọn đã sai theo một cách khá bổ ích.

Lần đầu tôi thử 10.10.0.1, vì đó là thứ ai cũng nghĩ tới đầu tiên. Nó thất bại ở cả hai chế độ split tunnel. Ở exclude mode, danh sách mặc định của WARP loại trừ mọi dải RFC 1918 cộng 100.64.0.0/10, nên client sẽ bỏ lưu lượng tới địa chỉ đó trước khi nó kịp rời thiết bị. Ở include mode, nó sẽ đụng với bất kỳ mạng 10.x thật nào tôi tình cờ tham gia; quán cà phê, không gian làm việc chung và rất nhiều văn phòng dùng đúng dải đó. 198.18.0.0/15 là dải dành cho đo kiểm hiệu năng (benchmarking) theo RFC 2544. Nó được dành riêng, không bao giờ được định tuyến trên internet công cộng, không nằm trong danh sách loại trừ của WARP, và không mạng thông thường nào dùng tới nó. Các địa chỉ IPv6 là ULA (fd00::/8) cũng vì lý do đó.

Còn vì sao lại có IPv6 thì mới là câu chuyện thú vị hơn. Khi địa chỉ v4 đã chạy, tôi thử từ điện thoại qua wifi, mọi thứ ổn, và tôi coi như xong. Dùng 5G thì không chạy. Agent báo connected, đường hầm khỏe mạnh, Access cũng ổn; phép thử qua wifi đã chứng minh tất cả những điều đó. Vấn đề là mạng di động bây giờ phần lớn chỉ có IPv6. Điện thoại hoàn toàn không có IPv4 gốc, và nó truy cập địa chỉ v4 kia qua bộ chuyển đổi 464XLAT của nhà mạng, thứ nằm bên ngoài đường hầm khi danh sách include chỉ chứa một tiền tố v4. Lưu lượng đi ra internet công cộng, nơi 198.18.0.0/15 không được định tuyến, và bị bỏ đi không một tiếng động. Không có lỗi nào trên điện thoại, không có gì trong log của connector.

Cách sửa là cấp cho mỗi máy một địa chỉ thứ hai mà điện thoại truy cập được trực tiếp qua IPv6, rồi thêm nó vào các tuyến và vào danh sách include. Giờ các địa chỉ fd12:3456:789a:: chính là thứ mà client SSH trên điện thoại thật sự dùng khi chạy dữ liệu di động.

Giảm tải: laptop chỉ còn là một cái terminal

#

Đây mới là phần mà cả hệ thống này tồn tại để phục vụ.

Mô hình và fine-tuning. Ollama chạy trên devbox và bind vào 127.0.0.1:11434. Phần còn lại của LAN văn phòng không nhìn thấy nó, huống gì internet. Trên laptop, nó xuất hiện ở https://devbox-ollama.ssh.test, hoặc dưới dạng một cổng trần cho những công cụ cần thế:

OLLAMA_HOST=127.0.0.1:11435 ollama list

Là 11435 chứ không phải 11434, và tôi cố ý: 11434 là cổng mặc định của chính Ollama, nên nếu có ngày laptop cũng chạy một Ollama cục bộ, hai bên sẽ tranh nhau cổng đó, và tùy cái nào khởi động trước mà tôi có thể âm thầm nhận câu trả lời của devbox từ cái Ollama “cục bộ”.

Hiệu quả thực tế là khi tôi làm một tính năng AI, mô hình mà nó gọi chạy trên GPU của máy trạm chứ không phải của laptop, dù tôi đang ở đâu. Các lượt đánh giá (evaluation), việc tạo embedding cho cả đống tài liệu, một lần fine-tune: tất cả chạy trên devbox, và quạt laptop thì cứ im. Khi đang làm prototype một agent, tôi có thể trỏ nó tới một mô hình cục bộ trên máy trạm và cho nó chạy hết vòng gọi công cụ này đến vòng khác (tool calling) mà không tốn hóa đơn API nào, rồi chuyển sang mô hình được host khi vòng lặp đã đúng.

Agent chạy dài. Một phiên agent chạy cả tiếng đồng hồ không nên phụ thuộc vào việc nắp laptop có mở hay không. Chạy nó trên devbox thì laptop chỉ còn là một ô cửa sổ nhìn vào: gập máy lại, lát sau ssh devbox từ bất cứ đâu tôi đang ở, hay từ điện thoại, và nó vẫn còn đó. Trước khi có đường hầm, điều này chỉ làm được ở văn phòng, mà đó lại chính là nơi tôi không cần đến nó.

Build và cụm máy. Cụm trên devbox có registry riêng, nên image có thể được build và push ngay trên máy trạm, cạnh nơi chúng sẽ chạy, thay vì upload từ laptop qua wifi khách sạn. Dashboard của cụm, dashboard của ingress và giao diện của registry đều là các hostname *.ssh.test trên laptop.

Vòng lặp phát triển di động. Điện thoại ở cùng mạng riêng với laptop, và các dev server trên laptop cũng có hostname công khai nằm sau Access. Vậy nên tôi có thể mang một bản build native của ứng dụng ra khỏi tòa nhà, dùng 5G, và nó vẫn nói chuyện với API đang chạy trên bàn làm việc của tôi. Hoặc với API trên devbox, nếu tôi để nó chạy ở đó. Trước đây, vòng phản hồi trên thiết bị thật qua mạng di động thật đồng nghĩa với việc triển khai lên một staging server dùng chung. Giờ nó chỉ còn là lưu một tệp.

Có một cái bẫy ở đây, nên biết trước khi bạn đi debug nó như lỗi của ứng dụng. Access cũng bảo vệ cả hostname WebSocket, mà client WebSocket native thì không phải trình duyệt. Nó không mang cookie CF_Authorization, nên kết nối từ bản build native tới WebSocket server bị chặn ngay ở edge với mã 403, trông chẳng giống lỗi do server của bạn trả về chút nào. Các tab trình duyệt thì không sao vì chúng đã giữ cookie từ lúc đăng nhập. Với mọi thứ không phải trình duyệt (ứng dụng native, một script, một agent gọi API dev), lời giải là một service token của Access, gửi dưới dạng hai header:

CF-Access-Client-Id:     <client_id>
CF-Access-Client-Secret: <client_secret>

Bản thân token không cấp quyền gì. Access chỉ chấp nhận nó ở những ứng dụng có policy nêu tên nó, nên phạm vi của nó đúng bằng danh sách hostname dev, không rộng hơn. Tôi xếp policy của nó vào quyết định non_identity thay vì allow, để trong audit log nó vẫn hiện ra là một bí mật dạng bearer, chứ không phải một người đã đăng nhập.

Những chỉ số internet không bao giờ thấy

#

Nửa còn lại của điều tôi muốn là khả năng quan sát. Phần lớn những thứ cho bạn biết một hệ thống đang chạy thế nào, một cách đúng đắn, đều không công khai. Trên devbox, đó là:

• dashboard của ingress proxy, và giao diện tracing chứa trace của nó
• một dashboard cho cụm Kubernetes
• giao diện của container registry (chỉ đọc)
• danh sách mô hình của Ollama và những gì đang được nạp lúc này
• docker info và số liệu thống kê của container

Không thứ nào trong số đó có hostname công khai, và sẽ không bao giờ có. Chúng được bind vào loopback hoặc IP dịch vụ của cụm, truy cập qua một đường chuyển tiếp SSH mà bản thân nó lại chạy trên đường hầm. Một ứng dụng giám sát trên điện thoại đọc docker info --format '{{json .}}' qua SSH xuyên WARP, nên từ đâu tôi cũng xem được các container của mình có đang chạy không, hay có thứ gì đã ngốn hết bộ nhớ.

Chính ứng dụng đó giúp tôi tìm ra một lỗi nhỏ đáng kể lại. sshd dành cho đường hầm trên Mac vẫn đang để LogLevel DEBUG2 từ hồi tôi debug nó. Với -e, sshd ghi log ra stderr, và với một phiên SSH thì stderr đó chính là stderr của kênh SSH. Output của mọi lệnh đều trả về kèm thêm dòng debug2: do_setup_env: set TMPDIR ở cuối, và ứng dụng trên điện thoại, vốn gộp hai luồng lại, nhận được JSON hợp lệ theo sau là một dòng log, parse thất bại, rồi hiển thị toàn bộ như một lỗi. Đổi sang LogLevel INFO là xong. Debug xong nhớ trả log level về như cũ.

Cũng có chủ đích không kém là những thứ tôi không đưa lên mạng này. Các đường hầm autossh cũ còn truy cập tới vài router trên mạng của người khác mà tôi giúp trông coi. Những router đó không có hostname công khai và không có tuyến WARP. Một trang quản trị router nằm trên internet là một rủi ro, dù có đăng nhập chắn phía trước, và đó cũng không phải mạng của tôi để mà mở rộng.

Access là bắt buộc

#

Hostname của một Cloudflare Tunnel nằm trên internet công cộng ngay khi bản ghi DNS của nó tồn tại. Không có tường lửa nào đứng trước nó; không mở cổng chính là mục đích của cả việc này. Lớp bảo vệ phải đến từ edge của Cloudflare, và đó là việc Access làm. Nó từ chối chuyển tiếp bất kỳ yêu cầu nào cho tới khi người truy cập chứng minh được mình là ai, nên một công cụ quét chưa xác thực không bao giờ chạm tới được laptop. Điều đó quan trọng, vì đây là các dev server: một traceback ở chế độ debug kèm cả settings, một JavaScript bundler mở toang. Không thứ gì đằng sau các hostname này được làm ra để đối mặt với internet.

Policy chỉ cho phép chính các địa chỉ email của tôi, không gì khác, với hai cách chứng minh là mã PIN dùng một lần gửi qua email và đăng nhập một lần (SSO). Phiên đăng nhập kéo dài tám tiếng, vì mối đe dọa thực tế là một chiếc laptop bỏ mở ở quán cà phê với cookie có hạn cả ngày, chứ không phải ai đó dò mã PIN bằng brute-force.

SSH được xác thực hai lần, bởi hai hệ thống không hề biết đến nhau. Access quyết định một luồng TCP có được phép tới sshd hay không; sshd thì vẫn đòi khóa của tôi. Mất một trong hai cũng không mở được máy. sshd dành cho đường hầm trên Mac còn tin tưởng SSH CA của Cloudflare, nên Access có thể đăng nhập cho tôi bằng một chứng chỉ ngắn hạn được cấp từ phiên SSO, trong khi authorized_keys vẫn chạy song song, để một cấu hình Access bị hỏng không thể khóa tôi ra khỏi chính laptop của mình.

Phần tôi hài lòng nhất lại là một chi tiết nhỏ. Việc lộ ra ngoài xảy ra khi ba thứ cùng khớp: một bản ghi DNS, một connector đang chạy và một zone đang hoạt động. Chúng trở thành đúng vào những thời điểm khác nhau, theo thứ tự tôi không kiểm soát được; zone tự chuyển sang active, vào một lúc nào đó sau khi nameserver được đổi, rất có thể trong lúc chiếc Mac đang ngủ. Vậy nên launch agent không chạy cloudflared trực tiếp. Nó chạy một bước kiểm tra trước (preflight): đọc các hostname từ chính cấu hình của đường hầm, hỏi Access API xem hostname nào đã được bảo vệ, và từ chối khởi động nếu còn cái nào chưa:

HOSTNAMES=$(grep -E '^\s*-\s*hostname:' "$CONFIG" | sed -E 's/.*hostname:\s*//' | sort -u)
PROTECTED=$(curl -fsS -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/access/apps?per_page=100" \
    | python3 -c 'import sys,json; print("\n".join(a.get("domain","") for a in json.load(sys.stdin)["result"]))') \
    || { echo "could not reach the Access API. refusing (fail closed)."; exit 1; }

for h in $HOSTNAMES; do
    grep -qxF "$h" <<<"$PROTECTED" || { echo "NOT starting: $h has no Access app"; exit 1; }
done
exec cloudflared tunnel --config "$CONFIG" run

Launch agent có KeepAlive, nên một lần từ chối sẽ tự thử lại sau mỗi 30 giây, và đường hầm tự lên khi các Access app đã tồn tại. Thất bại theo hướng đóng (fail closed) thì cái giá là một lần gián đoạn. Thất bại theo hướng mở (fail open) thì cái giá là bị lộ. Tôi biết mình thà phải giải thích chuyện nào hơn.

Bốn chỗ khiến tôi vấp

#

Mọi thứ ở trên giờ đều chạy. Nhưng trên đường tới đây, ba trong bốn chỗ có cùng một kiểu: thứ bị hỏng không sinh ra lỗi ở bất cứ đâu, còn những phần tôi nhìn thấy được thì đều báo khỏe mạnh.

Tuyến và danh sách include là hai danh sách khác nhau. Một tuyến của đường hầm khiến Cloudflare sẵn lòng mang một địa chỉ tới đúng connector. Danh sách include của WARP mới là thứ khiến client gửi nó đi ngay từ đầu. devbox không truy cập được từ điện thoại vì các tuyến của nó đã có, nhưng danh sách include vẫn chỉ chứa địa chỉ của chiếc Mac. Điện thoại bỏ gói tin ngay tại máy, connector không hề thấy luồng nào, và dashboard nào cũng xanh. Mỗi máy mới đồng nghĩa với việc thêm địa chỉ của nó vào cả hai nơi.

Địa chỉ IPv4 viết cứng trên mạng di động chỉ có IPv6. Đã kể ở trên: chạy trên wifi, hỏng trên 5G, không có lỗi. Nếu một tuyến WARP chạy trên wifi mà không chạy trên dữ liệu di động, trong khi Agent vẫn báo connected, thì vấn đề nằm ở định tuyến, không phải ở đường hầm.

sshd của macOS đằng sau cloudflared. macOS khởi động sshd bằng cơ chế kích hoạt qua socket của launchd, mỗi kết nối một tiến trình sshd -i sống ngắn. Đằng sau cloudflared, banner tới được client rồi luồng bị cắt trước khi chuỗi nhận dạng của client kịp gửi ngược lại, nên mọi lần đăng nhập đều chết ở kex_exchange_identification. Tôi đã xác nhận từ cả hai đầu và tái hiện được bằng một bộ chuyển tiếp TCP thuần, qua đó loại trừ Cloudflare. Cách sửa là chạy thêm một sshd -D độc lập thứ hai trên 127.0.0.1:2222 và các địa chỉ loopback của WARP, chạy dưới user của tôi, chỉ để làm origin cho đường hầm. Remote Login trong System Settings không bị đụng tới. devbox chạy Linux với một sshd sống lâu bình thường, nên chưa bao giờ gặp vấn đề này.

Những trường cấu hình không còn tồn tại. Các ví dụ cũ vẫn ghi warp-routing: enabled: true trong cấu hình đường hầm. cloudflared 2026.8 từ chối thẳng trường đó. WARP routing được bật hễ khối cấu hình tồn tại và có một tuyến trỏ tới đường hầm. Ít ra cái này còn báo lỗi, mà sau ba vụ kia thì như thế đã là hào phóng lắm rồi.

Những gì đã thay đổi

#

Tóm lại một cách thành thật: tôi không còn chọn chỗ làm việc dựa trên chỗ đặt phần cứng nữa. Laptop là một bàn phím tốt, một màn hình tốt với thời lượng pin dài, và nó không cần phải hơn thế. Máy trạm gánh phần việc nặng dù tôi đang ở đâu. Điện thoại là một thiết bị kiểm thử thật trên một mạng thật, chứ không phải thứ bị buộc vào wifi văn phòng. Và những phần của hệ thống mà tôi dùng để xem nó đang làm gì thì chỉ cách tôi một cú bấm, còn với người khác thì chúng không hề tồn tại.

Ở quy mô này, mọi thứ nằm gọn trong gói Zero Trust miễn phí của Cloudflare. Cái giá tôi phải trả là thời gian, và một tệp README mà tôi mừng vì đã viết, vì nếu không thì mỗi lỗi ở trên đều sẽ lại là một bí ẩn mới ở lần gặp thứ hai.

Nếu bạn đang tính làm điều gì đó tương tự, đây là những câu tôi sẽ hỏi về hệ thống của bạn:

1. Thứ gì đang chạy trên laptop của bạn chỉ vì laptop là cái máy duy nhất bạn luôn truy cập được?
2. Điện thoại của bạn có truy cập được dev server qua dữ liệu di động không, chứ không chỉ qua wifi văn phòng? Hãy thử trên 5G, đừng thử trên wifi.
3. Dashboard nào của bạn đang công khai chỉ vì đó là cách dễ nhất để xem nó từ bên ngoài? Mỗi cái như thế đều là ứng viên để chuyển sang một tuyến riêng.
4. Nếu ngày mai một hostname của đường hầm được bật lên mà chưa có Access app, thứ gì sẽ chặn nó lại? Nếu câu trả lời là “tôi sẽ nhớ”, hãy viết bước preflight.
5. Các địa chỉ riêng của bạn có nằm trong một dải mà những mạng bạn ghé qua sẽ không bao giờ dùng không?