Mac VPN 설정은 서버를 시작하지 않는다: 게이트웨이가 있는 곳

macOS에서 VPN이라는 이름은 서로 다른 두 작업에 붙어 있고, 설정 패널은 그중 하나만 다룹니다. 이 Mac의 트래픽이 공급자나 원격 게이트웨이를 통해 나가기를 원한다면 클라이언트 항목만으로 충분합니다. 호텔 방에서 집 네트워크의 프린터, NAS 또는 관리 페이지에 닿기를 원한다면 그 네트워크의 무언가가 바깥에서 오는 연결을 받아들여야 하며, 요즘 Mac은 기본 상태에서 그 무언가가 아닙니다. 세 가지 질문이 어느 경우인지를 정하며, 필드에 주소를 입력하기 전에 답해 둘 가치가 있습니다.

클라이언트 항목은 목적지를 지정하지, 리스너를 지정하지 않는다

macOS Ventura 이후의 시스템 설정 > 네트워크 > VPN에서 예전 릴리스가 네트워크 환경설정에 두던 필드는 다른 사람의 엔드포인트에 도달하는 방법을 설명합니다: 서버 주소, 원격 ID, 계정 또는 인증서, 그리고 선택적인 요청 시 연결 규칙입니다. 그 항목을 저장하면 Mac의 네트워크 구성에 연결이 기록됩니다. 이 과정 어디에도 포트를 묶거나 리스너를 열거나 원격 사용자를 등록하는 일은 없습니다.

셸에서 확인할 수 있습니다. 서비스하고 있다고 의심되는 Mac에서 sudo lsof -nP -iUDP 을 실행하고 프로토콜이 쓰는 포트를 보십시오: IKEv2는 500과 4500, OpenVPN 기본값은 1194, WireGuard는 51820입니다. 클라이언트뿐인 기계에는 원격 주소와 포트에 짝지어진 소켓이 보이며, 인터넷의 무엇이든 닿을 수 있는 와일드카드 바인딩은 없습니다. Network Extension 안에서 도는 터널은 lsof에서 숨을 수 있으므로 어느 쪽이든 앱의 상태 패널도 확인하고, 찾지 못할 것은 이 Mac을 게이트웨이로 바꾸는 Apple 설정 항목입니다.

세 가지 질문이 두 역할을 가른다

순서대로 처리하십시오. 첫 번째가 보통 나머지를 정하고, 세 번째가 Mac에 특화된 계획이 가장 많이 어긋나는 지점입니다.

1. 대화를 누가 시작하는가? Mac이 바깥으로 연결하고 상대가 응답한다면 클라이언트가 필요합니다. 인터넷의 장치가 당신의 네트워크에 닿으려면 안으로 연결해야 한다면 공개 진입점이 있는 게이트웨이가 필요하고, Mac은 그 게이트웨이의 클라이언트로 남을 수 있습니다.

2. 터널이 올라와 있는 동안 무엇이 닿아야 하는가? 한 호스트의 한 서비스라면 포트 포워딩의 결정입니다. 이름 해석을 포함한 서브넷 전체라면 라우팅과 DNS의 결정이며, 달라지는 것은 게이트웨이가 전달해야 할 대상이지 클라이언트 항목의 서술이 아닙니다.

3. 받아들이는 쪽은 어느 OS 릴리스에서 도는가? Mac의 경우 그 질문에는 단단한 답이 있고, Apple은 VPN을 macOS Server 5.7.1에서 제거된 것으로 기재하며, macOS Server 앱 자체는 2022년 사월 21일에 단종되었습니다. 그 서비스 이력 공지 가 더 이상 존재하지 않는 VPN 서비스 체크상자를 옛 자습서가 안내할 때 읽어야 할 페이지입니다.

첫 답이 “바깥의 누군가가 시작한다”라면 Mac의 클라이언트 패널에서 스위치를 찾는 일을 그만두고 터널을 끝낼 호스트를 고르십시오.

