Vì sao tuyến mạng con Tailscale đã được phê duyệt vẫn hết thời gian chờ

Việc phê duyệt trong bảng điều khiển quản trị trông như bước cuối cùng, nhưng không phải. Trước hết ứng dụng hết thời gian chờ, và chỉ sau đó bạn mới thấy bộ định tuyến đang trực tuyến và tuyến đã được phê duyệt. Phê duyệt là bước phân phối, không phải quyền và không phải bảo đảm chuyển tiếp. Bốn giai đoạn phải khớp nhau trước khi gói tin đến được máy chủ phía sau bộ định tuyến mạng con, và mỗi giai đoạn có thể thành công trong khi giai đoạn kế tiếp thất bại. Hãy xử lý theo thứ tự và dừng ở giai đoạn đầu tiên không đứng vững.

Bốn giai đoạn, một thất bại

Bộ định tuyến quảng bá tiền tố, tailnet phê duyệt quảng bá đó, máy khách chấp nhận tuyến nhận được, và chính sách truy cập cho phép kết nối cụ thể. Đó là bốn quyết định riêng biệt do ba thành phần khác nhau đưa ra. Vì vậy một tuyến đã được phê duyệt chỉ nói rằng mạng đã là một phần của bảng định tuyến tailnet.

Giai đoạn thứ tư bị bỏ qua nhiều nhất, vì ba giai đoạn đầu tạo ra trạng thái nhìn thấy được. Một quyền bao phủ địa chỉ tailnet của chính bộ định tuyến không tự động bao phủ mạng con riêng phía sau nó. Đó là các đích khác nhau, và chính sách được đánh giá theo từng đích.

Trên Linux, giai đoạn thứ ba cũng có một mặc định khiến người ta ngạc nhiên: chấp nhận tuyến mạng con là tùy chọn. Nhiều máy khách có giao diện đồ họa chấp nhận tuyến được quảng bá theo mặc định, nên một đội máy hỗn hợp có thể cho thấy một máy lỗi trong khi các máy khác vẫn chạy.

Xác nhận cài đặt trên máy bị lỗi thay vì giả định nền tảng. Tuyến chưa bao giờ là phần thiếu trên những máy đang chạy, nên hãy để chúng chứng minh phía tailnet khỏe mạnh. Tài liệu của Tailscale về bộ định tuyến mạng con bao gồm phê duyệt, chấp nhận tuyến ở máy khách và giai đoạn chính sách.

Kiểm tra tuyến nơi máy khách chạy

Bắt đầu từ máy khách bị lỗi, không phải từ bộ định tuyến. Xác nhận tuyến tồn tại và cài đặt máy khách cho phép chấp nhận tuyến.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Lệnh thứ nhất hiển thị danh sách máy ngang hàng và liệu bộ định tuyến mạng con có thể truy cập được; lệnh thứ hai in các tùy chọn của máy khách bao gồm cờ chấp nhận tuyến; lệnh thứ ba hỏi nhân hệ điều hành sẽ dùng giao diện nào cho một máy chủ thực trong mạng con. Nếu lệnh cuối cùng nêu giao diện vật lý thay vì giao diện Tailscale, tuyến chưa bao giờ vào bảng. Tuyến bị thiếu là vấn đề phía máy khách, không phải vấn đề phê duyệt. Hãy sửa nó trước khi xem chính sách.

Để chấp nhận tuyến trên Linux, hãy kết nối lại với cờ thay vì giả định nó đã được đặt: tailscale up --accept-routes. Máy khách đã tham gia với cờ khác sẽ giữ chúng cho đến khi bị thay đổi, nên hãy kiểm tra cài đặt hiện tại trước khi thêm cờ khác. Chạy lại lệnh thứ nhất sau thay đổi sẽ cho thấy tuyến trong bảng.

Chứng minh chuyển tiếp và đường về

Phê duyệt không cấu hình bộ định tuyến để chuyển tiếp gói tin và không sắp đặt câu trả lời. Cả hai là vấn đề cấp máy chủ ở phía LAN của bộ định tuyến. Hãy kiểm tra chúng trên bộ định tuyến, không phải trên máy khách.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Lệnh thứ nhất phải báo 1, nếu không nhân sẽ bỏ gói tin đã chuyển tiếp. Lệnh thứ hai cho thấy việc che giấu tuyến mạng con có viết lại nguồn hay không, đây là hành vi mặc định và thường là điều bạn muốn. Lệnh thứ ba cho thấy yêu cầu có đến đích và có gì trở về hay không; yêu cầu không có trả lời là vấn đề đường về, không phải vấn đề phê duyệt. Đọc ba kết quả cùng nhau trước khi thay đổi bất kỳ kết quả nào.

Nếu việc che giấu đã bị tắt, mạng đích cần tuyến trở về các địa chỉ tailnet, và mỗi chặng ở giữa phải biết điều đó. Bật lại che giấu là cách sửa nhanh nhất cho một dịch vụ, nhưng đánh đổi bằng việc ẩn địa chỉ gốc của máy khách khỏi đích. Sự đánh đổi đó quan trọng khi đích ghi lại địa chỉ nguồn để kiểm toán, nên hãy quyết định có chủ đích thay vì lật cờ trong lúc sự cố. Ghi lại lựa chọn bạn đã làm, vì người tiếp theo sẽ chỉ thấy một trong hai hành vi.

Đọc quy tắc truy cập cho tài nguyên

Khi tuyến đã có và việc chuyển tiếp đã được chứng minh, nghi phạm còn lại là chính sách. Đọc quyền được cho là cho phép kết nối và kiểm tra đích của nó, không chỉ nguồn. Danh tính của chính máy khách cũng phải khớp với bộ chọn của chính sách, nên hãy ghi lại từ chính máy bị lỗi.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Đầu ra trạng thái xác định địa chỉ của chính máy khách và các máy ngang hàng mà nó thấy, và bộ chọn nguồn của chính sách phải khớp với những thứ đó. tailscale ping chứng minh đường tailnet đến chính bộ định tuyến mạng con; nó phân giải tên máy ngang hàng và địa chỉ tailnet, không phân giải máy chủ bên trong một mạng con được quảng bá. Lệnh thứ ba gửi một ICMP echo bình thường qua tuyến mạng con, nên kết quả của nó mô tả đích thay vì bộ định tuyến. Từ chối ở cấp tailnet thường trở về dưới dạng từ chối, trong khi gói tin đi ra và không bao giờ trở lại sẽ hết thời gian chờ.

Tên bị lỗi là câu hỏi khác với địa chỉ bị lỗi; hãy phân giải máy chủ trực tiếp trước khi đổ lỗi cho tuyến. Viết quyền theo nhu cầu thực tế của tài nguyên chứ không phải toàn bộ mạng con. Mở cả một /24 để một ứng dụng hoạt động là cách một yêu cầu hẹp trở thành một quyền rộng mà sau đó không ai dám gỡ bỏ.

Nếu mục tiêu là lối ra internet chứ không phải mạng con riêng, thành phần đúng là một nút ra, không phải bộ định tuyến mạng con, và chính sách cũng như định tuyến khác nhau tương ứng. Hãy kiểm tra quyết định đó trước khi mở rộng một quyền. Nút ra thay đổi tuyến mặc định; bộ định tuyến mạng con chỉ quảng bá một tiền tố.