하나의 VPN 서비스로 Windows, Mac, Linux 데스크톱을 모두 감당할 수 있을까?

한 팀에 노트북 세 대, 서로 다른 VPN 메뉴 세 가지, 그리고 Mac만 빼고 어디서나 연결된다는 티켓. 메뉴가 달라도 그 클라이언트 뒤의 설계는 동일할 수 있다. 맞춰야 할 것은 대부분의 도입이 가정하는 것보다 좁다. 게이트웨이 신원 하나, 자격 증명 유형 하나, 경로 집합 하나, 리졸버 정책 하나. 누군가 프로필을 내보내기 전에 이 네 가지를 적어 두면 플랫폼 작업은 조사가 아니라 체크리스트가 된다.

클라이언트 파일이 아니라 접속 계약부터 시작하라

접속 계약은 벤더 콘솔을 열지 않고도 검토자가 확인할 수 있는 다섯 줄이다. 여기에는 도달 가능해야 하는 사설 프리픽스, 확인되어야 하는 내부 이름, 그것에 응답하는 리졸버, 로컬 경로에 남겨도 되는 트래픽, 그리고 클라이언트가 기대해야 하는 게이트웨이 인증서가 적힌다. 도입의 나머지 모든 것은 이 줄들을 파일 형식으로 옮긴 것에 불과하다.

사무실 예시 하나면 윤곽이 구체화된다. 애플리케이션 서버는 10.60.0.0/16 에, 사설 이름은 corp.example 아래에, 내부 리졸버는 10.61.0.53 에 있고, 일반 브라우징은 기기가 원래 쓰던 경로에 그대로 둔다. 마지막 항목은 클라이언트 기본값이 아니라 정책 결정이며, 아무도 말하지 않으면 여러 클라이언트가 모든 트래픽을 터널로 보낸다. 계약을 날짜와 담당자와 함께 기록하라. 나중에 터널이 바뀐 것인지 정책이 바뀐 것인지 알려주는 것은 그 기록뿐이다.

변호할 수 있는 프로토콜 하나와 인증 조합 하나를 고르라

세 플랫폼 모두가 추가 소프트웨어 없이 동작해야 할 때 흔한 선택은 인증서 기반 게이트웨이 인증을 쓰는 IKEv2와 사용자 측 EAP다. Windows, macOS, NetworkManager가 각각 IKEv2 클라이언트를 함께 제공하기 때문이다. 문제는 IKEv2를 지원한다는 말이 기능 집합이 아니라 이름표를 설명한다는 점이다. EAP 방식, 하드웨어 기반 키, 인증서와 계정의 매핑, 자동 재연결은 플랫폼마다 따로 구현된다. 셋 중 둘에서 동작하는 조합은 흔하므로 시험하기 전까지는 그렇게 가정해야 한다.

배포 안내서를 쓰기 전에, 나중이 아니라 모든 대상 플랫폼에서 그 조합을 시험하라. EAP-MSCHAPv2와 EAP-TLS를 모두 제공하는 게이트웨이는 대체 경로를 둘 여지를 준다. 단, 그 대체 경로가 장애 중에 발견되는 것이 아니라 지원 대상으로 문서화되어 있어야 한다. 지원되는 경로 두 개는 값싼 보험이고, 문서화되지 않은 세 번째 경로는 미래의 티켓이다.

하나의 조합으로 세 클라이언트를 모두 덮지 못할 때 정직한 선택지는 클라이언트를 추가하거나, 게이트웨이 프로필을 추가하거나, 지원 플랫폼 목록을 좁히는 것이다. 가장 크게 불평하는 플랫폼에서 인증서 검증을 끄는 것은 그중 어느 것도 아니다. 그 변경은 호환성 격차를 가로채기 위험으로 바꾸며, 도입의 이후 어떤 단계도 그것을 복구하지 못한다.

계약에서 플랫폼마다 산출물 하나를 만들라

