nmcli VPN 목록: 저장된 프로필과 활성 터널

nmcli connection show를 실행하면 VPN 목록을 기대하지만, 머신이 지금까지 저장한 모든 연결이 나옵니다. 브리지와 핫스팟도 포함됩니다. 찾는 VPN은 거기 있을 수도 있고, vpn이 아닌 다른 유형일 수도 있고, 아예 NetworkManager 연결이 아닐 수도 있습니다. 이 세 가지 중 어느 경우인지 알려면 명령 두 개가 필요합니다.

두 목록, 두 가지 질문

connection show는 NetworkManager가 저장한 것을 답하고, connection show --active는 현재 장치에 연결된 것을 답합니다. 첫 번째 목록에는 비활성 프로필도 포함되며 이는 의도된 것입니다. 내려간 저장된 VPN도 고쳐야 할 수 있는 프로필이기 때문입니다. 둘을 혼동하면 구성만 존재하는데도 터널이 돌아가는 듯한 인상을 줍니다.

기본 표를 읽는 대신 필드를 고르십시오. 기본 출력은 좁은 터미널에서 유형을 숨기고 긴 이름을 줄바꿈합니다.

첫 확인에는 보통 NAME, UUID, TYPE이면 충분하며, 그다음 관심 있는 항목 하나를 UUID로 살펴봅니다.

TYPE이 바로 놀라움이 있는 곳입니다

OpenVPN 플러그인으로 관리되는 연결은 vpn 유형으로 표시됩니다. 플러그인은 일반 VPN 프레임워크 안의 서비스이기 때문입니다. 네이티브 WireGuard 지원은 그 자체로 독립된 일급 연결 유형이므로 vpn으로 필터링하면 찾지 못합니다. 아무것도 반환하지 않는 WireGuard 터널 검색은 보통 필터 문제이지 프로필 누락이 아닙니다. 이것은 이름 붙이기의 변덕이 아니라 구조적 차이입니다.

NetworkManager가 시간이 지나며 네이티브로 다루는 법을 배운 다른 터널 유형에도 같은 말이 적용되므로, 무언가 없다고 결론 내리기 전에 TYPE 열을 읽으십시오.

전부 나열하고 나중에 필터링하면 프로필이 나타납니다.

이름만이 아니라 UUID를 읽으십시오

이름은 사람들이 편집하는 레이블이며, 부주의한 가져오기 후 두 프로필이 하나를 공유할 수 있습니다. UUID는 명령과 파일이 참조하는 정체성입니다. 항목이 중복처럼 보이면 아무것도 삭제하기 전에 UUID와 기반 설정을 비교하십시오.

활성화 명령은 둘 다 받아들이므로, 이름에 의존하는 습관은 결국 잘못된 프로필을 수정합니다.

되돌려야 할 수 있는 것을 변경할 때는 UUID를 메모에 복사하십시오.

저장된 프로필이 알려주지 않는 것

저장된 프로필은 터널이 올라와 있는지 아무것도 말하지 않고, 활성 연결은 내부 트래픽이 동작하는지 아무것도 말하지 않습니다. wg-quick이나 서비스 유닛이 시작한 터널은 NetworkManager 연결이 전혀 아닙니다. 그래서 인터페이스가 분명히 트래픽을 통과시키는데도 두 목록 모두에서 빠집니다. 프로필이 없다고 가정하기 전에 인터페이스와 라우팅 테이블을 확인하십시오. 빈 목록은 NetworkManager가 소유자가 아니라는 것만 증명합니다.

같은 인터페이스에 관리자 둘이 있는 것은 이 문제의 다른 판본이며, 커널 상태를 다른 무언가가 소유하는 동안 목록만 올바르게 보이게 만듭니다.

인터페이스마다 소유자를 하나로 두면 목록이 정직해지며, nmcli 참조 문서는 각 보기가 실제로 어떤 필드를 보고하는지 설명합니다.

비밀을 흘리지 않고 보고하십시오

connection show에 이름을 주면 설정이 출력되고, --show-secrets를 더하면 개인 키와 암호가 함께 출력됩니다. 티켓에 문제 해결 내용을 붙여넣는 데는 그것들이 필요 없습니다. 대신 유형, UUID, 상태, 관련 경로를 보고하고 비밀 저장소에서 온 것은 모두 가리십시오.

--ask를 사용한 대화형 활성화가 빠진 자격 증명을 제공하는 지원되는 방법이며, 무인 자동화에는 저장된 평문 암호 대신 다른 승인된 방식이 필요합니다.

짧고 가린 보고서가 전체 덤프보다 검토하기 쉽습니다.