Pi-hole và VPN trên một Pi: hệ điều hành còn được hỗ trợ không?

Trên một hộp kết hợp Pi-hole và VPN, hai thứ bị lẫn lộn: họ phân phối bạn đã cài và bản phát hành cùng kiến trúc mà các thành phần thực sự hỗ trợ. Bo mạch khởi động được ảnh chứng minh nhân chạy; nó không chứng minh tệp nhị phân FTL của Pi-hole và trình cài VPN của bạn nhắm cùng một không gian người dùng. Phép thử thật là sự chồng lấn bốn mặt: hỗ trợ bo mạch, nhánh phát hành, kiến trúc gói và lộ trình nâng cấp mà chính bạn có thể điều khiển. Mất bất kỳ chân nào trong bốn chân đó, thiết bị chạy tuần này rồi bỏ mặc bạn ở lần cập nhật bảo mật tiếp theo.

Nhánh phát hành quyết định hỗ trợ, không phải tên họ

Hỏi dự án còn thử nghiệm với bản phát hành nào, rồi ghi câu trả lời dưới dạng chuỗi phiên bản chứ không phải Debian. Trang điều kiện tiên quyết của Pi-hole liệt kê hệ điều hành được hỗ trợ và kiến trúc FTL dựng sẵn như hai yêu cầu riêng biệt, giới hạn hỗ trợ ở những bản phát hành mà chính bản phân phối còn duy trì, và cảnh báo rằng biến thể hoặc cấu hình khác thường có thể thất bại ngay trong danh sách được hỗ trợ. Cách diễn đạt đó quan trọng: một họ được hỗ trợ không bao trùm mọi thành viên của nó.

Một ảnh cũ vẫn khởi động trên Pi của bạn không phải bằng chứng về hỗ trợ. Bo mạch vẫn ổn, chỉ mục gói đã cũ, và sự không khớp lộ ra sau này, khi trình cài kéo một phụ thuộc mà bản phát hành không còn đáp ứng được.

Phía VPN có nhiều phần hơn, mỗi phần có cửa sổ riêng: daemon đường hầm, trình trợ giúp cài đặt ghi cấu hình của nó, ứng dụng khách của nhà cung cấp và gói tích hợp của bản phân phối là bốn dự án riêng biệt. Một trình cài nhận ra bản phân phối của bạn và một trình cài tạo ra dịch vụ mà bản phát hành có thể duy trì chạy là hai tuyên bố khác nhau. Tra danh sách nền tảng của chính daemon, rồi tra xem trình trợ giúp bạn định chạy có được động tới kể từ khi bản phát hành đó ra mắt không. Nơi dự án chỉ tuyên bố hỗ trợ đến một bản phát hành được nêu tên, hãy coi bản tiếp theo là chưa được kiểm chứng cho đến khi chính bạn khởi động nó.

Khớp mục tiêu nhị phân với không gian người dùng bạn có

Kiến trúc là thất bại lặng lẽ hơn. Nhân 64-bit với vùng người dùng 32-bit là tổ hợp thực tế, được hỗ trợ trên vài bo mạch, và nó chạy tệp nhị phân FTL 32-bit không phàn nàn, cho đến khoảnh khắc bạn cài thứ gì đó chỉ phát hành cho arm64. In cả hai nửa trước khi chọn ảnh, và giữ kết quả bên cạnh ghi chú của bạn.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

Nếu hai dòng kiến trúc đó không khớp, bạn đang ở cấu hình hỗn hợp: dùng được cho riêng Pi-hole, mong manh ngay khi dịch vụ thứ hai muốn thư viện gốc. Ghi lại ảnh 64-bit sạch thường nhanh hơn dựng lại chuỗi công cụ đã tạo ra sự không khớp.

Tiếp thị bo mạch cũng không giải quyết việc này. Dung lượng bộ nhớ và mẫu CPU không nói gì về việc gói của bạn liên kết với libc nào, nên hãy quyết định theo các giá trị in ra, không bao giờ theo trang sản phẩm.

Một hộp, hai dịch vụ, một chủ sở hữu mạng

