VPN 어댑터 이름이 다른 프로토콜을 숨길 수 있는 이유

VPN 어댑터 옆의 레이블은 인터페이스를 만든 소프트웨어를 설명하며, 그것은 실제로 네트워크를 지나는 패킷보다 한 계층 위입니다. 플러그인은 네트워크의 캡슐화가 아니라 플러그인 자체의 분류를 반영하는 이름의 어댑터를 노출할 수 있습니다. 클라이언트, 프로필, 피어를 읽으면 이름이 답할 수 없는 것을 알 수 있습니다. 설정 메뉴에서 똑같아 보이는 두 연결이 캡처에서는 전혀 다르게 동작할 수 있습니다.

이름은 회선이 아니라 공급자에게서 온다

Windows는 내장 VPN 클라이언트를 위한 짧은 연결 유형 목록을 정의하고, 타사 제품은 그 옆에 자체 스택을 설치합니다. 네트워크 목록에 나타나는 어댑터는 연결을 소유한 드라이버가 만들므로, 그 이름은 드라이버에 대한 증거이지 외부 프로토콜에 대한 보장이 아닙니다. 클라이언트 하나를 제거해도 어댑터 이름이 남을 수 있는 이유도 같습니다.

VPN 연결 유형에 관한 Microsoft 문서는 유형이 해당 연결에 대한 클라이언트 구성을 설명한다고 분명히 밝힙니다. 플러그인이 관여하면 표시되는 유형은 플러그인이 등록한 것을 따르며, 실제 캡슐화는 전혀 다른 것일 수 있습니다.

같은 계층 구조는 다른 곳에서도 나타납니다. Linux 호스트의 가상 어댑터, TAP 장치, 모바일 VPN 서비스 확장은 모두 소프트웨어가 만든 인터페이스이며, 인터페이스 이름은 서버와 협상하는 대신 그 소프트웨어가 고릅니다.

포트와 주소가 알려 줄 수 있는 것과 없는 것

각 계층은 서로 다른 증거를 남깁니다. 그것을 따로 읽으면 레이블은 더 이상 판결이 아닙니다:

TCP 443이 가장 분명한 예입니다. 그것은 SSTP, OpenVPN TCP 터널, SoftEther SSL-VPN 세션 또는 일반 웹 트래픽을 실을 수 있고, 포트 번호만으로는 그것들을 구별할 수 없습니다. 따라서 443을 허용하는 방화벽 규칙은 어떤 클라이언트가 사용 중인지에 대한 증거가 아닙니다. 외부 인터페이스에서의 캡처가 그것을 판정하며, 몇 초 만에 판정합니다.

프로필 형식과 피어를 읽는다

구성 파일은 어댑터보다 강한 단서입니다. OpenVPN 프로필에는 remote, proto, ca 같은 지시문이 들어 있고, WireGuard 구성에는 개인 키가 있는 [Interface] 섹션과 허용된 IP가 있는 [Peer] 섹션이 들어 있으며, Windows 전화번호부 항목은 연결 유형을 자체 형식으로 저장합니다. 각 구문은 하나의 구현에 속합니다.

그다음 피어의 문서와 로그를 보십시오. 서버는 어느 프로토콜 처리기가 세션을 받아들였는지 알고 있고, 그 로그는 완료된 단계를 지명합니다. 이 증거는 패킷이 실제로 해석된 곳에서 기록되므로 어떤 데스크톱 레이블보다 우선합니다.

레이블이 아니라 프로토콜로 설명서를 고른다

OpenVPN 지시문은 OpenVPN의 것이고, WireGuard 키와 허용된 IP는 WireGuard의 것이며, SSTP 프로필은 둘 다 아닙니다. 어댑터 이름이 호환되는 것처럼 들린다는 이유로 한 클라이언트의 옵션을 다른 클라이언트에 붙여 넣는 것이 작동하던 구성을 깨뜨리는 방식입니다.

프로토콜이 확인되면 해당 문제 해결 경로를 고르십시오: 클라이언트 자체의 로그, 서버의 프로토콜별 로그, 외부 교환을 보여 주는 캡처입니다. 그곳에서 장애는 레이블이 아니라 이름을 갖습니다.