NetworkManager에서 VPN 경로가 보이지 않을 때: 프로필 정책인가 스크립트인가

연결하면 터널 인터페이스가 나타나지만, 필요한 프리픽스 하나가 테이블에 없습니다. 다음 단계는 보통 그것을 추가하는 스크립트를 찾는 일입니다. 그 검색은 프로필에 OpenVPN 도우미를 붙여 넣는 답변으로 이어지는데, 그런 답변의 절반은 상황을 낫게 하기는커녕 더 나쁘게 만드는데, 빠진 경로에는 세 가지 가능한 소유자가 있고 그중 스크립트가 빠진 경우는 하나뿐이기 때문입니다.

무엇이든 쓰기 전에 어느 소유자가 책임인지 정하세요.

세 소유자, 하나의 빠진 프리픽스

프리픽스는 아무도 제공하지 않았기 때문에, 프로필이 거부했기 때문에, 또는 보지 않는 곳에 설치되었기 때문에 없을 수 있습니다. 서로 다른 결함이고 해결책도 다릅니다.

첫 번째는 확인하기 가장 쉬운데, 서버나 플러그인이 그 경로를 제공한 적이 있는지 보면 됩니다. 프리픽스를 받은 적 없는 백엔드는 설치할 수 없고, 도우미 스크립트는 상대가 한 번도 설명하지 않은 도달성을 지어낼 수 없습니다. 두 번째는 프로필 정책으로, 연결이 원래 가져갈 경로를 억제할 수 있습니다. 세 번째는 테이블이나 규칙으로, 기본 조회가 보지 않는 곳에 경로를 담아 둘 수 있습니다.

네 번째 소유자는 나중의 여러분, 즉 연결할 때 경로를 추가하지만 끊을 때 제거하지 않는 스크립트입니다. 그러면 터널보다 오래 살아남고 죽은 인터페이스를 가리키며 다음에 그 머신을 디버깅할 사람을 헷갈리게 하는 프리픽스가 생깁니다.

무엇이든 추가하기 전에 프로필을 읽으세요

저장된 연결 자체의 속성부터 시작하세요. 비밀을 쏟아내지 않고 읽고, 프로필 이름이 모호하면 UUID를 사용하세요.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type 는 어느 백엔드가 연결을 소유하는지 알려 주는데, 플러그인 데이터가 백엔드마다 다르기 때문에 이는 중요합니다. 한 플러그인이 받아들이는 키가 다른 플러그인에 지원되는 지시는 아니므로, 다른 클라이언트 문서에서 복사한 조각은 아무것도 증명하지 못합니다.

ipv4.ignore-auto-routes 와 ipv4.never-default 는 서로 다른 질문에 답합니다. 첫 번째는 연결이 원래 자동으로 가져갈 경로를 거부할 수 있고, 두 번째는 프로필이 기본 경로가 될 수 있는지 제어합니다. 자동 경로를 무시하고 다른 무엇에도 기대지 않는 프로필은 깔끔하게 연결되고 거의 아무것도 설치하지 않습니다.

ip -4 rule show
ip -4 route show table all

이 두 명령이 세 번째 가능성을 정리합니다. 프리픽스를 main 뿐 아니라 모든 테이블에서 찾고, 정책 규칙이 해당 조회를 다른 곳으로 보내는지 확인하세요. 프리픽스가 다른 테이블에 있고 아무도 그것을 조회하지 않는다면 경로가 빠진 것이 아니라, 결코 거기에 닿지 않는 조회가 있는 것입니다.

스크립트가 고칠 수 없는 것

도우미 스크립트를 추가하면 NetworkManager의 vpn.data 에게 실행할 프로그램이 생깁니다. 실재하는 메커니즘이지만, 스크립트는 프로필 자체의 정책이 무엇을 받아들일지 이미 결정한 뒤에 제어권을 넘겨받기 때문에 이런 경우 대부분에는 틀린 선택입니다.

OpenVPN의 script-security 도 자주 나오는 혼동으로, 클라이언트가 어떤 스크립트를 실행할 수 있고 그 환경에 무엇을 넣을 수 있는지 규정하는 OpenVPN 설정입니다. 레벨 3은 자격 증명을 환경으로 전달하도록 허용하는데, 이는 라우팅 수정이 아니라 비밀 취급에 관한 결정입니다. 백엔드가 OpenVPN이 아닌 프로필에 붙여 넣거나, 어떤 스크립트도 필요로 하지 않는데 올리면 경로는 늘지 않고 노출만 늘어납니다.

다음은 재시작 반사입니다. NetworkManager 서비스를 재시작하면 원격에서 작업 중일 때 자신이 연결된 링크까지 포함해 관리되는 모든 링크가 끊겼다가 다시 만들어집니다. 무해한 진단이 아니라 방해가 되는 조작이며, 서버에서는 세션이 살아남느냐의 차이가 될 수 있습니다.

판단은 순서대로

세 가지 질문을 차례로 던지세요. 상대가 프리픽스를 제공했는지는 백엔드 로그나 자체 상태 출력으로 알 수 있습니다. 그렇다면 프로필이 경로를 받아들이고 설치하도록 설정되어 있습니까, 아니면 억제하고 있습니까? 경로가 어딘가에 존재한다면, 테스트하는 트래픽에 대해 조회 경로가 올바릅니까?

첫 답이 예이고 둘째가 예이며 셋째가 올바를 때에만 보조 스크립트가 정당화되며, 그때도 백엔드가 그 경로를 기본으로 지원하는지 물어야 합니다. VPN 설정 참조에는 service-type 와 플러그인별 데이터 사전이 문서화되어 있으니, 키가 존재한다고 가정하기 전에 거기서 시작해야 합니다.

승인된 수정 뒤에는 다시 연결해 목적지를 주소로, 그다음 이름으로 시험하고, 다시 끊었다 연결해 상태가 반복 가능한지 확인하세요. 소유자 하나, 테이블 하나, 터널과 함께 사라지는 경로야말로 얻을 가치가 있는 결과입니다.