SSL VPN과 사이트 간 VPN은 왜 대립 개념이 아닌가
SSL VPN과 사이트 간 VPN은 서로 다른 축을 설명합니다. 누가 네트워크에 참여하는지, 터널을 어떻게 만드는지의 차이입니다. 둘을 함께 부르는 것은 범주 오류입니다.
같은 VPN을 두 관리자에게 설명하게 하면 한 사람은 “SSL VPN”이라고 답하고 다른 사람은 “사이트 간”이라고 말할 수 있습니다. 마치 메뉴에서 경쟁하는 선택지인 것처럼요. 그러나 둘은 서로 다른 질문에 대한 답이며, 대안으로 취급하면 해결할 수 없는 비교가 생깁니다. 한 레이블은 어떤 끝점이 연결되는지를, 다른 레이블은 그 사이 트래픽을 무엇이 나르는지를 말합니다. 축을 분리해 두면 논쟁의 대부분이 사라집니다.
두 레이블, 두 개의 별도 질문
토폴로지는 누가 무엇에 참여하는지에 답합니다. 원격 액세스 설계는 개별 사용자나 장치를 게이트웨이에 연결하며, 보통 사용자별 ID와 주소 풀을 둡니다. 사이트 간 설계는 두 네트워크를 게이트웨이로 연결하므로, 흥미로운 ID는 피어 게이트웨이이지 키보드 앞의 사람이 아닙니다. 이는 주소 계획부터 새벽 2시에 누가 액세스를 취소할 수 있는지까지 서로 다른 운영 문제입니다.
메커니즘은 터널을 어떻게 만들고 인증하는지에 답합니다. IKEv2를 사용하는 IPsec, 내부에 IP를 나르는 TLS 기반 제품, 브라우저를 향한 애플리케이션 포털은 메커니즘 선택이며, 각각 고유한 협상, 암호 제품군, 실패 모드가 있습니다. 어느 것도 토폴로지를 함축하지 않으며, 토폴로지가 메커니즘을 고르지도 않습니다.
두 축을 한 표에 넣으면 혼란이 드러납니다. 격자의 모든 칸을 채울 수 있기 때문입니다. 표가 할 수 없는 일은 공급업체가 어떤 조합을 출하했는지 알려주는 것입니다. 제품 이름은 두 축을 하나의 마케팅 문구로 압축하기 때문입니다.
범주 오류는 어디에서 오는가
공급업체들은 수년간 “SSL VPN”을 “IPsec VPN”의 반대 개념으로 팔았고, 그래서 메커니즘 비교가 토폴로지 선택처럼 보였습니다. 이 표현은 그 자체의 전제에서도 낡았습니다. 현재 설계는 지원되는 TLS 버전을 사용하고 SSL이라는 이름은 주로 제품 범주로 남아 있기 때문입니다.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
같은 압축에서 두 가지 신화가 나옵니다. 첫째는 IPsec이 사이트 간을 뜻한다는 것입니다. IKEv2는 클라이언트-게이트웨이 관계를 위해서도 설계되었으므로 개별 노트북이 IPsec으로 참여할 수 있습니다. 둘째는 TLS 기반 제품이 원격 액세스만 뜻한다는 것입니다.OpenVPN은 두 사이트 사이에서 트래픽을 나르는 데 일상적으로 쓰이며, TLS 사용은 브라우저 세션이 아니라 제어와 인증 교환에 집중됩니다.
모든 설명에 유용한 시험입니다. 한 단어를 바꾸었을 때 끝점과 프로토콜이 모두 바뀐다면 그 문장은 축을 섞고 있습니다. “SSL VPN 대 사이트 간”은 그 시험을 통과하지 못합니다. 첫 용어는 메커니즘 계열을, 둘째는 토폴로지를 가리키기 때문입니다.
비교할 수 있도록 배포를 설명하십시오
네 칸을 쓰고 채우십시오. 끝점, 메커니즘, 인증, 액세스 표면입니다. 지사 링크는 두 개의 명명된 접두사 사이에서 인증서 인증을 쓰고 사용자 수준 포털이 없는 IKEv2 게이트웨이 쌍으로 읽을 수 있습니다. 원격 액세스 서비스는 사용자별 주소를 할당하고 로그인 시 두 번째 요소를 요구하며 내부 DNS 영역만 게시하는 TLS 기반 클라이언트로 읽을 수 있습니다.
그 문장들은 제품 이름이 갖지 못한 방식으로 비교 가능합니다. 두 원격 액세스 설계는 같은 사용자 워크플로와 같은 취소 경로에 대해 측정할 수 있고, 두 사이트 간 설계는 같은 접두사 목록, 트래픽 정책, 실패 요구 사항에 대해 측정할 수 있습니다. 레이블은 비교를 조직할 뿐 대체하지 않습니다.
용어에는 공개된 기준점도 있습니다.IETF의 VPN 용어 문서는 원격 액세스와 사이트 간을 포함한 여러 서비스 모델을 그것을 만드는 메커니즘과 분리하며, 바로 그 구분이 계속 사라집니다.
제품 이름이 아니라 협상된 프로토콜을 읽으십시오
상자에 붙은 레이블은 실행 중인 터널이 무엇에 합의했는지 확정하지 않습니다. TLS 측에서 피어에게 직접 물어보고, 브로슈어의 버전이 아니라 핸드셰이크가 만들어낸 프로토콜 버전과 암호를 읽으십시오.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefIPsec 게이트웨이라면 동등한 관찰은 구현 자체의 상태 출력에서 나옵니다. 사용 중인 IKE와 ESP 제안을 보고합니다. 어느 쪽이든 요점은 같습니다. 메커니즘 축은 살아 있는 세션에서 읽어야 합니다. 클라이언트와 게이트웨이는 어느 관리자가 예상했든 것보다 오래된 무언가로 내려가 협상할 수 있기 때문입니다.
ipsec statusall | grep -E "IKE|ESP"그다음 남는 질문은 어떤 레이블도 답하지 않는 것들입니다. 어떤 프로토콜 버전이 아직 받아들여지는지, 게이트웨이 ID를 어떻게 검증하는지, 어떤 알고리즘 집합이 허용되는지, 누가 특정 사용자에게 특정 리소스를 승인하는지, 장치를 잃었을 때 무엇이 액세스를 취소하는지. 토폴로지 다이어그램과 메커니즘 이름은 그 목록의 시작이지 대체물이 아닙니다.
그러니 두 레이블을 유지하되 있는 그대로 사용하십시오. 어떤 끝점이 연결되고 터널이 어떻게 만들어지는지를 짧게 말하는 수단입니다. 둘 중 하나를 다른 하나를 배제하는 데 쓰는 순간, 그 설명은 아무것도 설명하지 않게 됩니다.