Tailscale: vào được dịch vụ nội bộ của khách mà không bắt IT mở một cổng inbound nào

Chỉ cần một câu là đội IT của khách gật đầu nhanh hơn hẳn: “Không cần mở cổng inbound nào cả.” Tài liệu chính thức của Tailscale viết đúng như vậy. Phần lớn thời gian bạn không phải mở cổng firewall nào, chỉ cần để máy nội bộ được khởi tạo kết nối TCP ra ngoài qua cổng 443.

Với một FDE, điều đó quan trọng hơn mọi tính năng khác. Thử hình dung tuần đầu của một dự án: bạn cần đọc database, gọi API nội bộ hoặc SSH vào máy chạy model, nhưng mọi thứ nằm sau NAT, và mỗi yêu cầu mở firewall lại phải chờ duyệt. Mỗi ngày chờ là một ngày chưa làm được việc thật.

Tailscale giúp rút ngắn khoảng chờ đó, với điều kiện bạn hiểu nó đủ rõ để giải thích cho người giữ chìa khóa.

Vì sao không cần mở cổng?

Trong bài “How Tailscale works”, Avery Pennarun mô tả nền tảng của Tailscale là WireGuard. Giao thức này tạo ra những đường hầm mã hóa rất nhẹ giữa máy tính, VM hoặc container của bạn. Trang chính thức của WireGuard gọi nó là một VPN đơn giản, nhanh và dùng mật mã hiện đại.

Phần đáng giá nằm ở cách hai đầu tìm thấy nhau. Tailscale dùng NAT traversal để thiết lập kết nối, nên không cần cấu hình firewall hay cổng công khai. Khi không đi thẳng được, lưu lượng sẽ chạy qua relay DERP. Theo Pennarun, relay này chỉ chuyển tiếp nguyên những gói tin đã mã hóa từ node này sang node khác mà không đọc được nội dung.

Đây chính là hai luận điểm bạn mang vào cuộc họp với đội bảo mật. Không có bề mặt tấn công mới nào hướng ra Internet. Và kể cả khi đi qua relay, bên trung gian cũng không đọc được dữ liệu.

Một buổi chiều ở site khách trông thế nào?

Thử hình dung khách hàng là một nhà máy. Họ có một API nội bộ và một database Postgres nằm trong mạng 10.0.0.0/24. Những máy này do đội vận hành quản lý, và họ không cho cài thêm phần mềm.

Lúc này subnet router là lời giải. Tài liệu của Tailscale định nghĩa đây là một thiết bị trong tailnet, đóng vai gateway để quảng bá route tới các thiết bị khác. Nhờ nó, những máy không cài Tailscale client vẫn truy cập được.

Bạn chỉ cần xin đúng một máy Linux trong mạng đó, cài Tailscale lên, cho nó quảng bá route của mạng con, và chỉ cần cho phép máy này kết nối ra ngoài qua TCP 443.

Bước tiếp theo mới là bước ăn điểm với khách: viết ACL. ACL của Tailscale mặc định từ chối, có hướng, và được thực thi ngay tại từng máy. Vì vậy bạn viết rule cho phép tài khoản của mình đi tới đúng cổng của API và đúng cổng Postgres, không gì hơn. Mọi đích còn lại trong mạng con tự động bị chặn mà không cần thêm dòng nào.

Nếu cần vào máy chạy model, Tailscale SSH cho phép Tailscale quản lý cả việc xác thực lẫn phân quyền cho kết nối SSH trong tailnet. Nó dùng khóa WireGuard tự sinh và hết hạn khi phiên kết thúc. Nghĩa là khi dự án đóng lại, không còn chiếc khóa SSH dài hạn nào của bạn nằm sót trên server của khách.

Giới hạn nằm ở đâu?

Tài liệu viết “phần lớn thời gian”, tức là vẫn có những trường hợp ngoại lệ. Có những mạng chặn luôn cả kết nối đi ra, hoặc chỉ cho đi qua proxy. Vì vậy, việc đầu tiên nên làm là hỏi khách xem máy trong mạng có mở được kết nối TCP ra cổng 443 hay không, trước khi hứa hẹn bất cứ điều gì.

Giới hạn thứ hai dễ bị bỏ qua hơn. Tài liệu nói rõ ACL không ảnh hưởng tới lưu lượng trong mạng nội bộ. Bản thân subnet router vẫn nói chuyện với cả mạng LAN như mọi máy khác, nên ACL chỉ kiểm soát ai trong tailnet được đi qua nó.

Hãy đặt router ở vị trí mà đội mạng của khách đồng ý, và nói thẳng điểm này với họ thay vì để họ tự phát hiện.

Giới hạn thứ ba liên quan đến việc thẩm định. Repo GitHub chính thức chứa phần lớn mã nguồn mở của Tailscale, gồm daemon tailscaled và CLI, theo giấy phép BSD-3-Clause.

Chữ “phần lớn” có nghĩa là không phải toàn bộ, và tailnet vẫn cần coordination server. Khách thuộc ngành bị quản lý chặt nhiều khả năng sẽ hỏi chuyện này, nên bạn cần trả lời chính xác thay vì nói “nó là open source”.

Nên học gì trước?

Đừng bắt đầu từ giao diện quản trị. Hãy bắt đầu từ ba khái niệm mạng mà Tailscale che bớt đi: NAT, route và nguyên tắc deny-by-default. Hiểu chúng, bạn sẽ debug được lúc kết nối rơi xuống relay hoặc lúc một route không được quảng bá.

Sau đó, hãy luyện viết ACL như viết code: hẹp, có review, có kiểm thử xem đích nào bị chặn. Trong CV, thay vì ghi chung chung “Tailscale”, hãy mô tả kết quả: “dựng truy cập cho đội ba người vào hai dịch vụ nội bộ của khách, không mở cổng inbound, quyền giới hạn theo ACL”.

Khi đọc JD của các vị trí FDE, nếu thấy công việc phải triển khai trong hạ tầng của khách, bạn nên chuẩn bị sẵn một câu chuyện cụ thể về cách mình từng vào được mạng nội bộ một cách an toàn.

Công cụ chỉ là một nửa câu chuyện. FDE nào mở được cánh cửa vào mạng của khách trong một buổi chiều, và giải thích được vì sao cánh cửa ấy an toàn, sẽ có thêm nhiều thời gian cho phần việc thật sự.