Windows는 VPNv2 프로필을 쓴다. MDM으로 배포하거나 Add-VpnConnection 과 그 XML 페이로드로 로컬에서 만든다. 걸리는 부분은 범위와 신뢰다. 장치 범위 프로필과 사용자 범위 프로필은 서로 다른 저장소에 설치되므로, 클라이언트에 필요한 인증서는 선택한 범위에 맞는 저장소에 있어야 한다. 이 짝을 잘못 맞추면 깔끔하게 가져오기되고 나서 첫 연결에서 실패하는 프로필이 만들어진다.

macOS는 관리형 VPN 페이로드가 포함된 구성 프로필을 쓴다. 서명해 MDM으로 배포하거나 파일럿에서는 직접 설치한다. 신원과 CA 체인은 별도 페이로드로 전달되며, 그래서 프로필이 아무 불만 없이 설치되고도 연결 시점에 실패할 수 있다. 설치 결과만이 아니라 페이로드 목록을 확인하라.

Linux는 NetworkManager 뒤의 백엔드에 달려 있고, strongSwan과 NetworkManager 플러그인은 별도 패키지다. 연결 속성은 일반 VPN 키가 아니라 플러그인 고유의 것이므로, 다른 플러그인에서 복사한 키는 오류 없이 저장되고 나서 활성화에서 실패하기 일쑤다. 플러그인이 실제로 실행될 위치에 있는지 확인하려면 깨끗한 이미지에서 연결을 만들어 보라.

세 산출물은 형식이 다르지만 각각 같은 다섯 줄의 계약을 담고 있다. 산출물이 완성되었는지 판단하는 기준이 이것이다. 모든 줄이 어딘가에 표현되어 있고, 도중에 군더더기가 발명되지 않았는가.

깨끗한 계정에서 경로, 리졸버, 재연결을 검증하라

연결되었다는 것은 인수 시험이 아니다. Windows에서는 Get-VpnConnection 이 프로필을 보여주고 route print 이 사설 프리픽스가 터널 인터페이스에 올라갔는지 보여준다. macOS에서는 scutil --nc list 이 활성 서비스를 확인하고 scutil --dns 이 시스템이 실제로 사용할 리졸버 순서를 보여준다.

Linux에서는 nmcli connection show --active 로 연결이 올라왔음을 확인하고 resolvectl status 으로 링크별 DNS를 본다. 연결 파일에는 있는데 링크별 출력에는 없는 리졸버는 분할 DNS가 적용되지 않았다는 뜻이다. 이는 이름이 확인되는 것과 이름이 터널을 통해 확인되는 것의 차이이며, 다음 단계를 어느 지원 팀이 맡을지가 달라진다. 링크별 출력은 연결이 올라온 뒤만이 아니라 전과 후를 모두 비교하라.

캐시된 자격 증명도, 관리자가 설치한 인증서도 없는 새 계정으로 전체 점검을 수행하라. 그다음 일시 중단과 재개 후에 반복하고, 자격 증명 재입력을 강제한 뒤에 한 번 더 하라. 이 두 전환이 첫 연결에서는 결코 드러나지 않는 재연결 실패의 대부분을 드러낸다.

패키지에 버전을 붙이고 롤백 경로를 남겨라

각 플랫폼 패키지에 그것이 구현하는 계약 리비전 태그를 붙이고, 어느 클라이언트와 게이트웨이 버전으로 승인했는지 적어 두라. 클라이언트 업데이트 후 동작이 바뀌면 그 태그는 추측할 파일이 아니라 다시 시험할 계약을 가리킨다.

각 플랫폼의 이전 패키지를 꺼낼 수 있는 상태로 두고, 그 옆에 제거 명령을 적어 두라. VPN 프로필 제거는 Windows, macOS, Linux 어디에서도 설치의 거울상이 아니며, 그 차이는 최악의 시점에 드러난다. 여분의 기기에서 제거를 한 번 연습해 두면 아카이브는 희망이 아니라 계획이 된다.