대신 게이트웨이가 있을 수 있는 곳

네 가지 배치가 가정과 소규모 사무실의 대부분을 덮습니다. 다른 이름표를 단 클라이언트 모드가 아니라 진짜 서버 모드를 갖춘 공유기는 터널을 경계에서 끝내고 호스트 수를 낮게 유지하지만, 그 펌웨어의 프로토콜 지원에 묶입니다. NAS나 항상 켜진 미니 PC는 공급자의 서버 패키지를 돌리고 읽을 수 있는 로그를 남깁니다. 작은 클라우드 VM은 당신이 통제하는 공개 주소를 주고 두 번째 터널로 집에 닿습니다. WireGuard 위에 세운 메시 오버레이나 피어 사이를 중계하는 관리형 서비스는 양쪽 끝을 바깥으로 연결하게 함으로써 들어오는 포트 포워딩을 피합니다.

그 선택지 사이의 경계는 보통 소프트웨어가 아니라 당신의 인터넷 연결입니다. ISP가 당신을 통신사 등급 NAT 뒤에 둔다면 공유기의 포트 포워딩을 아무리 해도 닿을 수 있는 진입점이 생기지 않으며, 중계나 메시 배치가 정직한 답입니다. 공유기가 보고하는 WAN 주소와 바깥 세상이 보는 주소를 비교하시고, 둘이 다르고 공유기의 값이 사설 또는 공유 범위에 있다면 중계 경우를 계획하십시오.

어느 호스트를 고르든 범위가 아니라 한 포트에 한 프로토콜을 전달하고, 실행 중인 macOS 릴리스에 대해 그 제품이 서버 역할을 문서화하지 않는 한 Mac을 들어오는 경로에서 빼십시오.

프로파일을 나눠 주기 전에 역할을 확인하십시오

후보 게이트웨이에서 설치 프로그램이 만들었으리라 믿는 대신 리스너가 존재함을 증명하십시오. macOS에서는 위 포트로 거른 sudo lsof -nP -iUDP, 패킷 필터 규칙이 설계의 일부라면 sudo pfctl -s nat 도 씁니다. Linux에서는 ss -lunp 이 같은 사실을 모호함 없이 보여 줍니다.

그다음 네트워크 바깥에서 프로토콜 자체로 시험하십시오. Ping이 증명하는 것은 적습니다: ICMP는 흔히 걸러지며 UDP 51820에 대해 아무 말도 하지 않습니다. 상세 로그를 켠 클라이언트 핸드셰이크를 셀룰러 데이터의 전화에서 실행하는 것이 가장 싼 실제 시험이며, 원격 동료가 지나갈 같은 경로를 지납니다.

그 뒤에야 클라이언트 프로파일을 건드립니다. Mac에서 scutil --nc list 은 시스템이 아는 VPN 서비스를 출력하는데, 방금 만든 게이트웨이가 그 안에 없다면 당신이 시험한 기계와 다른 기계를 설정하는 것입니다. 핸드셰이크가 LAN에서는 성공하고 바깥에서 실패한다면 원인은 들어오는 경로에 있습니다: NAT 규칙, 공급자의 CGNAT, 또는 게이트웨이의 방화벽, 그 순서입니다.

무엇이든 만들기 전에 네 가지를 정하십시오:

• 연결을 어느 쪽이 시작하는지, 당신의 Mac인지 원격 장치인지.
• 받아들이는 호스트의 OS 릴리스와 제품이 실제로 서버 역할을 지원하는지.
• ISP가 닿을 수 있는 공개 주소를 애초에 주는지.
• 게이트웨이가 받아들일 단일 포트와 프로토콜은 무엇이고, 그 뒤에서 어느 서비스가 응답하는지.

다음 단계는 구체적입니다: 게이트웨이 호스트를 고르고, 바깥에서 리스너를 확인하고, 그다음에야 Mac에서 그것을 가리키는 클라이언트 항목을 만드십시오.