Quyết định ai sở hữu việc đánh địa chỉ, bộ phân giải và đường hầm trước khi gói đầu tiên được đưa lên, nếu không hai dịch vụ sẽ cùng đòi một nhiệm vụ và không bên nào thắng sạch. Cấp cho Pi một địa chỉ tĩnh ngoài nhóm DHCP mà router của bạn phát, và giữ đường hầm trên subnet riêng: 192.168.50.10 cho Pi và 10.42.0.0/24 cho đường hầm là một cách chia khả thi, và bản thân các con số là tùy ý miễn chúng không đụng với thứ router của bạn đã phục vụ. Rồi ghi lại thành phần nào trả lời trên cổng 53, thành phần nào phát DHCP nếu bạn dùng, và thành phần nào giữ tuyến mặc định khi đường hầm đã lên. Trên ảnh không màn hình, việc cuối đó thuộc NetworkManager hoặc systemd-networkd, và cài một ứng dụng khách của nhà cung cấp cũng ghi lại cấu hình bộ phân giải là cách người ta kết thúc với đường hầm sống và DNS chết.

Chia sẻ hộp thì ổn. Chia sẻ vai trò thì không. Pi-hole muốn là người nghe duy nhất trên cổng 53, còn daemon VPN muốn đẩy cài đặt DNS riêng của nó tới các máy khách, nên hãy chọn bên nào trong hai bên mà máy khách nên tin và cấu hình bên kia tránh ra đường.

Giữ đường quản trị ra ngoài đường hầm khi có thể. Nếu bộ phân giải và đường hầm cùng hỏng, bạn vẫn muốn SSH tiếp cận được trên địa chỉ LAN, và điều đó nghĩa là dịch vụ quản lý không được phụ thuộc vào bên nào.

Biến lần nâng cấp tiếp theo thành một phần của lựa chọn

Một bản phát hành bạn không thể nâng cấp là trần hỗ trợ mà bạn đã chấp nhận. Thử cơ chế nâng cấp trên một thẻ dự phòng trước khi thiết bị gánh DNS của nhà bạn, và đọc những gì dự án nói về việc nhảy giữa các nhánh thay vì cho rằng nâng cấp gói là đủ.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

Các gói bị giữ là lý do thường gặp khiến một lần nâng cấp trông thành công mà không đổi gì. Gỡ giữ có chủ đích, từng cái một, và ghi lại dịch vụ nào cần ghim.

Trước khi nhảy, xuất cấu hình Pi-hole, các hợp đồng thuê tĩnh và mọi hồ sơ đường hầm, và xác nhận bạn có thể khôi phục chúng trên ảnh mới. Sau khi nhảy, thử DNS thông thường của máy khách, tài nguyên riêng sau đường hầm, kết nối lại, và mọi quy tắc chuyển tiếp trên cổng. Một hộp khởi động và trả lời ping gần như chưa vượt qua gì.

Khi không bản phát hành đơn lẻ nào vừa cả hai dịch vụ

Đôi khi phần chồng lấn trống rỗng: trình trợ giúp VPN đã chuyển sang bản phát hành mới hơn gói Pi-hole bạn cài được, hoặc ảnh của nhà sản xuất bo mạch chậm hơn cả hai. Trong trường hợp đó hãy tách vai trò thay vì sửa siêu dữ liệu phát hành để làm vừa lòng trình cài. Hai thiết bị nhỏ, hoặc một thiết bị cộng một container cho dịch vụ thứ hai, tốn ít hơn một thiết bị mà câu chuyện hỗ trợ dựa trên lời nói dối.

Làm giả phiên bản là lối tắt duy nhất cần từ chối thẳng. Trình quản lý gói tin vào những gì tệp phát hành nói, nên một định danh giả cho bạn bản cài mà không dự án nào trong hai dự án sẽ giúp bạn gỡ lỗi.

Nếu hai bản phát hành hiện tại đáp ứng mọi thứ, hãy chọn bản mà bạn theo được ghi chú nâng cấp mà không phải đoán, và thôi tìm kiếm. Rồi ghi lại phiên bản, kiến trúc, chủ sở hữu dịch vụ và bước khôi phục ở một chỗ, vì người tiếp theo chạm vào thẻ SD sẽ cần cả bốn.