Minecraft через VPN: яку адресу писати в списку серверів?

Вводити кінцеву точку VPN у список серверів Minecraft здається логічним і щоразу не спрацьовує, бо ця адреса завершує тунель, а не розміщує гру. У гравця, підключеного до того самого VPN, уже є шлях до хоста гри, тому запис має називати хост і порт, на якому слухає гра. Виправте ці два пункти, і решта проблеми — звичайна доступність сервісу, значно коротший контрольний список, ніж здається спочатку.

Дві адреси, дві задачі

Одна адреса — публічна інфраструктура: транспортна кінцева точка, що переносить зашифровані пакети між вузлами. Інша — приватна адреса машини, на якій працює виділений сервер. Вони не взаємозамінні, і заміна однієї іншою дає відмову в з'єднанні або тайм-аут, що виглядає як проблема з міжмережевим екраном.

З портом за замовчуванням гравець вводить 10.60.0.20:25565 і більше нічого. Сторінка завантаження Java-сервера Mojang зазначає 25565 як типовий порт, і операторові, який змінив порт, треба вірити, а не сумніватися за старим посібником.

Зробіть цю адресу справжнім сервісом

Досяжний адрес необхідний і недостатній. Виділений сервер має працювати, бути сумісним із версією, яку запускає клієнт гравця, і слухати на адресі, куди тунель може доставити. Процес, прив'язаний лише до loopback, не стає досяжним через те, що хтось додав машині ще одну адресу.

Переконайтеся в слухачі, перш ніж чіпати міжмережевий екран:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Перший рядок показує, до чого процес насправді прив'язаний, а другий — чи може вузол завершити рукостискання TCP. Коли прив'язка — 127.0.0.1, жоден обсяг налаштувань VPN не змінює результат, і саме ця деталь пояснює напрочуд багато повідомлень «VPN зламано».

Політика вузлів, міжмережевий екран і зворотний шлях

Над слухачем стоять два питання про дозволи. Конфігурація вузлів VPN має дозволяти трафік між двома вузлами, а міжмережевий екран хоста гри має приймати ігровий порт від цього вузла. Тримайте обидва обмеженими ігровим сервісом і авторизованими вузлами, замість вимикати міжмережевий екран хоста, що міняє правило з двох рядків на значно більшу проблему. Вузькі правила — ще й єдиний варіант цього, який проходить перевірку безпеки без абзацу обґрунтування.

Потім згадайте, що доводить успішний ping. Досягнення шлюзу VPN або відповідь від хоста гри доводить лише те, що ICMP пройшов шлях. Ігровому з'єднанню потрібен конкретний порт, відкритий в обидва боки, і зворотний шлях такий самий важливий, як вихідний.

Коли сервер стоїть за шлюзом

У прикладі вище ігровий сервер є вузлом, що робить схему адрес простою. Якщо сервер розташований у локальній мережі за шлюзом VPN, гравцеві потрібна маршрутизована приватна адреса сервера, шлюзу треба налаштувати пересилання для цієї мережі, а хосту в локальній мережі потрібен зворотний маршрут до клієнта в тунелі. Втратите зворотний шлях — і рукостискання помре на півдорозі, що є найзаплутанішим із трьох збоїв.

Не копіюйте адресу вузла з прикладу на іншу машину, щоб повторити цю топологію. Адреси в прикладі описують ролі, а повторне використання однієї адреси в двох ролях створює перекриття, яке маршрутизація не зможе розв'язати.

Виявлення, облікові записи і що не змінювати

Автоматичне виявлення локальної мережі — зручність, побудована на оголошеннях. Маршрутизованому VPN не обов'язково передавати ці широкомовні пакети, тож відсутність запису в списку локальної мережі нічого не каже про те, чи працює явна приватна адреса. Введіть адресу й лише потім судіть. Якщо з'єднання встановлюється, прогалина у виявленні — це незручність, а не несправність, і її можна так задокументувати, замість досліджувати.

Зберігайте незмінними і звичайну автентифікацію облікового запису, і політику допуску гри. Робочий приватний маршрут дає шлях, а не членство, і жодне переставляння пріоритетів адаптера не замінює визначення пункту призначення, який клієнт має використовувати.