Pi 하나에 Pi-hole와 VPN: 운영체제는 아직 지원되나요?

Pi-hole와 VPN을 함께 둔 상자에서는 두 가지가 뒤섞입니다. 설치한 배포판 계열과, 구성 요소가 실제로 지원하는 릴리스 및 아키텍처입니다. 이미지를 부팅하는 보드는 커널이 동작함을 증명할 뿐, Pi-hole의 FTL 바이너리와 VPN 설치 프로그램이 같은 사용자 공간을 겨냥한다는 것을 증명하지 않습니다. 진짜 시험은 보드 지원, 릴리스 브랜치, 패키지 아키텍처, 스스로 운영할 수 있는 업그레이드 경로의 사방 겹침입니다. 이 네 다리 중 하나만 잃어도 기기는 이번 주에는 동작하고, 다음 보안 업데이트에서 발목을 잡습니다.

지원을 정하는 것은 릴리스 브랜치이지 계열 이름이 아닙니다

프로젝트가 아직 어느 릴리스로 테스트하는지 묻고, 답을 Debian이 아니라 버전 문자열로 적으세요. Pi-hole의 사전 요구 사항 페이지는 지원 운영체제와 미리 빌드된 FTL 아키텍처를 두 개의 별도 요구 사항으로 나열하고, 지원을 배포판 자체가 아직 유지하는 릴리스로 제한하며, 지원 목록 안에서도 변형이나 특이한 구성이 실패할 수 있다고 경고합니다. 그 표현이 중요합니다. 지원되는 계열이 그 구성원 전부를 덮지는 않습니다.

Pi에서 아직 부팅되는 오래된 이미지는 지원의 증거가 아닙니다. 보드는 멀쩡하고 패키지 색인은 낡았으며, 불일치는 나중에, 설치 프로그램이 릴리스가 더는 만족시킬 수 없는 의존성을 끌어올 때 드러납니다.

VPN 쪽은 부품이 더 많고 각자 창이 있습니다. 터널 데몬, 그 설정을 쓰는 설치 도우미, 공급자의 클라이언트 앱, 배포판의 통합 패키지는 네 개의 별도 프로젝트입니다. 배포판을 인식하는 설치 프로그램과 릴리스가 계속 돌릴 수 있는 서비스를 만드는 설치 프로그램은 서로 다른 주장입니다. 데몬 자체의 플랫폼 목록을 찾아보고, 이어서 실행하려는 도우미가 그 릴리스 이후에 손댄 적이 있는지 찾아보세요. 프로젝트가 이름 붙은 릴리스까지만 지원을 밝힌다면, 직접 부팅해 보기 전까지 다음 릴리스를 미검증으로 취급하세요.

바이너리 대상과 보유한 사용자 공간을 맞추세요

아키텍처는 더 조용한 실패입니다. 32비트 사용자 영역을 둔 64비트 커널은 여러 보드에서 실제로 지원되는 조합이며, 32비트 FTL 바이너리를 불평 없이 돌립니다. arm64용으로만 배포되는 것을 설치하는 순간까지는요. 이미지를 고르기 전에 두 쪽을 모두 출력하고, 그 결과를 메모 옆에 두세요.

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

두 아키텍처 줄이 서로 맞지 않으면 혼합 구성입니다. Pi-hole 단독으로는 굴러가지만, 두 번째 서비스가 네이티브 라이브러리를 요구하는 순간 약해집니다. 깨끗한 64비트 이미지로 다시 굽는 편이 불일치를 만든 툴체인을 다시 짓는 것보다 대개 빠릅니다.

보드 마케팅도 이것을 결정하지 못합니다. 메모리 크기와 CPU 모델은 패키지가 어느 libc에 링크되는지에 대해 아무 말도 하지 않습니다. 그러니 출력된 값으로 판단하고, 제품 페이지로 판단하지 마세요.

상자 하나, 서비스 둘, 네트워크의 주인 하나

