Порожній список ігор LAN через OpenVPN? Перевірте шлях виявлення
Знайти розміщену гру і приєднатися до неї — два різні шляхи. Перевірте адресу сеансу, прочитайте, що оголошує лобі, а потім зважте релей і міст.
Пінгувати адресу тунелю іншого гравця і бачити його розміщену гру — два різні досягнення. Список у лобі зазвичай залежить від обміну виявлення, написаного для однієї локальної мережі, тоді як сеанс гри — це звичайне з'єднання з адресою та портом. Якщо вважати порожній список збоєм маршрутизації, ви підете до мосту, який може бути не потрібен, тому розділіть два питання, перш ніж щось змінювати.
Відокремте приєднання до сеансу від його пошуку
Невдале приєднання вказує на маршрути, правила брандмауера та службу, що слухає. Успішне приєднання з порожнім списком вказує на виявлення або на адресу, яку несе оголошення. Ці два результати ведуть до цілком різної роботи, і розрізнити їх можна, лише свідомо спробувавши перший.
Запишіть результат, перш ніж торкатися конфігурації VPN. Це найдешевший тест у всьому розслідуванні, і він відсікає половину простору рішень. Запишіть і адресу, яку використовували, бо вона стане точкою відліку для кожного наступного тесту. Без цього рядка в нотатках наступне порівняння — здогад.
Перевірте пряме приєднання, перш ніж торкатися тунелю
Якщо гра пропонує пряме з'єднання, використайте адресу тунелю хоста й задокументований порт гри, а власну автентифікацію гри та правила брандмауера хоста залиште недоторканими. Успішне приєднання звужує проблему до виявлення. Невдалому приєднанню все ще потрібне власне розслідування, і жоден релей його не виправить.
Не припускайте, що порт виявлення і порт сеансу — одне й те саме число. Ігри зазвичай оголошують на одному порту UDP і приймають гравців на іншому, а релей, збудований для неправильного, дає список, який усе одно залишається порожнім.
Перевірте також, який адаптер вибрав процес хостингу. Процес, прив'язаний до адреси домашньої LAN, оголосить саме цю адресу, і віддалений гравець не зможе маршрутизувати до неї, навіть якщо оголошення дійде. Список може заповнитися, а приєднання все одно не вдасться лише через це.
Зрозумійте, де закінчується широкомовлення
Маршрутизований тунель TUN переносить IP-пакети між вузлами і не відтворює локальне широкомовлення в мережі кожного вузла. Обмежена адреса широкомовлення 255.255.255.255 залишається всередині інтерфейсу, який її випускає, а широкомовлення, спрямоване на підмережу, — окремий випадок, а не загальна ліцензія для маршрутизаторів заливати оголошення.
Це властивість проєкту, а не дефект, який латають опцією. OpenVPN і його client-to-client налаштування керує трафіком між вузлами всередині тунелю і не є релеєм виявлення, хоча в багатьох обговореннях його пропонують саме для цього. Релей — окремий компонент із власною конфігурацією та власними режимами відмови. Припущення, що наявна опція вже це покриває, — найчастіша причина, чому розслідування застрягає.
Виявлення через multicast має ту саму проблему з іншим класом адрес, і йому потрібна маршрутизація multicast або релей, а не виняток для широкомовлення.
Коли релей виправданий, тримайте його вузьким
Якщо автоматичне виявлення є вимогою, спершу визначте фактичний обмін: широкомовлення чи multicast, адреса призначення, порт UDP, інтерфейс, який його надсилає, і адреса всередині відповіді. Релей, що відповідає протоколу й обмежений цими п'ятьма фактами, значно вужчий за розширення цілого сегмента Ethernet.
Пересилання пакета без змін може все ще бути недостатнім. Якщо корисне навантаження каже отримувачу під'єднатися до адреси, до якої він не дістанеться, релей дає марну відповідь, тому власний інтерфейс гри або налаштування оголошеної адреси варто перевірити раніше, ніж з'явиться будь-який релей.
Обмежте релей тими інтерфейсами й вузлами, яким він потрібен, і визначте, як відповіді знаходять того, хто запитує. Повторення сторонніх широкомовних пакетів розкриває інші локальні служби та створює петлі, які потім боляче налагоджувати.
Міст лише тоді, коли проєкт потребує Ethernet
Кадри Ethernet ідуть усередині TAP, тож тунель TAP може належати до навмисно змощеного домену широкомовлення. Проста заміна dev tun на dev tap не будує цей міст, не робить конфігурацію сервера сумісною і не змушує застосунок вибрати новий інтерфейс. Посібник OpenVPN з мостів описує ширшу схему, а не ліки для одного порожнього лобі.
Мостування також вирівнює план адрес, тому рішення заслуговує причини більшої, ніж нетерплячка. Дві мережі, що були окремими, стають однією, і кожна служба з обох боків починає бачити широкомовні пакети іншого боку. Цей наслідок має бути в журналі змін, перш ніж хтось це ввімкне. Немає правила, що клієнти ігор мусять бути в діапазоні 192.168; виберіть план без перекриття і перевірте обмеження конкретної гри, замість того щоб перенумеровувати тунель, бо так зробив допис на форумі.
Наприкінці тримайте два результати окремо: чи можна приєднатися до хоста і чи оголошує відповідь виявлення адресу, яку інший гравець справді може використати. Виправлення другого без підтвердження першого — це шлях, яким люди зрештою утримують міст для проблеми, яка ніколи не була про широкомовлення.