SoftEther VPN Azure: 열린 포트가 아닌 릴레이 경로

서버가 설정할 수 없는 라우터 뒤에 있으므로 포트를 포워딩하겠다는 뻔한 계획은 쓸 수 없습니다. VPN Azure 는 바로 그 상황을 위해 존재하며 첫 연결의 방향을 뒤집어 해결합니다. 서버가 바깥의 릴레이로 연결하고 클라이언트는 서버가 아니라 릴레이에 도달합니다. 이 뒤집힘을 이해하면 서비스가 무엇을 해결하는지와 나중에 마주칠 모든 한계가 설명됩니다.

경로에서 무엇이 바뀌는가

일반적인 리스너에서는 클라이언트가 공인 주소로 TCP 연결을 열고 라우터가 이를 서버로 전달합니다. 릴레이에서는 서버가 릴레이 인프라로 나가는 연결을 유지하고, 릴레이가 클라이언트 연결을 받아 그 페이로드를 대기 중인 서버로 넘깁니다. 인바운드 포트는 열리지 않고 고정 주소도 필요 없으며 라우터는 그대로입니다. 방화벽 관점에서 서버는 평범한 아웃바운드 클라이언트이므로 제한적인 네트워크도 이를 허용합니다.

릴레이는 그 서버에 자체 도메인의 이름을 부여하고 클라이언트는 그곳으로 연결하도록 구성됩니다.

그 이름은 릴레이 서비스에 속하며 Microsoft Azure VPN Gateway가 아닙니다. 둘 다 Azure 무언가로 불리더라도 말입니다. 둘을 서로 바꿔 쓸 수 있다고 보면 동작할 수 없는 구성이 됩니다.

어떤 프로토콜이 릴레이를 통과하는가

릴레이는 SoftEther 프로토콜을 전달하며 프로젝트는 SSTP 를 클라이언트 옵션으로 문서화합니다. Windows에 SSTP 클라이언트가 포함되어 있어 유용합니다. 다만 호스트의 모든 리스너를 위한 범용 운반자가 되지는 않습니다. OpenVPN 리스너, IPsec 응답자, L2TP 서비스는 각자 도달 가능한 종단점이 필요하며 SoftEther 서버가 연결되어 있다는 이유만으로 릴레이를 통해 전달되지 않습니다.

따라서 클라이언트 프로필은 서버 주소가 아니라 릴레이 이름을 가리키며, 직접 연결용으로 만든 기존 프로필은 변경 없이 동작하지 않습니다. 릴레이가 전달하지 않는 프로토콜을 전제로 설계하기 전에 실행 중인 버전의 지원 클라이언트 목록을 확인하십시오.

릴레이가 대신해 주지 않는 것

릴레이는 전송 수단입니다. 사용자, 가상 허브, 접근 정책, 경로를 만들지 않으며 서버 뒤의 사설 네트워크에 대해 아무것도 모릅니다. 원격 클라이언트가 LAN 서브넷에 도달해야 한다면 서버에는 여전히 브리지 또는 라우팅 구성, 반환 경로, 이를 가능하게 하는 방화벽 정책이 필요합니다. 양쪽 끝의 주소 계획이 겹치는 문제도 릴레이에는 보이지 않으며 직접 해결해야 할 과제로 남습니다.

지원되는 보안 설정도 직접 선택해야 합니다. 프로젝트 문서에는 오래된 플랫폼 예제가 있으며 오래된 스크린숏에서 구식 암호나 인증서 설정을 복사하는 것은 아무도 감사할 수 없는 터널을 만드는 좋은 방법입니다. 실행 중인 버전에 맞는 최신 지침을 사용하십시오.

인증서 검증과 사용자 인증은 서버의 책임으로 남으며 릴레이는 결코 둘 중 어느 것도 대체하지 않습니다.

의존성으로 운영하십시오

가용성에는 이제 제삼자가 포함됩니다. 릴레이에 도달할 수 없으면 서버가 아무리 건강해도 클라이언트는 연결할 수 없고, 외부에서는 클라이언트 문제처럼 보입니다. 릴레이 경로는 서버 자체의 상태와 분리해 감시하고, 정말 중요한 날을 위해 다른 주소의 직접 리스너 같은 문서화된 대체 수단을 마련해 두십시오.

지연은 사용자의 근접성이 아니라 릴레이의 지리에 따르므로, 이를 통해 대화형 성능을 약속하기 전에 측정할 가치가 있습니다.

서버의 신원을 확인한 다음 실제 애플리케이션 경로를 확인하십시오. 연결 성공 배너만으로는 부족합니다. 필요한 리소스가 릴레이가 전달하는 주소 체계로 도달 가능한지도 확인하십시오. 릴레이 이름, 사용한 프로토콜, 대체 수단을 기록해 두면 이 링크에 관한 앞으로의 질문 대부분에 답할 수 있습니다.