NAT 뒤의 SoftEther: 직접 트래버설인가, VPN Azure 릴레이인가?

SoftEther 서버가 변경할 수 없는 공급자 라우터 뒤에 있고 클라이언트가 여전히 연결되므로, 릴레이가 모든 것을 운반한다고 가정하게 됩니다. 그것이 사실인지는 DNS 이름, 조정된 UDP 경로, 릴레이로 나가는 터널 중 어느 것이 작업을 했는지에 달려 있습니다. 셋 모두 연결된 클라이언트를 만들 수 있으며 서로 다른 조건에서 실패합니다. 사용자나 허브를 건드리기 전에 어떤 경로를 사는지 결정하십시오.

세 가지 메커니즘, 세 가지 다른 약속

동적 DNS는 이름 짓기입니다. 바뀌는 주소를 향해 호스트 이름을 유지해 사람들이 번호를 쫓지 않게 할 뿐, 다른 일은 하지 않습니다. 기본 NAT 트래버설은 조정입니다: 두 SoftEther 엔드포인트가 정보를 교환하고 그 사이의 변환 장치를 통해 쓸 수 있는 UDP 경로를 열려고 시도합니다. VPN Azure는 릴레이입니다: 서버가 서비스로 외부 접속하고, 클라이언트는 릴레이 인프라의 호스트 이름을 통해 도착합니다.

셋은 하나의 기능 버전이 아니라 서로 보완합니다. 배포가 이름 짓기를 쓰면서도 실제 연결은 트래버설이나 릴레이에 의존할 수 있습니다.

클라이언트와 네트워크에서 결정하십시오

선택은 클라이언트에서 시작합니다: 트래버설은 기본 SoftEther 연결 메커니즘에만 존재하기 때문입니다. 같은 서버의 OpenVPN, L2TP/IPsec, SSTP 리스너는 호스트를 공유해도 이를 물려받지 않습니다. 사용자가 무엇을 실행할지, 그다음 네트워크가 무엇을 허용하는지 보십시오. TCP 443만 허용하는 기업 네트워크는 그 포트의 릴레이로 밀어내고, 트래버설에 필요한 UDP 포트를 통과시키는 네트워크는 직접 경로를 시도할 수 있으며, 둘 다 실제 이그레스 정책에 비추어 확인하십시오.

수동으로 도달할 수 있는 리스너는 관리자가 하나를 게시할 수 있을 때 여전히 합당한 설계이지만, 자체 주소 지정과 방화벽 작업이 있는 별도 프로젝트입니다.

세션이 어떤 전송을 골랐는지 확인하십시오

연결 상태가 사용 중인 경로에 대한 유일하게 정직한 출처입니다. 서버에서 읽고, 클라이언트가 받은 호스트 이름을 확인하십시오.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList는 어떤 세션이 연결되어 있는지 보여 주고, 그중 하나에 대한 SessionGet은 세션이 릴레이를 통해 도착했는지 여부를 포함해 연결 유형을 보고합니다. 릴레이 인프라로 확인되는 레코드는 세션이 제삼자를 거친다는 뜻이며, 테스트에서 그 경로를 차단해 확인할 수 있습니다. 기본 클라이언트에서는 UDP 가속이 데이터 경로를 제어 경로에서 떼어 놓을 수 있으므로 한 번의 관측으로 세션 전체를 설명할 수 없습니다. 주소 변경 후 오래된 동적 DNS 이름과, 백엔드 경로가 없는데도 응답하는 릴레이는 따로 시험할 가치가 있는 두 가지 실패 모드입니다. 설계가 의도한 것이 아니라 실제로 측정한 것을 기록하십시오.

선택한 경로가 무엇에 의존하는지 계획하십시오

모든 경로에는 의존성이 따릅니다. 직접 트래버설은 네트워크 전환이나 새 변환 장치 뒤에서 바뀔 수 있고, 릴레이 세션은 서비스나 도달 가능한 포트가 실패하면 실패합니다. 다른 네트워크에서 다시 연결하고 클라이언트가 검증한 서버 ID를 확인하며, 이전에 작동한 경로를 같은 테스트에 남겨 두십시오. 그다음 VPN 뒤의 프라이빗 리소스를 시험하십시오: 권한 부여, 허브 구성원 자격, 주소 할당, 반환 경로는 어느 쪽이든 사용자의 책임으로 남기 때문입니다.

호스트 이름, 프로토콜, 기능 설정, 관측된 전송을 적어 두십시오. 그 네 부분 기록이 다음 사람이 작동하는 연결을 재현할 수 있게 합니다.