NetworkManager에서 OpenVPN 및 WireGuard 파일 가져오기가 실패합니다

GNOME 설정에서 파일에서 가져오기…를 선택했고, 공급업체 클라이언트와 함께 동작하는 프로필을 골랐는데, 대화상자는 목록에 아무것도 추가하지 않고 닫혔습니다. 두 번째 노트북에서는 가져오기가 완료되어 연결이 프로필 이름으로 나타났고, 그다음 첫 인증 요청에서 실패했습니다. NetworkManager는 여러분의 .ovpn 또는 wg-quick 파일을 있는 그대로 실행하지 않습니다. 파일을 파서에 넘기고, 파서가 그것을 NetworkManager 자체의 연결 형식으로 바꾸며, 그때부터 터널은 그 파싱된 객체로 만들어집니다. 비밀, 경로, DNS가 모두 거기서 나옵니다. 따라서 쓸모 있는 질문은 파일이 왜 깨졌느냐가 아니라 파싱이 일어났는지, 그리고 무엇을 남겼는지입니다.

가져오기가 실제로 파일에 하는 일

OpenVPN의 경우 파서는 플러그인 패키지 안에 있고, 그것이 만드는 연결은 org.freedesktop.NetworkManager.openvpn 같은 D-Bus 서비스를 가리킵니다. 플러그인이 없으면 파서도 없습니다. 유형이 nmcli에 알려지지 않고, 그래픽 VPN 추가 목록에 가져오기 항목이 아예 없을 수도 있습니다. WireGuard는 한 가지 중요한 점에서 다릅니다. NetworkManager는 1.30 계열부터 자체 WireGuard 설정을 가지고 있어 별도 플러그인 패키지가 없지만, wg-quick 읽기는 그것을 포함한 빌드에만 있습니다.

어느 쪽이든 파일은 한 번만 읽힙니다. 결과는 /etc/NetworkManager/system-connections/ 아래 keyfile로 기록되고, 연결 이름을 따르며, root 소유이고 키 자료를 담고 있어 다른 사용자는 읽을 수 없습니다. 그 keyfile이 이제 연결입니다. 이후 원본 .ovpn을 편집해도 아무것도 바뀌지 않습니다.

세 가지 증상은 세 단계에 속합니다. 가져오기 항목이 없거나 유형을 모르면 플러그인이나 버전이 빠진 것입니다. 지시문 이름을 언급하는 가져오기 오류는 파서가 파일을 읽고 일부를 거부했다는 뜻입니다. 연결은 있지만 한 번도 활성화되지 않으면 파싱된 객체가 불완전하거나 서버가 거부하는 것입니다. 무엇이든 편집하기 전에 세 경우 중 어느 것인지 판단하세요.

프로필을 디버깅하기 전에 플러그인을 확인하세요

플러그인이 없으면 손상된 프로필과 똑같아 보입니다, 그래서 먼저 패키지를 확인하세요. Debian과 Ubuntu에서는 OpenVPN 지원이 network-manager-openvpn과 데스크톱 도우미로 제공됩니다. Fedora에서는 NetworkManager-openvpn과 NetworkManager-openvpn-gnome, Arch에서는 networkmanager-openvpn입니다.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

그다음 절대 경로에서 가져오세요: nmcli connection import type openvpn file /home/you/profile.ovpn. 상대 경로도 보통 동작하지만, 디렉터리를 바꾼 셸에서는 빠른 가져오기가 우회로가 됩니다. WireGuard의 경우 nmcli --version을 확인하고 modprobe wireguard로 커널 쪽이 있는지 확인하세요. 모듈이 없는 머신에서 성공한 가져오기는 장치가 끝내 나타나지 않는 연결을 남깁니다. nmcli 참조는 import 하위 명령과 허용되는 유형 이름을 문서화합니다. type wireguard이 곧바로 거부된다면 그 빌드는 이 기능보다 오래된 것이며, 올바른 조치는 배포판 패키지나 백포트입니다. 구성을 임의의 디렉터리에 복사하고 무언가 읽어 주기를 바라는 것이 아닙니다.

.ovpn이 아니라 OpenVPN 연결을 읽으세요

연결이 생기면 파일을 다시 읽지 말고 파싱된 설정을 읽으세요: nmcli connection show "Work VPN" | grep -E '^vpn\.'. 필요한 것은 remote와 포트, 전송 방식, 신원 자료 — ca, cert, key, tls-auth 또는 tls-crypt — 그리고 인증 방식입니다. 개인 키 암호가 있는 프로필에서는 sudo nmcli --show-secrets connection show "Work VPN"을 추가하고 secret 플래그를 보세요. 0은 none이라 비밀이 keyfile에 있습니다. 1은 agent-owned, 2는 not-saved라 keyfile에 절대 기록되지 않습니다. 4는 not-required라 비밀이 전혀 필요 없습니다. 이것은 비트이지 척도가 아니므로 3은 단순히 agent-owned 더하기 not-saved입니다. 세션마다 한 번 묻는 비밀은 agent-owned (1)이며 에이전트가 요청합니다. 그를 위한 별도 플래그 번호는 없습니다. 플래그 불일치는 데스크톱 애플릿에서는 연결되고 스크립트나 부팅에서는 실패하는 흔한 이유입니다.

