여럿이 게임을 설치하고 같은 네트워크에 연결했는데 빈 서버 목록이 보인다. 반사적으로 네트워크를 탓하며 터널을 찾지만, 게임이 터널이 실어 나를 패킷을 애초에 보내지 않았을 수 있다. VPN이 등장하기 전에, 누군가 멀티플레이를 누를 때 그 에디션이 세 가지 중 무엇을 실제로 하는지부터 확인하자.

세 가지는 서로 바꿔 쓸 수 없다. 하나는 직접 로컬 트래픽을 쓰고, 하나는 서비스에 누가 더 하는지 묻고, 하나는 계정 없이는 시작을 거부한다. 터널은 첫째에 도움이 되고, 둘째에는 무관하며, 셋째는 고칠 수 없다. 이 순서가 중요한 이유는 셋 모두 같은 빈 목록을 만들면서 해결책은 세 가지로 다르기 때문이다.

게임이 호스트를 나열하기 전에 확인하는 것

대부분의 멀티플레이 메뉴는 몇 가지를 순서대로 한다. 로그인한 계정을 확인하고, 에디션 권한을 확인하고, 로비나 친구를 백엔드에 조회하고, 그다음에야 로컬 네트워크를 본다. 어느 단계든 조용히 실패할 수 있고, 화면은 보통 두 경우 모두 같은 빈 목록을 보여 준다. 그래서 «LAN이 고장 났다»는 화면만으로 내릴 수 있는 진단이 아니다. 백엔드 오류, 만료된 권한, 격리된 서브넷은 로비 화면에서 구별되지 않으며, 그중 네트워크 문제는 하나뿐이다.

네트워크 설정을 바꾸기 전에 그 에디션 자체의 문서를 읽어라. 리마스터는 직접 IP 접속을 없애고, LAN 검색을 호스팅 로비로 바꾸고, 원판에는 필요 없던 플랫폼 계정을 요구하는 일이 흔하다. 예를 들어 현재 Age of Empires II: Definitive Edition의 지원 페이지는 게임 서버에서 호스팅되는 로비를 설명하며, 거기서 공개 범위, 비밀번호, 지역을 고른다. 그것은 그 에디션에서 확인해야 할 애플리케이션 흐름이지, 이전 어떤 버전에 대한 증거가 아니다.

에디션 이름뿐 아니라 빌드 번호도 적어 두어라. 패치가 게임을 한 모델에서 다른 모델로 옮길 수 있고, 출시 빌드용으로 쓰인 안내가 더 이상 없는 메뉴를 설명할 수 있다.

검색 패킷은 첫 라우터에서 죽는다

직접 LAN 플레이는 보통 브로드캐스트나 멀티캐스트에 의존한다. 호스트가 서브넷 전체 주소로 자신을 알리고, 클라이언트가 그 알림을 듣는다. 이런 패킷은 설계상 라우팅되지 않으므로 두 기기 사이의 라우터는 유니캐스트 트래픽이라면 통과할 경우에도 이를 버린다. 같은 스위치에 있는 두 기기는 서로를 보고, 같은 두 기기가 다른 VLAN이나 클라이언트 격리가 켜진 게스트 네트워크에 있으면 서로를 보지 못한다. 콘솔과 휴대폰도 대개 자체 검색 프로토콜로 같은 방식을 따르므로, 플랫폼이 게임만큼 중요하다.

«같은 Wi-Fi인데 서버가 없다»는 보고의 대부분이 여기서 나온다. 격리가 켜진 게스트 SSID, 콘솔을 별도 세그먼트에 두는 메시 구성, 로컬 서브넷을 공용으로 취급하는 방화벽 프로필은 각각 일반 인터넷 접속을 남겨 둔 채 검색을 깨뜨린다. 게임 탓으로 돌리기 전에 클라이언트 격리 설정과 서브넷 마스크를 확인하라.

로비 서비스는 네트워크 경로가 아니다

게임이 호스팅 로비를 쓰면 경기 목록은 운영자 서버에서 오고, 당신의 서브넷에서 오지 않는다. VPN은 그 서버로 가는 패킷 경로를 바꾸지만, 서비스가 어떤 로비를 보여 주는지, 경기가 어느 지역에서 호스팅되는지, 계정에 참가 권한이 있는지는 바꾸지 않는다. 그것은 백엔드가 주는 답이며, 어떤 라우팅도 바꾸지 못한다.

그 모델에서 터널은 잘해야 지연 변수이고, 나쁘면 지리 탐지 문제다. 서비스는 당신의 거리 주소가 아니라 출구 주소를 보기 때문이다. 같은 논리가 친구 초대와 파티 시스템에도 적용된다. 그것들은 플랫폼이 중개하는 계정 수준 기능이라, 같은 LAN의 두 플레이어가 로비에서 서로를 못 보면서도 둘 다 낯선 사람의 경기에는 참가할 수 있다.

터널이 다시 만들 수 있는 것과 없는 것

터널은 플레이어가 서로 다른 장소에 있고 게임이 주소로 직접 접속을 지원할 때 유용하다. 라우팅 터널은 두 사이트 사이에서 유니캐스트 트래픽을 나르고, 브리지 터널이나 가상 이더넷 세그먼트를 제공하는 오버레이라면 직접 LAN 플레이가 의존하는 브로드캐스트 검색도 나를 수 있다. 이해해야 할 차이는 이것이다: 라우팅은 서브넷 사이로 패킷을 옮기고, 브리징은 두 사이트를 하나의 서브넷처럼 보이게 한다.

터널이 못 하는 것은 애플리케이션이 구현하지 않은 멀티플레이 모드를 더하는 일이다. 에디션이 직접 접속을 없앴다면 가상 LAN 세그먼트로도 되살릴 수 없다. 로비가 계정을 요구한다면 터널로 그 검사를 통과하지 못한다. 그리고 두 기기가 같은 NAT 뒤에 있고 사이에 격리가 있다면 오버레이로 격리를 우회할 수는 있지만, 그것은 정책 우회이기도 하므로 네트워크를 운영하는 사람과 상의할 일이다.

게임이 실제로 쓰는 경로를 시험하라

같은 서브넷에 호스트 하나와 클라이언트 하나를 두고, 격리를 끄고 터널 없이 시작하라. 그것이 되면 게임과 에디션이 하려는 일을 지원하는 것이고, 이후의 실패는 경로 문제다. 거기서 실패하면 터널은 애초에 답이 아니었다.

그다음 접속 방식, 포트나 검색 방식, 계정 요구에 대해 설명서가 뭐라고 하는지 기록하라. 한 번에 변수 하나만 바꿔라. 먼저 서브넷, 다음 세그먼트, 마지막 터널이다. 호스트 주소와 정확한 메뉴 경로를 적어 두면 다음 세션에서 논쟁을 되풀이하는 대신 시험을 재현할 수 있다.

버전, 누가 호스트하는지, 사람들이 어떻게 접속하는지, 그 세션에 어떤 계정이나 구독이 필요한지 정하고 날짜 전에 적어 두어라. 그것은 어떤 터널보다 많은 논쟁을 끝내고 무엇을 시험했는지 기록을 남긴다.

관련 글