OpenVPN 너머 LAN 게임 목록이 비었나요? 검색 경로를 확인하세요

다른 플레이어의 터널 주소로 핑을 보내는 것과 그가 호스트한 게임이 보이는 것은 서로 다른 성과입니다. 로비 목록은 보통 단일 로컬 네트워크를 위해 작성된 검색 교환에 의존하는 반면, 게임 세션은 주소와 포트로의 평범한 연결입니다. 빈 목록을 라우팅 실패로 취급하면 필요하지도 않을 브리지로 향하게 되므로, 무엇이든 바꾸기 전에 두 질문을 분리하세요.

세션 참여와 세션 탐색을 분리하세요

참여 실패는 라우트, 방화벽 규칙, 대기 중인 서비스를 가리킵니다. 빈 목록인 채로 참여가 성공하면 검색이나 알림이 담고 있는 주소를 가리킵니다. 이 두 결과는 전혀 다른 작업으로 이어지며, 첫 번째를 의도적으로 시도해야만 구분할 수 있습니다.

VPN 설정을 건드리기 전에 결과를 적어 두세요. 이것은 전체 조사에서 가장 저렴한 시험이며 설계 공간의 절반을 없앱니다. 사용한 주소도 기록하세요. 이후 모든 시험의 기준점이 되기 때문입니다. 노트에 그 한 줄이 없으면 다음 비교는 추측일 뿐입니다.

터널을 건드리기 전에 직접 참여를 시험하세요

게임이 직접 연결 옵션을 제공한다면 호스트의 터널 주소와 문서화된 게임 포트를 사용하고, 게임 자체의 인증과 호스트의 방화벽 규칙은 그대로 두세요. 참여가 성공하면 문제는 검색으로 좁혀집니다. 실패한다면 여전히 별도의 조사가 필요하며, 어떤 릴레이도 그것을 고치지 못합니다.

검색 포트와 세션 포트가 같은 번호라고 가정하지 마세요. 게임은 보통 한 UDP 포트에서 알리고 다른 포트에서 플레이어를 받으며, 잘못된 포트를 위해 만든 릴레이는 여전히 빈 목록을 만듭니다.

호스팅 프로세스가 어떤 어댑터를 선택했는지도 확인하세요. 홈 LAN 주소에 묶인 프로세스는 그 주소를 알리게 되고, 알림이 도착하더라도 원격 플레이어는 그곳으로 라우팅할 수 없습니다. 목록이 채워져도 그 이유만으로 참여가 실패할 수 있습니다.

브로드캐스트가 어디서 멈추는지 이해하세요

라우팅된 TUN 터널은 피어 사이로 IP 패킷을 운반하며 각 피어의 네트워크에서 로컬 브로드캐스트를 재현하지 않습니다. 제한 브로드캐스트 주소 255.255.255.255 는 그것을 내보내는 인터페이스 안에 머물고, 서브넷으로 향하는 브로드캐스트는 별개의 사례이지 라우터가 알림을 범람시켜도 된다는 일반 허가가 아닙니다.

이것은 설계의 성질이며, 옵션으로 덧대울 결함이 아닙니다.OpenVPN의 client-to-client 설정은 터널 내부의 피어 트래픽을 제어하며 검색 릴레이가 아닙니다. 많은 스레드에서 이 목적을 위해 제안되지만 말입니다. 릴레이는 자체 구성과 자체 고장 모드를 가진 별개의 구성 요소입니다. 기존 옵션이 이미 그것을 덮는다고 가정하는 것이 이 조사가 멈추는 가장 흔한 이유입니다.

멀티캐스트 검색은 다른 주소 클래스로 같은 문제를 겪으며, 브로드캐스트 예외가 아니라 멀티캐스트 라우팅이나 릴레이가 필요합니다.

릴레이가 정당할 때는 범위를 좁게 유지하세요

자동 검색이 요구 사항이라면 먼저 실제 교환을 식별하세요. 브로드캐스트인지 멀티캐스트인지, 목적지 주소, UDP 포트, 그것을 보내는 인터페이스, 응답 안의 주소입니다. 이 다섯 가지 사실로 제한된 프로토콜에 맞는 릴레이는 전체 Ethernet 세그먼트를 확장하는 것보다 훨씬 좁습니다.

패킷을 그대로 전달하는 것만으로는 부족할 수 있습니다. 페이로드가 수신자에게 도달할 수 없는 주소로 연결하라고 지시한다면 릴레이는 쓸모없는 응답을 전달합니다. 그래서 어떤 릴레이가 존재하기 전에 게임 자체의 인터페이스나 알림 주소 설정을 시도해야 합니다.

릴레이는 그것이 필요한 인터페이스와 피어로 제한하고, 응답이 요청자를 어떻게 찾는지 정의하세요. 무관한 브로드캐스트를 반복하면 다른 로컬 서비스가 노출되고 나중에 디버깅하기 괴로운 루프가 생깁니다.

설계가 Ethernet을 필요로 할 때만 브리지하세요

Ethernet 프레임은 TAP 안을 흐르므로 TAP 터널은 의도적으로 브리지된 브로드캐스트 도메인에 속할 수 있습니다. 단지 dev tun 를 dev tap 로 바꾸는 것은 그 브리지를 만들지 않고, 서버 구성을 호환되게 하지도 않으며, 애플리케이션이 새 인터페이스를 선택하게 하지도 않습니다.OpenVPN 브리징 가이드는 빈 로비 하나에 대한 치료가 아니라 더 넓은 배치를 설명합니다.

브리징은 주소 계획도 평평하게 만듭니다. 그래서 이 결정은 조급함을 넘어선 이유를 가질 자격이 있습니다. 분리되어 있던 두 네트워크가 하나가 되고, 양쪽의 모든 서비스가 상대편의 브로드캐스트를 보기 시작합니다. 그 결과는 누군가 그것을 켜기 전에 변경 기록에 들어가야 합니다. 게임 클라이언트가 192.168 대역에 있어야 한다는 규칙은 없습니다. 겹치지 않는 계획을 고르고, 포럼 글이 그렇게 했다는 이유로 터널의 번호를 다시 매기는 대신 해당 게임의 제한을 확인하세요.

마지막에는 두 결과를 분리해 두세요. 호스트에 참여할 수 있는지, 그리고 검색 응답이 다른 플레이어가 실제로 사용할 수 있는 목적지를 알리는지입니다. 첫 번째를 확인하지 않고 두 번째를 고치는 것이, 브로드캐스트와 무관했던 문제를 위해 브리지를 유지하게 되는 경로입니다.