운영 체제는 이미 어떤 VPN 프로토콜을 이해할까요?

다른 클라이언트를 내려받기 전에 운영 체제가 이미 무엇을 구현하는지 확인하세요. 그 답만으로 설치 프로그램을 완전히 건너뛸 수 있는 경우가 많습니다. Windows, macOS, ChromeOS는 각각 고정된 짧은 터널 프로토콜 목록을 제공하며, 그중 하나를 말하는 게이트웨이에는 추가 드라이버도 서비스도 업데이트 경로도 필요하지 않습니다. 이것을 결정하는 것은 브로슈어의 공급업체 이름이 아닙니다. 결정하는 것은 프로토콜, 엔드포인트가 어떻게 인증하는지, 그리고 어떤 주소를 기대하는지입니다.

제품 이름이 아니라 프로토콜을 물으세요

제품 이름은 회선을 지나는 것이 무엇인지 거의 말해 주지 않습니다. 같은 라벨로 팔리는 두 게이트웨이가 전혀 다른 터널을 요구할 수 있고, 하나는 내장 클라이언트를 받아들이는 반면 다른 하나는 자체 포털 외에는 모두 거부할 수 있습니다. 같은 장비를 설명하는 두 관리자가 서로 다르게 말하면서 둘 다 옳을 수 있습니다. 설명하는 계층이 다르기 때문입니다. 설치 프로그램이 필요한지를 결정하는 것은 그 아래의 터널입니다.

게이트웨이를 운영하는 사람에게 어떤 터널 프로토콜인지, 어떤 인증 방식인지, 클라이언트가 어떤 주소와 DNS 접미사를 받아들여야 하는지 세 가지를 물으세요. 프로토콜을 이름으로 묻고, 답이 제품 이름으로 돌아오면 왜 프로토콜이 필요한지 설명하세요. 그 세 가지 답이 소프트웨어를 내려받기 전에 클라이언트 문제를 정리합니다.

제품 이름이 그렇게 많은 티켓에 남는 데에는 이유가 있습니다. 사용자가 보는 것은 포털 URL이고, 터널은 작동하는 동안 보이지 않습니다. 인수인계 메모에 프로토콜을 적는 데 한 줄이 들고, 나중에 오는 모든 사람의 모호함이 사라집니다.

내장 목록이 멈추는 곳

기본 목록은 짧고, 그 가장자리가 내용보다 중요합니다. IPsec 위의 L2TP 를 미리 공유한 키로 말하는 플랫폼은 SSTP를 말하지 않으며, 그 차이가 클라이언트를 결정합니다. 표는 공급업체가 아니라 터널 기준으로 정렬되어 있으므로 게이트웨이가 지정한 프로토콜을 찾을 수 있습니다.

표는 브로슈어가 아니라 게이트웨이의 요구 사항에 비추어 읽으세요. 답이 미리 공유한 키를 쓰는 L2TP over IPsec이라면 처음 세 플랫폼은 추가로 아무것도 설치하지 않고 연결됩니다. 답이 OpenVPN이라면 무엇이든 설치하기 전에 ChromeOS만 지원됩니다. 어떤 내장 열에도 나타나지 않는 프로토콜은 설치 프로그램이 온다는 정직한 신호입니다.

Linux는 일반화에 저항하는 열입니다. 프로토콜 지원은 배포판이 패키징하기로 선택한 데몬과 플러그인에 살고, 그래서 최소 이미지는 추가하기 전까지 그중 아무것도 말하지 못할 수 있으며, 같은 데스크톱을 가진 두 배포판도 다를 수 있습니다.

명령줄에서 프로필을 만드세요

그래픽 패널이 쓰는 모든 것은 접근할 수 있는 어딘가에 저장되며, 바로 그것이 내장 프로필을 자동화할 수 있게 합니다. Windows는 VPN 항목을 .pbk 파일에 사용자 프로필 아래와 ProgramData 아래에 보관하고, rasphone 는 네트워크 목록이 보여 주지 않는 항목을 나열하고 편집할 수 있습니다. 기계가 스크립트로 준비되고 아무도 마법사를 클릭하지 않을 때 이것이 중요합니다. 프로필이 트레이에 한 번도 나타나지 않고 존재할 수 있는 이유도 설명합니다.

