Raspberry Pi VPN 서버를 Ethernet으로 옮기는 방법

Pi를 Wi-Fi에서 케이블로 바꾸는 일은 오 분짜리 작업처럼 보입니다. 그리고 그렇게 유지되는 것은 이전을 하나가 아닌 네 개의 별도 설정으로 다룰 때뿐입니다. 클라이언트가 접속하는 엔드포인트 이름은 그대로 두고 그 아래 주소만 바꿀 수 있습니다. 실제로 깨지는 것은 예전 주소에 고정된 리스너, 아직 무선 리스를 가리키는 포트 포워딩, 또는 이미 은퇴시켰다고 생각한 인터페이스로 나가는 반환 경로입니다. 이 안내는 각 단계에서 복구 경로를 열어 두므로 실패한 전환은 재부팅 한 번으로 끝납니다.

무엇이든 뽑기 전에 네 명의 소유자를 기록하라

전환이 살아남을지를 네 가지 설정이 결정합니다. Pi 주소, OpenVPN 바인딩 주소, 라우터의 리디렉션 대상, 그리고 응답이 지나는 경로입니다. 케이블을 만지기 전에 네 가지를 모두 적어 두세요. 무선 리스가 사라지면 기기에서 예전 값을 더는 읽을 수 없기 때문입니다. 유선 인터페이스는 무선 프로필을 상속하지 않으며, Bookworm에서는 주소가 NetworkManager에 있고 Bullseye에서는 dhcpcd.conf에 있습니다. 무선 MAC 주소를 고정한 예약은 eth0에 대해 아무것도 말해 주지 않습니다. 새 주소는 자체 증거가 필요한 새 할당으로 다루세요.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

리스너가 두 번째 소유자입니다. 서비스가 특정 바인딩 주소로 시작했다면 소켓은 예전 인터페이스와 함께 죽습니다. 모든 주소에 바인딩하면 소켓은 살아남고 라우터 규칙만 고치면 됩니다.

리디렉션 대상과 반환 경로는 사람들이 건너뛰는 소유자입니다. 아직 10.42.7.24를 가리키는 포워딩은 들어오는 핸드셰이크를 Pi가 더는 갖지 않은 주소로 보내므로, 클라이언트는 서버 쪽 로그 한 줄도 없이 시간 초과로 끝납니다. 반환 경로는 두 링크가 잠깐 함께 살아 있을 때 중요합니다. Pi는 라우팅 테이블이 선호하는 인터페이스로 응답하는데, 그것이 항상 패킷이 도착한 인터페이스는 아닙니다. 아래 경로 조회는 커널이 어떤 소스를 고르는지 보여 줍니다.

새 주소를 믿기 전에 실제 소켓을 읽어라

설정 파일은 의도를, 소켓은 현실을 말합니다. 기억하는 설정을 믿는 대신 실행 중인 서비스에 무엇에 바인딩되었는지 물어보세요. OpenVPN 2.6 매뉴얼은 --local을 하나의 주소에 바인딩하는 것으로 정의하고, 생략하면 모든 인터페이스에 바인딩한다고 설명합니다.

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

상태 열이 아니라 로컬 주소 열을 읽으세요. 10.42.7.24:1194을 보여 주는 줄은 소켓이 곧 제거할 주소에 고정되었다는 뜻이고, 0.0.0.0:1194 또는 *:1194은 데몬이 인터페이스 변경을 스스로 따라간다는 뜻입니다. 주소가 고정되어 있으면 살아 있는 소켓을 손으로 다시 쓰지 말고 프로필을 고쳐 유닛을 재시작한 뒤, 서비스가 인증서와 키 파일에 여전히 닿는지 확인하세요.

당신을 접근 가능하게 유지하는 순서로 이전을 진행하라

여기서는 속도보다 순서가 중요합니다. 무선이 아직 동작할 때 유선 링크를 올리고, 새 주소와 반환 경로를 확인한 다음에 무선 프로필을 은퇴시키세요. 그 순서라면 대체가 증명될 때까지 작업 세션을 열어 둘 수 있습니다.

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