첫 패키지가 올라가기 전에 주소 지정, 리졸버, 터널의 주인을 정하세요. 그렇지 않으면 두 서비스가 같은 임무를 주장하고 어느 쪽도 깔끔하게 이기지 못합니다. Pi에는 라우터가 나눠 주는 DHCP 풀 밖의 고정 주소를 주고, 터널은 자체 서브넷에 두세요. Pi에 192.168.50.10, 터널에 10.42.0.0/24라는 분할은 하나의 실행 가능한 안이며, 숫자 자체는 라우터가 이미 제공하는 것과 충돌하지 않는 한 임의입니다. 그다음 어떤 구성 요소가 53번 포트에서 응답하는지, 사용한다면 어느 것이 DHCP를 나누는지, 터널이 올라와 있는 동안 어느 것이 기본 경로를 갖는지 적으세요. 화면 없는 이미지에서 그 마지막 일은 NetworkManager나 systemd-networkd의 몫이고, 리졸버 설정까지 다시 쓰는 공급자 클라이언트를 설치하는 것이 사람들이 살아 있는 터널과 죽은 DNS로 끝나는 길입니다.

상자를 공유하는 것은 괜찮습니다. 역할을 공유하는 것은 아닙니다. Pi-hole는 53번 포트의 유일한 수신자가 되고 싶어 하고, VPN 데몬은 자기 DNS 설정을 클라이언트로 밀어 넣고 싶어 합니다. 클라이언트가 둘 중 누구를 믿을지 고르고, 다른 쪽은 비켜서도록 설정하세요.

가능하면 관리 경로를 터널 밖에 두세요. 리졸버와 터널이 함께 실패해도 LAN 주소에서 SSH는 닿아야 하므로, 관리 서비스는 둘 중 어느 것에도 의존해서는 안 됩니다.

다음 업그레이드를 선택의 일부로 만드세요

업그레이드할 수 없는 릴리스는 이미 받아들인 지원의 천장입니다. 기기가 집의 DNS를 떠맡기 전에 여분 카드에서 업그레이드 절차를 시험하고, 패키지 업그레이드로 충분하다고 가정하는 대신 브랜치를 건너뛰는 일에 대해 프로젝트가 무엇이라 하는지 읽으세요.

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

업그레이드가 성공한 듯 보이면서 아무것도 바꾸지 않는 흔한 이유는 보류된 패키지입니다. 보류를 일부러 하나씩 풀고, 어느 서비스가 고정을 필요로 했는지 기록하세요.

건너뛰기 전에 Pi-hole 설정, 고정 임대, 모든 터널 프로필을 내보내고 새 이미지에 복원할 수 있는지 확인하세요. 건너뛴 뒤에는 일반 클라이언트 DNS, 터널 뒤의 사설 자원, 재연결, 게이트웨이의 모든 포워딩 규칙을 시험하세요. 부팅되고 ping에 응답하는 상자는 거의 아무것도 통과하지 못한 것입니다.

어떤 단일 릴리스도 두 서비스에 맞지 않을 때

때로는 겹침이 비어 있습니다. VPN 도우미가 설치할 수 있는 Pi-hole 패키지보다 새로운 릴리스로 옮겨갔거나, 보드 제조사의 이미지가 둘 다보다 뒤처진 경우입니다. 그럴 때는 설치 프로그램을 만족시키려고 릴리스 메타데이터를 고치는 대신 역할을 분리하세요. 작은 기기 둘, 또는 기기 하나에 두 번째 서비스용 컨테이너 하나를 더하는 편이, 지원 이야기가 거짓에 기대는 기기보다 비용이 적습니다.

버전을 위조하는 것은 곧바로 거절해야 할 유일한 지름길입니다. 패키지 관리자는 릴리스 파일이 말하는 것을 믿으므로, 위조된 식별자는 두 프로젝트 어느 쪽도 디버깅을 도와주지 않을 설치를 낳습니다.

현재 릴리스 둘이 모든 것을 만족한다면, 추측 없이 업그레이드 노트를 따를 수 있는 쪽을 고르고 탐색을 멈추세요. 그리고 버전, 아키텍처, 서비스 소유자, 복원 단계를 한곳에 기록하세요. SD 카드를 다음으로 만지는 사람에게 네 가지 모두 필요하기 때문입니다.