VPN 포트 요구 사항: 비교 전에 적어야 할 세 줄

VPN 서비스의 포트 목록은 그것이 중요한지를 결정하는 세부 사항, 즉 누가 연결을 시작하는지를 빠뜨린 채 비교 페이지 사이에서 복사된다. 나가는 TCP 443을 허용하는 규칙은 다른 호스트가 여러분의 기기에서 대기 중인 리스너에 도달할 수 있는지에 대해 아무것도 말하지 않는다. 하나의 요금제를 비교하기 전에 세 가지 요구 사항을 따로 적고, 여러분의 작업에 실제로 필요한 것이 어느 것인지 표시하라. 그 종이가 있으면 대부분의 비교는 하나의 짧은 질문으로 줄어든다.

어떤 포트 목록을 읽기 전에 요구 사항을 나눠라

세 줄이 거의 모든 경우를 덮는다: 터널 너머의 목적지에 도달하는 것, 다른 사람이 안으로 연결할 수 있도록 무언가를 게시하는 것, 터널 자체를 운반하는 것이다. 각 줄은 서로 다른 이유로 실패하며, 하나를 충족하는 제공자 정책이 나머지 둘을 건드리지 않을 수 있다. 작업을 올바른 줄에 배치하는 데는 오 분이 걸리고 나중의 논쟁을 아낀다.

마케팅 문구는 세 줄을 일부러 흐리게 만든다. P2P 허용은 목적지 정책을 설명하고, 전용 주소는 주소를 설명하며, 포트 제한이 없다는 주장은 보통 요금제가 그것들을 나열하지 않는다는 뜻이다. 그 문구들 중 어느 것도 나머지에 답하지 않는다.

구체적인 흐름 하나를 골라 문장으로 써라: 시작자, 전송, 포트, 주소 체계, 방향. 원격 호스트로 업로드하는 야간 백업 클라이언트는 나가는 것뿐이다. 책상 위에서 친구들이 접속하는 게임 서버는 들어오는 것이다. 둘 다 하나의 터널로 돌린다는 것은 그 종이에 두 줄이 모두 필요하다는 뜻이지 그 사이의 타협이 아니다.

나가는 접근은 터널이 아니라 목적지 정책에서 실패한다

변환하는 게이트웨이를 지나는 나가는 트래픽은 상태를 만든다. 내부 주소와 포트에서 나온 첫 패킷이 변환 항목을 만들고 응답이 그것과 일치하는데, 이것이 RFC 3022에 설명된 매핑 동작이다. 브라우저 탭이 보통 포트 요청 없이도 작동하는 이유가 바로 이 메커니즘이다.

그래도 두 가지가 그것을 깨뜨린다. 출구 노드가 남용 가능하다고 보는 목적지나 포트 번호를 걸러낼 수 있고, 애플리케이션이 출구 정책이 전혀 예상하지 못한 포트에서 대기하고 있을 수 있다. 안으로 들어오는 규칙이 아니라 목적지 쌍에 대해 물어보고, TCP와 UDP에 대해 다른 답을 기대하라.

논쟁하기 전에 측정하라. 터널 뒤에 놓일 기기에서 이것들을 실행하라, 터널을 내린 상태에서 한 번, 올린 상태에서 한 번:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com

같은 명령, 같은 목적지, 두 가지 터널 상태는 운영자에게 조치할 수 있는 전후 비교를 준다. 문서용 주소를 실제로 필요한 호스트로 바꿔라, 중요한 것은 비교가 반복된다는 것이지 어떤 숫자가 인상적으로 보이는 것이 아니다.

들어오는 게시에는 매핑, 주소, 수명이 필요하다

공개 측에서 무언가가 어디로 전달할지 모르는 한 바깥의 어떤 것도 여러분의 리스너로 연결을 시작할 수 없다. 운영자가 보유한 고정 포트 예약, 클라이언트가 UPnP, NAT-PMP 또는 PCP를 통해 요청한 매핑, 라우팅된 공개 주소는 서로 다른 세 가지 제품이며 서로 다른 세 가지 한계를 가진다.

그중 어느 것에든 다섯 가지를 물어라: 어떤 프로토콜인지, 어떤 외부 포트인지, 외부 포트가 로컬과 달라도 되는지, 어떤 주소 체계를 덮는지, 재연결 후 매핑이 얼마나 유지되는지. 활성 세션에 묶인 예약은 그 세션이 끝나면 사라진다, 요금제 페이지가 무엇을 말하든.

먼저 로컬 쪽 절반을 확인하라, 죽은 리스너와 막힌 들어오는 경로는 밖에서 보면 똑같기 때문이다:

ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

로컬 요청이 200을 돌려주는데 여러분이 통제하지 않는 네트워크에서 온 요청이 여전히 시간 초과된다면, 그 간극은 공개 측에 있다. 애플리케이션을 이름으로 설명하는 대신 운영자에게 프로토콜과 외부 포트를 알려야 할 순간이다.

터널 자체의 전송은 별개의 질문이다

운반 포트는 문제의 가장 작은 부분이며 가장 찾기 쉽다. 기본값은 프로토콜마다 다르고, 클라이언트가 협상할 수 있는 것이 어떤 요금제 설명보다 중요하다.

나가는 UDP를 버리는 네트워크는 TCP 443 터널을 받아들이고 UDP 터널은 거부하므로, 대체 모드는 요구 사항 종이에 속한다. 운반을 바꾸는 것은 터널 안의 애플리케이션 포트를 옮기지 않고 목적지 정책을 넓히지도 않는다; 그것들은 각자의 줄에 남는다.

거기 있는 동안 단편화를 한 번 시험할 가치가 있다, 연결된 뒤 큰 전송에서 멈추는 터널은 보통 닫힌 포트가 아니라 잘못된 MTU를 갖기 때문이다:

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

Windows에서는 같은 시험이 ping -f -l 1400 203.0.113.10이다. 통과하는 가장 큰 크기 아래로 터널의 MTU를 설정하고, 실패한 전송을 다시 시험하라.

요금제에 돈을 내기 전에 세 줄을 검증하라

세 줄을 한 페이지에 놓고 각 칸을 약속이 아니라 측정된 결과로 채워라. 이 명령들은 그 페이지의 로컬 절반을 약 일 분에 만들어 낸다:

ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10

출력을 점검 목록으로 읽어라. 터널이 올라간 상태에서 목적지가 응답하면 나가는 것이 작동한다. 들어오는 것은 여러분의 네트워크 밖의 호스트가 외부 포트의 리스너에 도달할 때만 작동한다. 운반은 여러분의 접속 네트워크가 허용하는 프로토콜에서 핸드셰이크가 완료될 때 작동한다.

두 가지 습관이 그 종이를 정직하게 유지한다. 각 결과 옆에 날짜와 클라이언트 버전을 기록하라, 제공자 정책과 클라이언트 기본값이 모두 움직이기 때문이다. 그런 다음 그 흐름을 지원하는 가장 좁은 매핑을 요청하라, 모든 것을 열어 달라는 요청은 보통 기술적 답 대신 거절이나 추가 판매를 얻기 때문이다.