파서가 무엇을 버렸는지 가장 빨리 보는 방법은 플러그인에 파일을 다시 쓰게 하고 비교하는 것입니다: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. 그 차이에서 사라지는 지시문은 연결 시점에 존재하지 않습니다. 훅이 흔한 용의자입니다. script-security, up, down, route-up은 높은 권한으로 스크립트가 실행되기를 기대하며 의도적으로 넘겨지지 않습니다. 가져오기를 성공시키려고 검증을 낮추거나 추가 권한을 주지 마세요. 지원되지 않는 옵션은 보통 도달할 수 없는 서버가 아니라 플러그인의 기능 집합을 반영합니다. 그 동작은 NetworkManager 디스패처 스크립트나 서버 측 정책으로 옮기세요.

신원 필드가 살아남았는지도 확인하세요. CA 참조, remote-cert-tls, 그리고 프로필이 의존하던 이름 검사입니다. 이것들 없이 올라오는 연결은 그 주소에서 응답하는 무언가와 이야기하고 있을 수 있습니다.

wg-quick 파일이 아니라 WireGuard 연결을 읽으세요

wg-quick 파일은 셸 의미론을 가진 형식이고, 가져온 연결은 설정의 집합입니다. PrivateKey는 인터페이스의 개인 키가 되고, Address는 하나 이상의 IPv4 및 IPv6 주소가 되며, DNS는 NetworkManager의 resolver 속성으로 매핑되고, MTU는 wireguard.mtu로 매핑됩니다(wg-quick 자체의 기본값은 1420). 각 peer 블록은 공개 키, endpoint, 허용 IP, persistent keepalive를 가진 peer 항목이 됩니다. 무엇이 저장되었는지 nmcli --show-secrets connection show wg0로 출력하세요. peer 목록이 그 출력에 나타나지 않으면 keyfile을 읽으세요:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

살아남지 않는 것은 wg-quick의 셸 절반입니다. PreUp, PostUp, PreDown, PostDown, Table은 그 도구의 동작이지 WireGuard 인터페이스의 속성이 아니므로 가져온 뒤에는 아무것도 그것을 실행하지 않습니다. 원본이 기본 경로를 건드리지 않으려고 Table = off를 썼다면, 최신 NetworkManager 릴리스는 같은 목적으로 ip4-auto-default-route와 ip6-auto-default-route를 제공합니다. 연결이 스크립트처럼 동작한다고 가정하지 말고 명시적으로 설정하세요. 사용자 지정 경로를 밀어 넣던 훅은 그 경로를 연결의 라우팅 설정에 추가해야 하며, 그렇지 않으면 그냥 빠집니다.

연결에 정확히 하나의 소유자를 주세요

전형적인 후속 고장은 다음 부팅까지 동작하다가 루프에 빠지는 연결입니다. 보통 [email protected]이 이전 실험에서 아직 켜져 있었거나 공급업체 클라이언트가 자체 데몬을 띄우고 있었고, 두 소유자가 같은 목적지에 경로와 DNS를 쓰고 있었습니다. NetworkManager는 자기 경로로 resolver를 설정하고 wg-quick은 resolvconf를 통해 쓰며, 마지막에 쓴 쪽이 이깁니다. 그래서 이름 해석이 되다가 멈추고 다시 됩니다. systemctl status wg-quick@wg0, nmcli connection show --active, ip link show type wireguard을 확인한 다음, 메트릭을 조정하는 대신 두 번째 소유자를 비활성화하세요.

정말 둘 다 필요하다면 별도 인터페이스와 겹치지 않는 허용 IP를 주고, 기본 경로를 설치하는 쪽은 정확히 하나만 두세요. 메트릭이 다른 기본 경로 두 개는 분할 터널이 아니며, 두 번째로 시작하는 서비스가 결정하는 경쟁입니다. 재연결 후에는 적용된 상태를 다시 확인하세요. 한 번의 수동 resolver 편집으로 동작하게 만든 것은 가져오기가 완전하다는 증거가 아닙니다.

트래픽으로 검증하고 재부팅을 견디세요

연결을 nmcli connection up "Work VPN"로 올린 다음 아이콘을 믿지 말고 상태, 주소, 경로를 읽으세요: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default, 그리고 터널 안에서만 해석되는 이름의 실제 조회입니다. 핸드셰이크나 성공한 ping은 암호가 동작함을 증명할 뿐입니다. 포워딩, 분할 터널 접두사, 사설 DNS에 대해서는 아무 말도 하지 않으며, 바로 그 부분이 보통 깨집니다.

그다음 재부팅하고 반복하세요. autoconnect 동작, 이름이 바뀐 인터페이스, 장치 뒤에 로드되는 플러그인은 깨끗한 부팅에서만 보이는 고장입니다. journalctl -u NetworkManager -b --no-pager | tail -n 40은 이 부팅에서 데몬이 이 연결로 무엇을 했는지 보여 줍니다. 두 번째 컴퓨터에는 keyfile을 복사해 root 소유 모드 600으로 유지하거나, OpenVPN이면 nmcli connection export를 쓰고 만들어진 .ovpn을 다시 가져오세요. 내보내기 경로에는 WireGuard 대응물이 없으므로 그 방향은 파일 복사나 보호된 원본에서의 새 가져오기입니다.

짧게 정리하면 순서대로: 플러그인이나 NetworkManager 버전을 확인하고, 절대 경로에서 가져오고, secret 플래그를 포함한 파싱된 설정을 읽고, OpenVPN 내보내기를 원본과 비교하고, WireGuard 쪽의 훅과 경로를 확인하고, 두 번째 소유자를 비활성화한 뒤 재부팅 후 이름 해석과 경로 표를 검증하세요. 연결이 그 모두를 통과하면 그것을 시작한 프로필 파일은 보호된 저장소로 돌아갈 수 있습니다.