분할 터널은 게임이 아니라 런처를 제외합니다

런처를 제외 목록에 추가하면 다운로드가 느린 상태에서 빠른 상태로 뛰어오르고, 경기는 여전히 먼 서버에 도착합니다. 아무것도 고장 나지 않았습니다. 런처와 게임은 두 세트의 소켓을 가진 두 프로세스이며, 하나를 제외한다고 다른 하나에 대해 말할 수 있는 것은 없습니다. 다운로드가 빨라진 것은 다운로드가 런처의 트래픽이었기 때문이며, 경기는 다른 누군가의 연결로, 당신의 규칙이 본 적 없는 실행 파일이 열었습니다.

설치 프로그램 하나, 여러 프로세스

현대 게임 소프트웨어는 작은 별자리입니다. 로그인을 처리하는 클라이언트, 콘텐츠를 가져오는 업데이터, 게임을 시작하는 런처, 그리고 안티치트나 매치메이킹 오버레이를 위해 스스로 두 번째 프로세스를 만들 수 있는 게임 실행 파일이 있습니다. 각각은 자신의 목적지로 향하는 자신의 연결을 유지할 수 있습니다.

제외 규칙은 보통 그중 하나를 지목합니다. 어느 것을 지목하는지는 VPN 클라이언트가 지원하는 식별자에 전적으로 달려 있으며, 바로 그 부분을 사용자는 거의 확인하지 않습니다. 일부 클라이언트는 실행 파일 경로를 맞추고, 일부는 패키지나 번들 식별자를 맞추며, 일부는 서로 무관한 두 바이너리가 공유할 수 있는 프로세스 이름을 맞춥니다. 규칙은 표현할 수 있는 것조차 제한하기 때문에 프로세스 목록보다 규칙을 먼저 읽으세요.

따라서 증상은 “분할 터널이 고장 났다”가 아닙니다. “규칙이 내가 신경 쓰는 트래픽을 나르는 프로세스가 아닌 프로세스를 포함한다”이며, 이는 훨씬 좁고 훨씬 고치기 쉬운 진술입니다. 그렇게 말하면 다음 단계는 더 이상 추측이 아닙니다.

경기 연결을 소유한 프로세스 찾기

게임을 시작하고 경기에 들어가서 화면에 무엇이 있는지가 아니라 누가 소켓을 소유하는지 보세요. Windows에서는 프로세스 목록과 프로세스별 소켓 쿼리가 두 명령으로 답합니다:

Get-Process | Where-Object { $_.ProcessName -match 'launcher|game|client' } | Select-Object Id,ProcessName,Path
Get-NetTCPConnection -State Established | Select-Object OwningProcess,RemoteAddress,RemotePort | Sort-Object OwningProcess

두 번째 명령은 이름이 아니라 프로세스 ID를 출력하므로 두 출력을 ID로 연결하세요. 찾는 행은 원격 주소가 게임 서비스에 속한 행이며, 이를 소유한 프로세스가 규칙에서 지목해야 하는 실행 파일입니다.

Linux에서는 같은 질문에 소켓 유형별로 명령 하나가 필요하며, 둘 다 확인할 가치가 있으며, 경기 연결은 UDP인데 나머지는 모두 TCP일 수 있기 때문입니다:

ss -tunp state established | grep -i game
ss -tunp | awk 'NR==1 || /udp/'

게임이 컨테이너나 호환성 계층에서 실행되면 찾은 프로세스가 설치한 바이너리가 아니라 심(shim)일 수 있습니다. 그 경우 중요한 식별자는 클라이언트가 보는 것이며, 심의 경로일 수 있고, 원본 파일을 아무리 편집해도 영향을 주지 않습니다.

클라이언트가 지원하는 식별자 맞추기

무엇이든 추가하기 전에 제외 규칙에 대한 클라이언트 문서를 읽으세요. 흔한 세 모델은 다르게 동작하며, 그중 하나는 함정입니다.

경로 규칙은 가장 정확하고 가장 취약합니다. 실행 파일을 옮기는 런처 업데이트는 규칙이 더 이상 실행되지 않는 파일을 가리키게 남기며, 눈에 띄는 변화 없이 증상이 돌아옵니다. 패키지 규칙은 그런 일을 견디고, 생각하지 못한 도우미 프로세스까지 조용히 포함할 수 있으며, 이는 도우미에 따라 편리하거나 우려스럽습니다.

클라이언트가 무엇을 지원하든, 찾을 수 있는 모든 실행 파일에 항목을 추가하지 마세요. 한 세션이 작동할 때까지 시행착오로 만든 목록은 검토할 수 없고, 무관한 소프트웨어에 대한 예외를 조용히 쌓아갑니다. 찾은 프로세스를 지목하고 그것이 무엇을 위한 것이었는지 적어 두세요.

다운로드가 아니라 경기에서 테스트하기

런처의 다운로드 속도는 가능한 최악의 테스트인데, 이미 제외된 프로세스를 정확히 운동시키기 때문입니다. 실패하던 것을 사용하고, 게임 자체의 성능 표시가 아니라 경로를 확인하세요:

ip route get 203.0.113.55
Get-NetTCPConnection -State Established | Where-Object RemotePort -eq 27015

첫 번째 명령에는 경기 서버가 확인된 주소가 필요하며, 게임의 연결 로그나 클라이언트가 알려줄 수 있습니다. 경로가 물리 인터페이스를 지목하면 규칙이 작동합니다. 두 번째는 세션이 존재하는지 보여 주며, “제외되었지만 서버가 다운됨”과 “제외되지 않음”을 구분합니다.

테스트하는 동안 지역과 액세스 네트워크를 고정하세요. 시도할 때마다 다른 데이터 센터에 도착하는 경기는 다른 주소를 만들며, 규칙을 검증하는 대신 움직이는 표적을 쫓게 됩니다. 같은 주소로 두 번 실행하는 것이 다른 주소로 열 번 하는 것보다 가치 있습니다.

다음 업데이트 후 다시 확인하기

경로 기반 규칙은 패치 주기로 측정되는 수명이 있습니다. 한 달 뒤 게임이 제외를 따르지 않으면 먼저 실행 파일이 이동했는지 확인하고, 다음으로 그 옆에 새 도우미 프로세스가 나타났는지 확인하세요.

한 클라이언트가 문서화한 애플리케이션 제외 모델은 이러한 규칙이 설명되는 방식에 대한 합리적인 참고 자료이지만 세부 사항은 제품마다 다릅니다. 자신의 문서를 읽고, 사용한 식별자를 기록하고, 날짜를 적으세요. 그 기록이 다음에 런처가 업데이트를 배포할 때 미스터리를 오 분 수정으로 바꿉니다.

클라이언트가 필요한 경계를 도저히 표현할 수 없다면, 승인된 더 넓은 정책이 문서화되지 않은 예외 더미보다 낫습니다. 넓고 이해되는 것이 좁고 틀린 것보다 이기며, 특히 좁은 버전이 모두가 시행 중이라고 믿는 것일 때 그렇습니다.