Cài ứng dụng Linux nghe như một chỉ dẫn duy nhất trên một Pi không màn hình, nhưng nó ẩn đi một lựa chọn giữa hai đường triển khai với ranh giới hỗ trợ khác nhau. Một là ứng dụng chính thức của nhà cung cấp, mang theo yêu cầu riêng về phân phối và kiến trúc. Còn lại là tệp cấu hình thủ công mà một ứng dụng khách chuẩn đã được hệ điều hành đóng gói sẵn sử dụng. Cả hai đều đến cùng một dịch vụ, và chúng không thể thay thế nhau về mặt bảo trì.

Câu hỏi về kiến trúc đến trước, vì một bo mạch 64 bit có thể đang chạy không gian người dùng 32 bit và ứng dụng chỉ cung cấp một trong hai.

Hai ranh giới hỗ trợ, không phải hai trình cài đặt

Đọc trang cài đặt hiện tại của nhà cung cấp cho ứng dụng bạn định dùng và đối chiếu với bo mạch: bản phát hành phân phối, kiến trúc gói và mọi yêu cầu về màn hình hoặc phiên. Việc Pi hỗ trợ vận hành 64 bit không cho biết không gian người dùng nào đang được cài, và đó chính là giá trị mà trình quản lý gói kiểm tra. dpkg --print-architecture và uname -m trả lời điều đó mỗi lệnh một dòng. Nếu bản phát hành hoặc kiến trúc nằm ngoài tập được ghi trong tài liệu, ứng dụng không được hỗ trợ ở đó dù có cài được.

Hỗ trợ cũng khác theo cách đóng gói. Một giới hạn được ghi cho một định dạng gói không tự động áp dụng cho bản dựng từ kho, và một bản phân phối phái sinh từ Debian không tự động là môi trường được hỗ trợ. Các gói cộng đồng và công thức cài đặt cũ mang mô hình bảo trì riêng, bạn có thể chấp nhận có chủ đích nhưng không nên tiếp nhận vô tình.

Ứng dụng cho những gì mà hồ sơ không cho

Ứng dụng chính thức không chỉ là kết nối: nó thường mang công tắc ngắt của nhà cung cấp, xử lý DNS và các công tắc tính năng, và nhà cung cấp hỗ trợ những hành vi đó như một bộ. Một hồ sơ thủ công giao cho ứng dụng khách chuẩn không thừa hưởng gì trong số đó. Ứng dụng khách thủ công sở hữu vòng đời kết nối và chính sách lỗi cục bộ, điều này ổn khi bạn tự cấu hình và đáng ngạc nhiên khi bạn cho rằng chúng đi kèm. Cả hai lựa chọn đều đến cùng các máy chủ; chỉ một lựa chọn bao gồm phần logic xung quanh.

Nếu một tính năng quan trọng, chẳng hạn chặn lưu lượng bên ngoài đường hầm, nó phải có trong cấu hình của bạn chứ không phải trong ứng dụng của nhà cung cấp.

WireGuard thủ công: những bước quan trọng

Nhà cung cấp ghi tài liệu về việc tạo cấu hình WireGuard cho ứng dụng khách tương thích chuẩn và khuyến nghị con đường đó cho thiết lập thủ công, giữ OpenVPN cho thiết bị cũ hơn. Tạo hồ sơ trong bảng điều khiển tài khoản, mang sang Pi và đặt ở nơi chỉ chủ sở hữu đọc được. Đừng bao giờ dán tệp vào một luồng hỗ trợ, vì tên tệp thân thiện không làm khóa riêng nhúng bên trong trở nên công khai được. Sau đó kiểm tra đường hầm bằng một yêu cầu duy nhất trước khi kết nối bất cứ thứ gì khác.

Việc ngừng sử dụng máy chủ là chi tiết vận hành mà người ta hay quên. Một điểm cuối chọn thủ công có thể bị thu hồi, và nhà cung cấp lưu ý rằng có thể cần cấu hình thay thế. Ghi lại hồ sơ dùng điểm cuối nào để sự cố về sau có thể chẩn đoán được.

Quyết định xem Pi có phải cổng kết nối không

Một đường hầm được các ứng dụng của chính Pi dùng không tự động trở thành cổng cho các thiết bị phía sau. Chuyển tiếp, định tuyến trả về, quyền sở hữu bộ phân giải và bất kỳ chính sách nào ngăn lưu lượng thoát ra ngoài đường hầm đều là thiết kế riêng với các chế độ lỗi riêng. Nếu có thiết bị khác trong phạm vi, hãy đánh giá chúng như trường hợp riêng thay vì cho rằng kết nối của Pi bao phủ chúng. Chính sự tách biệt đó giữ cho một triển khai nhỏ dễ bảo trì.

Sau đó chấp nhận vòng đời: một yêu cầu mới từ Pi, phân giải tên qua bộ phân giải dự kiến và hành vi khởi động hoặc kết nối lại mà bạn đã lên kế hoạch. Hãy kiểm chứng từng thứ thay vì cho rằng ứng dụng hay hồ sơ cung cấp.

Huyền thoại nên bỏ là cho rằng trình cài Linux và tệp WireGuard đại diện cho cùng một quyết định. Chúng là hai mô hình vận hành với hai chủ sở hữu khác nhau.

Bài viết liên quan