OpenVPN 또는 IKEv2: 프로토콜을 고르기 전의 네 가지 확인

OpenVPN과 IKEv2 중 무엇을 고를지는 대개 프로토콜 문제로 논의되지만, 그런 틀은 결정을 낭비합니다. 결정하는 것은 서버와 기기가 같은 완전한 프로파일을 지원하는지, 그리고 그 프로파일이 네트워크 사이를 옮겨 다니는 방식을 견디는지입니다. 두 스택은 서로 변환되지 않으며, OVPN 파일은 문법만 다른 IKEv2 프로파일이 아닙니다. 순서대로 실행하는 네 가지 확인은 어떤 기능 표보다 빠르게 그 질문에 답합니다.

클라이언트가 없으면 논의는 끝난다

Windows와 macOS에는 IKEv2 클라이언트가 기본 포함되어 있으므로, 그곳에서 IKEv2 프로파일을 배포하는 데 추가 비용이 들지 않고 운영체제가 이미 제공하는 프로비저닝 옵션을 물려받습니다. 같은 기기에서 OpenVPN을 쓰면 설치하고 업데이트하고 지원해야 하는 서드파티 클라이언트가 필요하며, 그 클라이언트는 프로파일이 쓰는 모든 옵션을 받아들여야 합니다. 동작하는 클라이언트가 없는 플랫폼은 비교 대상조차 아니므로, 다른 무엇을 비교하기 전에 다뤄야 할 플랫폼을 세세요.

Windows에서는 명령 하나가 이미 있는 프로파일을 나열하고 각각의 유형을 보여 줍니다. 그것이 출력하는 이름이 이후 확인에서 쓰는 이름입니다.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

클라이언트 설치를 요구하는 것이 그 플랫폼에서 OpenVPN 열의 실제 답이며, 그것은 프로토콜의 한계가 아니라 배포 작업입니다. 어느 구성도 신뢰 확인, 신원 검증, 유지 관리를 없애지 않습니다. 약속하기 전에 프로파일이 어떻게 배포되는지, 자격 증명이 어떻게 갱신되는지, 분실한 기기가 어떻게 제거되는지 물어보세요. 단순한 설치도 주말에 아무도 돌리고 싶지 않은 복구 절차를 숨길 수 있습니다.

이동성은 공동 설정이지 프로토콜의 약속이 아니다

IKEv2는 양쪽 끝이 MOBIKE를 지원하고 켤 때 그것을 쓸 수 있으며, 이는 클라이언트가 주소가 바뀌는 동안 터널을 유지하게 해 줍니다. RFC 4555가 그 확장을 정의하며, 조건부 표현이 중요한데, 그 기능을 무시하는 서버는 대신 다시 협상합니다. 파일 전송에서는 결과가 같아 보이고 실시간 통화에서는 아주 달라 보일 수 있습니다.

정말로 신경 쓰는 전환을, 지켜볼 수 있는 무언가를 돌린 채로 시험하세요. Windows에서는 ping -t <internal-host>을 계속 돌리고 다른 곳에서는 평범한 ping을 쓰면서, Wi-Fi에서 셀룰러로 바꾸고 끊김을 지켜보세요. MOBIKE 실패는 클라이언트 로그에서 조용한 주소 갱신이 아니라 완전한 재인증으로 나타납니다. 측정하는 것은 터널이 변화를 견디는지이지, 프로토콜이 지원을 광고하는지가 아닙니다.

OpenVPN 클라이언트는 각자의 플랫폼 동작과 프로파일 타이머에 따라 다시 연결하므로, 같은 시험이 다른 형태의 중단을 낳을 수 있습니다. 프로토콜에 붙은 이름표가 아니라 사용자에게 중요한 사건을 비교하세요.

자격 증명은 서비스에 속하고 스택에 속하지 않는다

인증서와 다른 로그인 방식은 연결을 종료하는 서비스에 속합니다. 한 클라이언트의 비밀번호 요구는 다른 클라이언트와의 호환성에 대해 아무것도 말하지 않으며, 다른 게이트웨이에서 동작하는 프로파일은 이 게이트웨이에 대해 아무것도 말하지 않습니다. 두 스택을 비교하는 동안 서버 신원 규칙은 그대로 두세요. 실패를 밝히기 전에 프로토콜을 바꾸면 대개 두 번째 호환되지 않는 프로파일이 생깁니다.

만료되었거나 잘못 발급된 인증서는 둘 다에서 같은 방식으로 실패하므로, 어느 프로토콜을 탓하기 전에 클라이언트가 제시할 자격 증명을 살펴보세요. 아래 출력은 개인 키를 읽지 않고 주체, 발급자, 유효 기간을 보여 줍니다.

openssl x509 -in client.crt -noout -subject -issuer -dates

회사 연결이라면 회사가 공개한 방식을 쓰고, 비교를 실험으로 취급하는 것을 그만두세요. 스스로 둘을 비교한다면, 그 한 가지 세부가 결과의 얼마만큼이 프로토콜에 관한 것인지를 결정하므로, 먼저 두 선택지가 같은 게이트웨이에서 끝나는지 확인하세요. 자격 증명을 지목하는 거부는 자격 증명 문제이며, 프로토콜을 아무리 바꿔도 고쳐지지 않습니다.

터널이 실제로 무엇을 라우팅하는지 확인한다

연결한 뒤 필요한 경로가 있고 이름이 해석되는지 확인하세요. 내부 리소스용 프로파일은 일반 브라우징을 의도적으로 로컬 경로에 남길 수 있으며, 그것은 결함이 아니라 정책 결정입니다. 중요한 것은 팀이 쓰는 목적지에 터널을 통해 도달할 수 있는지입니다.

Windows에서는 명령 두 개가 경로와 이름 조회를 다룹니다. Linux의 대응은 ip route show default와 resolvectl query <internal-host>입니다.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

터널이 올라오지만 유용한 것을 라우팅하지 않는 것은 프로파일을 서비스 사이에서 복사했을 때 흔한 결과이며, 일반 연결 시험은 인터페이스가 올라와 있어서 그것을 보여 주지 않습니다. 어떤 경로로든 닿는 공용 주소가 아니라 사용자가 처음 여는 리소스를 시험하세요. 이름이 공용 주소로 해석되는데 경로가 터널 안을 가리킨다면, DNS 응답과 경로는 서로 다른 결정에 속하며 둘 다 고쳐야 합니다.

확인 후 유지 관리를 저울질한다

추상적으로 어느 프로토콜이 더 유지하기 쉽다고 할 수 없습니다. 유지 관리는 누가 게이트웨이를 운영하는지, 프로파일이 어떻게 기기에 도달하는지, 분실한 기기가 얼마나 빨리 접근을 잃는지에 달려 있습니다. 단순한 엔드포인트 클라이언트가 운영하기 더 어려운 서버 앞에 놓일 수 있고, 그 반대도 일어납니다. 그것을 만든 사람이 떠난 뒤 팀이 둘 중 무엇을 계속 운영할 수 있는지 물어보세요.

작업을 덮는 지원되는 연결을 고르고, 기능 목록이 아니라 실제로 필요한 접근에 대해 시험하세요. 서로 다른 두 게이트웨이는 비교를 프로토콜만큼이나 경로에 관한 것으로 만들므로, 각 선택지가 어느 게이트웨이에서 끝나는지 기록하세요. 실제로 들고 다닐 기기에서 네 가지 확인을 반복하고, 그것을 통과하는 프로파일을 남기세요.