포트 검사기는 열렸다고 하는데? Minecraft 플레이어가 여전히 접속하지 못하는 이유

누군가 포트 검사를 실행하고 열림이라는 단어를 보고 서버가 해결되었다고 여긴다. 그 결과가 실제로 의미하는 것은 좁다. 검사기의 위치에서, 그 순간, 그 주소와 포트로 TCP 연결이 수락되었다는 것뿐이며, Minecraft 프로토콜 핸드셰이크나 계정 인증, 또는 서버가 플레이어를 월드에 들여보냈는지에 대해서는 아무것도 말하지 않는다.

이는 서로 다른 네 개의 계층이며, 그중 어디서든 실패하면 플레이어에게서는 안 됐다는 같은 말이 나온다.

프로브는 볼 수 있는 것만 시험한다

TCP 연결은 양쪽이 세 방향 핸드셰이크를 마칠 때 성립하며, 그것은 게임이 아는 모든 것보다 아래에 있다. 프로브는 리스너가 존재했고 자기 네트워크 위치에서 응답했다고 보고한다. 어떤 프로세스든 포트를 잡고 연결을 받을 수 있으므로 리스너가 게임이라고 말할 수는 없다.

위치는 결과만큼 중요하다. 공용 인터넷의 검사기는 한 네트워크에서 한 경로를 시험한다. 운영자가 같은 네트워크 안에서 실행하는 검사기는 전혀 다른 경로를 시험하며, 거기서의 긍정적 결과는 원격 플레이어가 무엇을 겪는지 거의 말해 주지 않는다. 서로 다른 두 제공자의 서로 다른 검사기는 심지어 당신의 서버와 무관한 이유로 서로 다른 답을 낼 수 있다.

시점도 중요하다. 프로브 결과는 실행된 순간을 설명하며, 동적 주소나 변경된 포워딩 규칙이 있는 가정용 연결은 실제 답을 몇 분 뒤로 옮길 수 있다. 공인 주소, 포트, 주소 체계, 시각을 판정과 함께 기록하지 않으면 그 관찰은 재현할 수 없다. 같은 연결의 휴대폰이 아니라 정말로 다른 네트워크에서 검사를 반복하라.

소켓과 플레이어 사이의 네 계층

접속하는 클라이언트가 실제로 수행하는 순서를 그려 보라. 먼저 주소를 해석하고, 다음으로 공개된 포트로 TCP 연결을 열고, 다음으로 협상과 인증을 위해 게임 자체의 프로토콜로 말하고, 마지막으로 서버가 그 신원을 월드에 들일지 결정한다. 각 계층에는 고유한 실패 서명이 있고, 포트 검사기에 보이는 것은 첫 번째뿐이다.

Java Edition의 기본 포트는 25565이지만, 운영자는 다른 외부 포트를 공개하고 그것을 안쪽으로 포워딩할 수 있으므로 플레이어가 입력하는 번호가 서버가 보는 번호와 반드시 같지는 않다. 잘못된 외부 포트를 겨냥한 검사기는 서버가 완전히 건강한데도 닫혔다고 보고하며, 이것이 이 분야 전체에서 가장 흔한 오경보다.

이름은 포트 위에 한 단계를 더한다. 플레이어가 호스트 이름을 입력하면 해석이 공개된 주소를 반환해야 하며, 네트워크 안의 머신에서는 대신 사설 주소를 반환할 수 있다. 그것은 방화벽 실패가 아니며, 아무리 포트 포워딩을 해도 바뀌지 않는다.

안쪽 플레이어가 다른 경로를 택하는 이유

같은 LAN에 있거나 그 LAN에 도달하는 VPN에 있는 플레이어는 안쪽에서 공인 주소에 닿으려 한다. 요청은 라우터의 외부 주소로 가고 라우터는 그것을 다시 안쪽으로 변환해야 하며, 이것이 흔히 헤어핀 또는 NAT 리플렉션이라 불리는 구성이다. 이것이 동작하려면 나가는 변환과 돌아오는 경로가 모두 맞아야 하며, 많은 가정용 라우터는 아예 구현하지 않는다.

그래서 바깥의 손님은 접속하고 서버 옆에 앉은 사람은 접속하지 못한다. 외부 경로는 정말로 멀쩡하다. 실패하는 것은 내부 우회이며, 플레이어 화면에서는 서버 문제처럼 보이는 방식으로 실패하지만, 한 번도 변환되지 않은 연결은 결코 서버에 도달하지 않으므로 어느 쪽이 일어났는지는 서버 자체의 로그가 판정한다.

정직한 두 가지 해결책과 나쁜 습관 하나가 있다. 좋은 선택은 내부 플레이어가 사설 주소나 내부에서 사설 주소로 해석되는 split-DNS 이름을 사용하게 하는 것, 또는 그 기능이 있고 제대로 동작한다면 라우터에서 리플렉션을 켜는 것이다. 나쁜 습관은 포트를 더 열거나 호스트 방화벽을 끄는 것이며, 그것은 라우터가 한 번도 하지 않은 변환에 영향을 줄 수 없다.

Netgate의 NAT 리플렉션 문서는 외부와 내부의 구분과 split-DNS 대안을 더 자세히 설명한다. 그것을 메커니즘의 설명으로 읽고, 특정 VPN 제공자나 라우터가 모든 루프백 변형을 지원한다는 약속으로 읽지 말라.

각 관점에서 증거를 모아라

각 테스트마다 누가, 어디서, 몇 시에, 어느 주소와 포트를 상대로 실행했고 서버가 무엇을 기록했는지 적어라. 서버 콘솔에 분명한 이유가 있는 게임의 거부는 결코 도착하지 않은 연결과는 다른 발견이며, 둘은 반대 방향으로 이끈다.

허용된 원격 플레이어는 접속하는데 로컬 플레이어 한 명이 안 된다면, 남은 질문은 로컬 경로이며 그것은 별도의 조사가 필요하다. 클라이언트가 어느 주소를 썼는지, 라우터가 변환을 어떻게 했는지, 서버가 연결 시도를 아예 기록했는지라는 세 가지 사실을 포트를 무작위로 다시 여는 대신 네트워크 소유자에게 넘겨라.