VPN 클라이언트로서의 Pi: 관리자 하나인가, 자체 스크립트인가?

자기 자신의 아웃바운드 트래픽만 보호하면 되는 Raspberry Pi에는 현실적인 설계가 두 가지 있습니다. 네트워크 관리자가 터널을 소유하게 하거나, 터널을 소유하는 스크립트를 유지하는 것입니다. 둘 다 트래픽을 실어 나를 수 있습니다. 실패하는 지점이 다르며, 새벽 두 시에 원격으로 진단할 수 있는 실패가 선택할 가치가 있는 쪽입니다. 소유권, IPv6와 DNS가 개입될 때 전체 터널이 무엇을 뜻하는지, 그리고 터널이 끊기는 순간 무슨 일이 벌어지는지로 둘을 비교하십시오.

하나의 터널에 두 명의 소유자

설계 A는 시스템의 네트워크 관리자 안에 있는 프로필입니다. 가져온 OpenVPN 프로필이나 기본 WireGuard 연결이며, 부팅 시 Ethernet과 Wi-Fi를 올리는 같은 서비스가 활성화합니다. 설계 B는 클라이언트를 직접 실행하고 리졸버 구성을 편집하며 자체 경로와 방화벽 규칙을 설치하는 여러분의 유닛입니다. 둘 다 정당한 설계지만, 라우팅 테이블을 바꿀 권한이 누구에게 있는지에서 다릅니다.

소유자가 다르므로 실패도 다릅니다. A에서는 활성화되지 않은 프로필이 인터페이스를 올려 두고 터널을 내리며, 관리자의 로그가 이유를 알려 줍니다. B에서는 절반만 성공한 스크립트가 자기를 만든 프로세스가 끝난 뒤에도 남는 경로를 남깁니다. 둘을 함께 돌리는 것이 최악의 결과입니다. 두 프로세스가 기본 경로를 쓰고, 부팅 시 두 리졸버 편집이 경쟁하며, 교체해야 할 비밀이 두 벌이 됩니다.

터널마다 소유자를 하나 고르고 무엇이든 시험하기 전에 다른 쪽을 비활성화하십시오. 소유자가 둘이라는 것은 터널이 올라가 있는데 아무것도 해석되지 않을 때 볼 곳도 두 곳이라는 뜻입니다. 이 한 가지 규칙이 Pi VPN 스레드에서 설명되는 혼란스러운 상태의 대부분을 막습니다.

가져오기가 만드는 것과 만들지 않는 것

Raspberry Pi OS Bookworm 이후에서 기본 네트워크 구성 도구는 NetworkManager이므로 프로필은 클라이언트 터널의 자연스러운 집입니다. 가져오기에는 맞는 플러그인이 설치되어 있어야 하며, 없으면 지원되지 않는 연결 유형에 대한 메시지와 함께 실패합니다. 그것이 멈추고 플러그인을 설치하라는 정직한 신호입니다.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

가져오기는 프로필을 저장합니다. 상대편에 도달할 수 있음을 증명하지 않고, 파일의 모든 지시문이 변환을 견뎠다고 보장하지도 않습니다. 결과 연결을 다시 읽고 신원과 신뢰를 지니는 부분, 곧 인증서, 원격 호스트와 포트, 암호를 묻는지 저장하는지를 확인하십시오.

--ask 로 활성화하면 공용 머신의 셸 기록에 암호 문구를 남기지 않습니다. 무인 Pi라면 결국 프로필이 부팅 시 올라오기를 원하게 되는데, 이는 손으로 한 번 올리는 것과는 별개의 결정입니다.

전체 터널, 두 설계의 비교

전체 터널은 의도가 아니라 경로에 대한 주장이며, 두 설계는 그것을 다르게 표현합니다. 프로필 방식은 관리자에게 기본 경로와 리졸버 설정을 설치하라고 요청하고, 스크립트 방식은 스크립트가 말하는 대로 하며 아무것도 하지 않는 것도 포함합니다. 어느 설계도 지시받지 않으면 IPv6를 덮지 않으며, 손대지 않은 IPv6 기본 경로는 IPv4가 완벽해 보이는 동안 터널 밖으로 트래픽을 기꺼이 실어 나릅니다.

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

경로 조회에는 문서용 주소를 쓰고 검사해도 되는 호스트로 바꾸십시오. 첫 명령은 Pi가 보통 목적지에 어느 인터페이스를 쓸지 보여 주고, 두 번째는 IPv6 기본 경로가 아직 있는지 보여 주며, 세 번째는 어느 리졸버가 응답했는지 증명합니다. 전체 터널에 관한 어떤 주장도 믿기 전에 셋을 모두 읽으십시오.

공급자의 지침이 전체 터널을 약속하는데 IPv6 기본 경로가 살아 있다면 Pi는 새고 있습니다. 업링크에서 IPv6를 끄거나 프로필이 그것을 요구하도록 하십시오. 나중에 발견하는 대신 의도적으로 결정하십시오.

열린 실패와 닫힌 실패

터널이 끊기면 기본 경로를 잃은 라우팅 테이블이 그저 물리 업링크로 되돌아가고 트래픽은 평문으로 계속됩니다. 이것이 열린 실패이며, 무언가 막지 않는 한 두 설계의 기본 동작입니다. 대부분은 몇 주 뒤 방화벽 로그를 읽고서야 알게 됩니다.

닫힌 실패는 터널이 내려가 있을 때 원격 접속을 앗아가므로 관리 경로를 위한 의도적인 예외가 필요합니다. 한 가지 방법은 터널 밖에서 VPN 피어의 주소만 허용하는 규칙입니다.

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

운영 비용을 정직하게 비교하십시오. 프로필은 보통 이 규칙을 표현할 수 없으므로 닫힌 실패는 여러분을 스크립트 설계나 터널과 무관하게 규칙을 설치하는 작은 유닛 쪽으로 밀어냅니다. 어느 경우든 일주일 동안 거부를 기록하십시오. 조용한 거부는 고장 난 서비스와 똑같이 보이며, 사용자가 한 사이트가 더 이상 로드되지 않는다고 알릴 때 카운터가 필요할 것입니다.

화면 없는 Pi를 위한 선택

이미지가 이미 NetworkManager를 돌리고 있고 터널에 특별한 것이 필요 없으며 업링크를 자동으로 따르게 하고 싶다면 프로필을 택하십시오. 정책 라우팅, 목적지별로 고르는 여러 터널, 또는 터널이 올라오기 전에 존재해야 하는 닫힌 실패 규칙이 필요하다면 스크립트를 택하고 부팅 순서와 정리까지 모든 부분을 소유하십시오. 두 설계를 섞는 것은 어느 하나만 쓸 때보다 비쌉니다.

둘 사이의 이전은 대체로 순서의 문제입니다. 옛 소유자를 비활성화하고 낡은 경로나 리졸버 항목이 남지 않았는지 확인한 다음, 새것을 활성화하고 두 번 재부팅하십시오. 한 번의 재부팅은 두 번째가 드러내는 경쟁을 숨길 수 있습니다. 터널이 아니라 Pi를 시험하며 끝내십시오. 이름을 해석하고, IPv4로 무언가를 가져오고, 남겨 두었다면 IPv6로도 가져온 다음, 터널을 끊고 선택한 동작이 실제로 일어나는지 확인하십시오. ip link 의 인터페이스는 시험의 시작이지 끝이 아닙니다.