이 NetworkManager 플러그인으로 VPN 두 개를 동시에 돌릴 수 있을까?
저장된 프로필 두 개는 아무것도 증명하지 못한다. 플러그인의 서비스 메타데이터에서 여러 연결 지원 여부를 확인한 뒤, 두 연결 사이의 라우트와 DNS를 조정하라.
연결 목록에 VPN 항목이 둘 있는데 둘 다 연결됨이라고 표시되지만, 기대한 트래픽을 실제로 나르는 것은 그중 하나뿐이다. 아니면 두 번째가 아예 시작을 거부하고, 그것이 플러그인 탓인지 클라이언트 탓인지 잊고 있던 정책 탓인지 아무도 말할 수 없다. VPN은 하나만 된다는 주장은 특정 구현을 설명한 것이고 구현은 서로 다르다. 먼저 역량을 확인하고, 그다음 조정으로 넘어가라.
저장된 프로필을 세고, 다음으로 활성화를 세라
저장된 프로필은 설정 객체이고, 활성 연결은 실행 중인 인스턴스다. 목록은 두 개념을 시각적으로 합쳐 놓기 때문에 두 보고 모두 맞는 것처럼 들린다. 정확한 객체를 UUID와 함께 지목하는 것부터 시작하라. 표시 이름은 고유하지 않고 오래된 가져오기가 새 항목과 라벨을 공유하는 일이 흔하기 때문이다. 그다음 활성 목록을 따로 확인하고 어떤 UUID가 나타나는지 보라. 그래야만 두 설정을 비교하는지 살아 있는 터널 둘을 비교하는지 알 수 있다.
같은 UUID를 두 번 활성화하는 것은 세 번째 경우이며 동시성이 아니다. 하나의 인스턴스를 다시 활성화하는 것이다.
플러그인 자체의 메타데이터를 읽어라
모든 VPN 플러그인은 관리자가 읽는 작은 메타데이터 파일을 함께 제공하며, 그 파일은 플러그인이 여러 연결을 동시에 지원하는지 선언할 수 있다. 업스트림 프로젝트가 지금 쓰는 내용을 되풀이하지 말고 이 머신에 설치된 파일을 읽어라. 실제로 무엇을 가졌는지는 배포 패키지가 정하기 때문이다. 같은 확인은 프로토콜마다 적용된다. 한 플러그인에 대한 답은 다른 플러그인에 대해 아무것도 말해 주지 않는다. 패키지 버전을 결과와 함께 기록하라. 그래야 나중 비교가 의미를 갖는다.
VPN 하나 제한에 관한 옛 조언은 더 오래된 통합을 설명한 것이었다. 영원히 참인 것도 아니고 고정된 것으로 가정하기에 안전하지도 않으며, 눈앞의 파일이 그 문제를 국지적으로 판정한다.
동시라는 말은 조정되었다는 뜻이 아니다
플러그인 둘이 성공적으로 시작한다는 것은 역량을 증명할 뿐 설계를 증명하지 않는다. 둘 다 기본 라우트를 내놓는 두 터널은 경쟁하고, 자기 라우트를 마지막에 설치한 쪽이 대개 알리지도 않은 채 이긴다. 겹치는 사설 대역도 같은 문제를 더 작은 형태로 안고 있다.
무엇이든 활성화하기 전에 어떤 목적지가 어느 프로필에 속하는지 정하라. 프로필 이름을 바꾼다고 목적지가 구분되지 않는다.
DNS는 당신이 하든 하지 않든 승자를 고른다
리졸버 설정은 프로필마다 따로 있고, 둘이 활성일 때 해석 순서는 의도가 아니라 정책과 우선순위가 정한다. 마지막에 올라온 프로필이 모든 사내 이름을 조용히 차지할 수 있다.
사설 이름 공간마다 그 이름에 답해야 할 리졸버를 배정하고, 순서에 기대지 말고 라우팅 선호를 의도적으로 설정하라. 그다음 두 터널을 모두 올린 상태에서 각 공간의 이름을 시험하고, 하나를 끊은 상태에서 다시 시험하라. 두 터널이 모두 올라와 있는 동안에만 동작하는 리졸버는 최악의 순간에 누군가를 놀라게 할 설계다.
정해진 순서로 배포하고 중간에 점검하라
프로필 하나를 활성화하고 그 라우트와 리졸버 상태를 점검한 뒤, 두 번째를 활성화하고 다시 점검하라. 두 상태를 비교하면 무엇이 바뀌었고 어느 프로필이 무엇을 소유하는지 알 수 있다. 둘을 모두 활성화한 다음 결과를 진단하지 마라.
필요한 자원마다 그것을 날라야 할 터널을 통해 시험하고, 그다음 프로필 하나를 끊어 다른 하나가 자기 라우트와 DNS, 의도한 실패 동작을 유지하는지 확인하라. 배포된 플러그인이 정말로 필요한 일을 할 수 없다면, 관리자 옆에서 낡은 프로토콜을 되살리는 대신 지원되는 업그레이드나 명시적으로 격리된 대안을 골라라. 아무도 관리하지 않는 두 번째 별도 터널은 격리가 아니라 뜻밖의 라우트를 만드는 또 하나의 근원이다.