첫 번째 명령은 eth0이 의도한 주소를 받았는지 답하고, 두 번째는 커널이 외부 목적지에 쓸 소스 주소를 출력하므로 변경 전후에 실행하세요. 그 소스가 아직 무선 주소라면 유선 링크는 아직 선호 경로가 아니며, 외부 테스트는 OpenVPN과 무관한 이유로 실패합니다. 포워딩을 만지기 전에 라우팅 우선순위를 고치세요.

두 링크가 모두 살아 있으면 Pi는 무선 기본 경로를 선호할 수 있습니다. 먼저 설치되었거나 유선 링크의 메트릭이 더 높기 때문입니다. Bookworm에서 지원되는 설정은 연결의 ipv4.route-metric이고, Bullseye에서는 인터페이스별 metric 줄이 dhcpcd.conf에 해당합니다. 되돌리기 경로를 한 명령 거리에 두려면 무선 링크를 끄지 말고 우선순위를 낮추세요.

터널은 LAN이 아니라 외부에서 증명하라

소파에서 되는 VPN 연결은 보이는 것보다 적게 증명합니다. LAN 안에서 공인 주소로 가는 트래픽은 라우터가 일관성 없이 구현하는 hairpin이나 반사 규칙을 지납니다. 그래서 LAN 테스트가 통과해도 외부 경로가 깨져 있을 수 있습니다. 수락 테스트에는 셀룰러 데이터를 쓰는 휴대폰이나 네트워크 밖의 아무 호스트나 사용하세요. LAN 시도는 별도의 선택적 진단으로 남겨 두세요.

그다음 패킷이 도착하는 순서대로 로그를 읽으세요. 아무것도 없으면 핸드셰이크가 Pi에 닿지 않았다는 뜻이므로 리디렉션 대상이나 호스트 방화벽이 틀렸습니다. 시작했다가 멈추는 핸드셰이크는 키, 인증서, MTU를 가리킵니다. 완료되고 끊기는 세션은 보통 반환 경로나 두 번째 기본 경로를 뜻하며, 클라이언트 로그 줄 Initialization Sequence Completed이 터널 자체가 올라왔음을 알려 줍니다.

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

클라이언트가 다시 시도하는 동안 서버 로그에 아무것도 나타나지 않으면 OpenVPN 설정 읽기를 멈추고 리디렉션 대상으로 돌아가세요. 캡처는 도착 여부를 몇 초 만에 답하고, 응답 없는 수신 패킷은 문제를 경로로 좁힙니다.

한 단계 되돌리기를 유지하고 무선 프로필을 은퇴시켜라

유선 구성이 재부팅을 통과할 때까지 무선 프로필을 설치된 채로 두세요. nmcli con show은 필요한 프로필 이름을 나열하고, 삭제한 프로필은 최악의 순간에 기억에서 다시 만들어야 합니다. 인터페이스 이름, 주소 방식, 메트릭을 다른 네 값 옆에 기록하세요. 메모에서 입력할 수 있는 되돌리기는 다시 만들어야 하는 것보다 가치 있습니다.

무선 의존성을 은퇴시키는 것은 삭제가 아니라 속성 변경입니다. connection.autoconnect no을 설정하면 자격 증명과 주소 기록을 그대로 둔 채 Pi가 떠나온 네트워크에 다시 붙지 않게 됩니다.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

작업이 끝났다고 선언하기 전에 네 가지를 확인하세요. 리디렉션 대상이 유선 주소와 일치하는지, 리스너가 재시작을 견뎠는지, 외부 클라이언트가 핸드셰이크를 완료하는지, 재부팅 후에도 Pi가 유선 주소에서 응답하는지입니다. 재부팅은 실행 중인 커널에만 있던 할당을 잡는 가장 저렴한 방법입니다. 네 가지 중 하나라도 실패하면 무선 프로필을 sudo nmcli con up 명령으로 다시 올리고 기록한 값과 살아 있는 값을 비교하세요.