Minecraft przez VPN: który adres trafia do listy serwerów?

Wpisywanie punktu końcowego VPN na liście serwerów Minecrafta wydaje się logiczne i za każdym razem zawodzi, bo ten adres kończy tunel, a nie hostuje gry. Gracz połączony z tym samym VPN-em ma już ścieżkę do hosta gry, więc wpis musi wskazywać hosta i port, na którym nasłuchuje gra. Popraw te dwa elementy, a reszta problemu to zwykła osiągalność usługi, znacznie krótsza lista kontrolna, niż się początkowo wydaje.

Dwa adresy, dwa zadania

Jeden adres to infrastruktura publiczna: punkt końcowy transportu, który przenosi zaszyfrowane pakiety między peerami. Drugi to prywatny adres maszyny uruchamiającej dedykowany serwer. Nie są wymienne, a zastąpienie jednego drugim daje odrzucone połączenie albo przekroczenie limitu czasu, które wygląda jak problem z zaporą sieciową.

Z domyślnym portem gracz wpisuje 10.60.0.20:25565 i nic więcej. Strona pobierania serwera Java firmy Mojang podaje 25565 jako domyślny, a operatorowi serwera, który zmienił port, trzeba wierzyć, zamiast podważać to na podstawie starego poradnika.

Zrób z tego adresu prawdziwą usługę

Osiągalny adres jest konieczny i niewystarczający. Dedykowany serwer musi działać, być zgodny z wersją uruchamianą przez klienta gracza i nasłuchiwać na adresie, na który tunel może dostarczyć. Proces związany wyłącznie z loopbackiem nie staje się osiągalny dlatego, że ktoś dodał maszynie inny adres.

Potwierdź nasłuch, zanim dotkniesz zapory:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Pierwsza linia pokazuje, do czego proces faktycznie się przywiązał, a druga, czy peer może ukończyć uścisk dłoni TCP. Gdy powiązanie to 127.0.0.1, żadna ilość konfiguracji VPN nie zmienia wyniku, i ten jeden szczegół wyjaśnia zaskakującą liczbę zgłoszeń „VPN jest zepsuty”.

Polityka peerów, zapora i droga powrotna

Nad nasłuchem stoją dwa pytania o uprawnienia. Konfiguracja peerów VPN musi zezwalać na ruch między dwoma peerami, a zapora hosta gry musi przyjmować port gry od tego peera. Trzymaj oba zawężone do usługi gry i autoryzowanych peerów, zamiast wyłączać zaporę hosta, co wymienia regułę na dwie linijki na znacznie większy problem. Wąskie reguły to także jedyna wersja tego, która przechodzi przegląd bezpieczeństwa bez akapitu uzasadnienia.

Potem przypomnij sobie, co dowodzi udany ping. Dotarcie do bramy VPN albo otrzymanie odpowiedzi od hosta gry dowodzi tylko, że ICMP przeszedł ścieżkę. Połączenie gry wymaga, by konkretny port był otwarty w obu kierunkach, a droga powrotna liczy się tak samo jak droga wychodząca.

Gdy serwer stoi za bramą

W powyższym przykładzie serwer gry jest peerem, co utrzymuje plan adresów prostym. Jeśli serwer mieszka w sieci LAN za bramą VPN, gracz potrzebuje routowalnego prywatnego adresu serwera, brama musi mieć skonfigurowane przekazywanie dla tej sieci, a host w sieci LAN potrzebuje trasy powrotnej do klienta w tunelu. Pominięcie drogi powrotnej zabija uścisk dłoni w połowie, co jest najbardziej mylącą z trzech awarii.

Nie kopiuj przykładowego adresu peera na inną maszynę, żeby naśladować tę topologię. Adresy w przykładzie opisują role, a ponowne użycie jednego adresu w dwóch rolach tworzy nakładanie się, którego routing nie rozwiąże.

Wykrywanie, konta i czego nie zmieniać

Automatyczne wykrywanie sieci LAN to wygoda zbudowana na ogłoszeniach. Rutowany VPN nie musi przenosić tych transmisji rozgłoszeniowych, więc brak wpisu na liście LAN nic nie mówi o tym, czy jawny prywatny adres działa. Wpisz adres, a potem oceń. Jeśli się łączy, luka w wykrywaniu to niedogodność użytkowa, a nie usterka, i można to tak udokumentować, zamiast badać.

Zachowaj też nienaruszone zwykłe uwierzytelnianie konta i politykę wstępu gry. Działająca prywatna trasa daje ścieżkę, nie członkostwo, i żadne przestawianie priorytetów karty sieciowej nie zastąpi wskazania miejsca docelowego, którego klient powinien używać.