Windows 수신 VPN 또는 OpenVPN 호스트: 5분 안에 고르기

Windows는 운영체제 외에 아무것도 설치하지 않고 VPN 연결을 받아들일 수 있으며, 소유한 두 대의 컴퓨터가 한나절 동안 터널을 필요로 할 때 정말 도움이 됩니다. 유용한 기간은 대략 그 정도입니다. 내장 수신기에는 고정된 프로토콜 목록이 있고, 클라이언트별 정책이 없으며, 누군가 닫을 수 있는 데스크톱에 의존합니다. 그것과 라우터 끝점, OpenVPN 호스트 중에서 고르는 일은 선호가 아니라 세 가지 조건의 문제입니다.

내장 수신기의 실체

들어오는 연결 마법사는 워크스테이션을 작은 원격 접속 끝점으로 바꿉니다. 어떤 로컬 계정이 전화 접속할 수 있는지, 주소를 어떻게 나눠 주는지, 어떤 프로토콜이 켜져 있는지 선택합니다. PPTP에 더해 에디션과 인증서 작업이 지원하면 L2TP/IPsec 또는 SSTP입니다.

그것이 아닌 것은 정책 계층입니다. 사용자별 경로 할당이 없고, 서버가 강제하는 분할 터널도 없으며, 터널과 워크스테이션 자체의 네트워크 신원 사이에 분리도 없습니다. 연결한 클라이언트는 워크스테이션과 같은 세그먼트에 도착하며, 그 세그먼트의 방화벽 규칙 아래 놓입니다.

바로 이 마지막 점을 따져야 합니다. 워크스테이션 자체의 포트와 공유, 브라우저는 이제 계정을 가진 누구나 닿을 수 있고, 그 계정은 이미 할 수 있는 모든 것을 갖춘 로컬 Windows 계정입니다.

결정하는 세 가지 조건

접속이 얼마나 유지되어야 하는지, 몇 사람이 필요한지, 네트워크가 프로토콜을 아예 전달할 수 있는지 물어보십시오.

답이 한 대의 컴퓨터, 한 사람, 그리고 라우터를 직접 통제하는 네트워크에서의 몇 시간이라면 내장 수신기는 적절합니다. 접속이 한 달 동안 재부팅을 견뎌야 하거나, 별도 자격 증명을 가진 다섯 동료에게 제공해야 하거나, 들어오는 연결을 받을 수 없는 모바일 네트워크에서 써야 한다면 그렇지 않습니다. 프로토콜이 포트가 아니라 IP 프로토콜 47을 요구한다면, Windows가 무엇을 지원하든 네트워크가 전달을 거부할 수 있습니다.

이 세 가지 답은 논쟁의 대부분을 한 번에 없앱니다. 나머지는 구현 세부 사항입니다.

라우터 끝점이 이기는 경우

라우터에서 끝나는 터널은 상시 접속에 자연스러운 선택입니다. 라우터는 이미 항상 켜져 있고, 다른 사무실로 사이트 간 터널을 운반할 수 있으며, 라우터가 사용하는 프로토콜을 제공한다면 클라이언트에 아무것도 설치할 필요가 없습니다.

제약은 펌웨어입니다. 소비자용 라우터는 사양이 허용하는 것의 일부만 지원하는 경우가 많고, VPN 지원을 광고하는 모델이라도 계획한 바로 그 프로토콜이 없을 수 있습니다. 제품군이 아니라 설치된 펌웨어의 기능 목록을 확인하십시오.

OpenVPN 호스트가 이기는 경우

항상 켜져 있는 작은 컴퓨터의 OpenVPN 서버는 혼합된 클라이언트, 별도 자격 증명을 가진 여러 사용자, 그리고 나가는 트래픽에 유리한 포트 하나가 작동과 차단의 차이를 만드는 네트워크에 맞습니다. 클라이언트마다 프로필을 발급하고, 모든 주요 플랫폼에서 실행되며, 클라이언트 쪽에서는 평범한 아웃바운드 응용 프로그램처럼 동작합니다.

소유자도 필요합니다. 누군가는 인증서를 갱신하고, 호스트 업데이트를 적용하고, 클라이언트가 연결하지 못할 때 로그를 읽어야 합니다. 그 사람이 없으면 자체 호스팅 끝점은 정말 중요해지는 날까지 조용히 쇠퇴합니다.

접속을 약속하기 전에 경로를 확인하십시오

Windows 수신기가 실패하는 가장 흔한 이유는 인증이 아닙니다. 경로입니다. PPTP는 들어오는 TCP 1723과 GRE가 필요한데, GRE는 포트가 아니라 프로토콜 47이며, 많은 라우터는 포트만 전달합니다. 어떤 접속망은 들어오는 연결을 아예 허용하지 않습니다. 이 한 가지 사실이 어떤 Windows 설정보다 많은 네트워크에서 내장 수신기를 배제합니다.

계정을 구성하기 전에 경로를 시험하십시오. 실패의 후보가 셋이 아니라 하나가 되도록:

Test-NetConnection -ComputerName 203.0.113.45 -Port 1723
Get-NetAdapterBinding | Where-Object ComponentID -like ms_pptp
ss -lunp | grep 1194

첫 줄의 닫힌 포트는 전달이나 통신 사업자의 문제이지 Windows의 문제가 아닙니다. 셋째 줄은 OpenVPN을 고른 뒤 할 점검으로, 대기하는 UDP 포트 하나가 프로토콜 문제 전체를 대신합니다.

어떤 선택지를 고르든 PPTP를 장기 방안으로 인터넷에 향한 채 두지 마십시오. 그 인증과 암호화는 낡았습니다. 그리고 진짜 필요가 웹 응용 프로그램 하나라면, 역방향 프록시가 어떤 VPN보다 작은 답입니다.