Keyfile인가 Netplan인가: VPN 프로필은 실제로 어디에 저장되는가

가져온 파일을 찾는 것은 쉬운 부분이며 흔히 잘못된 시작입니다. 중요한 것은 NetworkManager가 오늘 어떤 파일을 저장된 연결로 읽는가이며, 그것은 연결 식별자와 설치된 패키지가 실제로 사용하는 구성 백엔드에 달려 있습니다. 그 질문에 답하기 전에 가져오기를 편집하는 것이 바로 작동하는 VPN이 두 개의 반쯤 맞는 구성이 되는 길입니다.

가져온 파일은 저장된 프로필이 아닙니다

모든 VPN 문제 주위에는 세 가지 이름이 떠돕니다. 연결 이름, 가져온 파일 이름, 그리고 터널이 올라올 때 나타나는 가상 인터페이스입니다. 어느 것도 저장된 구성을 식별하지 못하며, 연결 이름은 편집할 수 있지만 그 뒤의 파일은 원래 식별자를 유지합니다.

읽기 전용 목록으로 시작하고 레이블이 아니라 식별자로 원하는 VPN을 고르십시오:

nmcli -f NAME,UUID,TYPE connection show

티켓에 붙여 넣는 어떤 목록에서도 엔드포인트 호스트 이름과 신원 레이블을 빼십시오. 유용한 부분은 유형과 식별자이고, 나머지는 낯선 사람에게 필요 없는 맥락입니다. 공유하기 전에 나머지를 가리고 그렇게 했다고 말하십시오. 빈칸이 무엇을 뜻하는지 아무도 궁금해하지 않도록.

keyfile 위치는 같은 뜻이 아닙니다

네이티브 keyfile 플러그인에서는 연결 파일이 세 디렉터리에 나타날 수 있으며, 그 차이는 편의가 아니라 지속성입니다.

런타임 사본을 편집하면 다음 시작까지는 성공한 것처럼 보이지만, 그때 변경이 증발하고 파일은 의문스럽게 되돌아간 것처럼 보입니다. 패키지가 제공한 사본을 편집하는 것은 업그레이드가 그것을 교체할 때까지 작동하며, 같은 교훈의 더 느리고 더 혼란스러운 판본입니다.

keyfile 문서는 존중할 만한 세부를 덧붙입니다. 그 파일에는 개인 키와 암호 문구가 들어 있을 수 있고, root가 아닌 사용자가 읽거나 쓸 수 있는 keyfile은 NetworkManager가 무시합니다. 설정을 찾으려고 디렉터리 권한을 넓히면 조사하려던 로딩 동작이 깨집니다.

Netplan이 지속성을 가질 때

Ubuntu에서는 Netplan 문서에 설명된 NetworkManager 통합이 23.10부터 제공되며 지속 사본이 사는 곳을 바꿉니다. 비임시 연결의 경우 다음을 쓰고, /etc/netplan/90-NM-<connection UUID>.yaml 그 아래에 임시 NetworkManager 프로필을 생성합니다: /run/NetworkManager/system-connections/.

그것은 배포판 통합이며 모든 NetworkManager 설치에 대한 규칙이 아닙니다. YAML 파일을 찾으러 가기 전에 설치된 패키지가 실제로 그것을 사용하는지 확인하십시오. 런타임 프로필이 편집할 가치가 있는 출처가 아니라 다른 무언가의 생성된 표현일 수 있다는 점도 기억하십시오. 두 명령의 확인이 잘못된 파일을 한 시간 편집하는 일을 아껴 줍니다.

문서화된 예는 NetworkManager 패스스루 데이터와 함께 Netplan nm-devices 유형을 통해 OpenVPN 연결을 저장합니다. Netplan이 특정 VPN 필드에 대한 전용 해석을 갖지 않는다는 사실은 저장된 VPN이 사라졌다는 뜻이 아니라, 그 필드가 불투명한 데이터로 이동한다는 뜻입니다.

일시적 인터페이스는 프로필이 아닙니다

활성화는 결코 지속되도록 의도되지 않은 임시 가상 연결과 인터페이스를 만듭니다. 통합은 의도적으로 각각에 새 YAML 파일을 쓰지 않으므로, /etc/netplan 에 없다고 해서 상위 프로필이 저장되었는지에 대해 아무것도 말하지 않습니다.

나타났다 사라지는 파일을 쫓고 있다면 아마 구성이 아니라 이런 것 중 하나를 보고 있는 것입니다. 내용에서 어떤 결론을 내리기 전에 재시작을 견디는지 확인하십시오. 재부팅 때 사라지는 런타임 파일은 그것이 결코 출처가 아니었음을 알려 주며, 그 한 번의 관찰이 조사 전체의 방향을 바꿉니다. 그때 편집이 성공한 것처럼 보인 이유도 설명해 줍니다.

비밀과 소유권

프로필은 전혀 다른 곳에 저장된 인증서나 키를 참조할 수 있고, 암호는 NetworkManager에 속하거나, 사용자 세션 비밀 에이전트가 제공하거나, 의도적으로 저장되지 않을 수 있습니다. 따라서 파일 하나를 찾는 것은 무인 시작이 무엇을 요구할지에 대해 거의 결정하지 못합니다.

비밀 값을 출력하지 않고 참조와 비밀 플래그를 검사하십시오. 데스크톱 로그인은 부팅 시 없던 에이전트를 사용할 수 있게 만들 수 있으며, 생성된 런타임 파일을 복사해도 그 에이전트가 재현되지 않습니다. 실무적 증상은 사람이 로그인하면 연결되고 기계가 혼자 시작하면 실패하는 터널입니다. 그 패턴은 라우팅이 아니라 비밀 소유권을 가리킵니다.

승인된 변경은 연결을 소유한 관리자를 통해 수행하고, 그다음 저장된 식별자와 실제 연결을 모두 검증하십시오. 지속 소유자를 하나만 유지하십시오. 가져오기, 생성된 keyfile, YAML 출처를 따로 편집하면 다음 재연결이 무엇을 사용할지에 대한 세 가지 경쟁 설명이 남습니다. 실제로 지속되는 것을 고르고 그것만 편집하며, 어떤 파일을 권위 있는 것으로 다루었는지 티켓에 적으십시오. 다음 사람이 한 줄의 출처에 감사할 것입니다.