rasdial
rasdial "VpnName" alice
rasdial "VpnName" /disconnect

손으로 .pbk 파일을 편집하는 것은 되지만 그것을 망가뜨리는 가장 빠른 방법이기도 하므로 형식은 도구가 소유하게 두세요. macOS는 서비스를 시스템 구성에 보관하고, networksetup 는 서비스 이름으로 그것들을 다루고, 여러 플래그는 호스트 이름이 아니라 주소를 원하므로 먼저 엔드포인트를 확인한 뒤 클라이언트가 실제로 사용할 값을 저장하세요. 이 구분은 자동화에서 물어뜯는데, 주소로 동작하는 스크립트가 이름으로는 실패할 수 있고 오류는 거부된 인수가 아니라 고장 난 게이트웨이처럼 보이기 때문입니다.

networksetup -listallnetworkservices
networksetup -getinfo "ServiceName"
networksetup -setmanualwithdhcprouter "ServiceName" 198.51.100.20

서비스 이름은 현지화되어 있고 사용자가 편집할 수 있으므로 Wi-Fi 를 하드코딩한 스크립트는 다른 언어로 설정된 첫 기계에서 깨집니다. 목록 명령에서 이름을 읽어 추측하지 말고 그대로 전달하세요.

독점 클라이언트 없는 인증서

일부 배포는 클라이언트 인증서만 필요하고 다른 독점 요소는 없습니다. 드라이버를 받아들이기 전에 시험해 볼 가치가 있는 중간 사례입니다. 인증서를 플랫폼 저장소에 두는 것은 지원되지만, 공급업체 루트를 밀어 넣고 클라이언트가 찾겠지 기대하는 것과 같은 행위는 아닙니다. 전자는 의도적 배치이고 후자는 지원 티켓이 붙은 추측입니다.

사람들을 잡는 세부 사항은 클라이언트가 어느 저장소를 읽는가입니다. 사용자 저장소의 인증서는 기계 저장소용으로 구성된 클라이언트에 보이지 않으며, 받는 메시지는 인증서가 없다고 말할 뿐 잘못된 위치에 있다고는 하지 않습니다. 인증서가 잘못됐다고 결론 내리기 전에 두 저장소를 모두 확인하세요. 작동하는 구성이 어느 쪽을 쓰는지 적어 두세요. 기계를 다시 만들 때 그 메모가 인증서보다 오래 남습니다.

Windows는 두 저장소를 명시적으로 분리하고, macOS는 로그인 키체인과 시스템 키체인을 분리합니다. 이름은 다르지만 실패 방식은 같습니다. 클라이언트가 결코 보지 않는 유효한 인증서입니다.

무엇이 설치 프로그램을 강제하는가

일부 게이트웨이는 클라이언트를 사설 인증서 저장소, 포스처 에이전트, 또는 운영 체제가 수행할 수 없는 로그온 교환에 묶습니다. Check Point, Cisco, Fortinet 하드웨어에 구축된 배포가 흔히 그곳에 이르며, 그런 경우 내장 클라이언트는 지름길이 아닙니다. 타사 대체품이 연결되면서도 정책을 위반할 수 있어, 이것은 편의가 아니라 보안 결정이 됩니다. 정책이 요구하는 것을 설치하고 설치 프로그램 버전 옆에 이유를 기록하세요.

그 기록이 사람들이 건너뛰는 부분이며 다음 관리자의 일주일을 아껴 주는 부분입니다. 프로토콜, 인증 방식, 주소 체계, 필요한 접미사, 그리고 추가해야 했던 모든 바이너리에 대한 한 줄의 근거입니다. 채팅 스레드가 아니라 설치 프로그램 메모가 있는 곳에 두세요. 두 줄의 문서가 반복 조사를 막습니다.