Pusta lista gier LAN przez OpenVPN? Sprawdź ścieżkę wykrywania

Pingowanie adresu tunelu innego gracza i widzenie jego hostowanej gry to dwa różne osiągnięcia. Lista w lobby zwykle zależy od wymiany wykrywania napisanej dla jednej sieci lokalnej, podczas gdy sesja gry to zwykłe połączenie z adresem i portem. Potraktowanie pustej listy jako błędu routingu kieruje cię ku mostowi, którego możesz nie potrzebować, więc rozdziel oba pytania, zanim cokolwiek zmienisz.

Oddziel dołączanie do sesji od jej znajdowania

Nieudane dołączenie wskazuje na trasy, reguły zapory i usługę nasłuchującą. Udane dołączenie z pustą listą wskazuje na wykrywanie albo na adres, który niesie ogłoszenie. Te dwa wyniki prowadzą do zupełnie różnej pracy, a rozróżnić je można tylko, świadomie próbując pierwszego.

Zapisz wynik, zanim dotkniesz konfiguracji VPN. To najtańszy test w całym dochodzeniu i eliminuje połowę przestrzeni projektowej. Zanotuj też użyty adres, bo stanie się punktem odniesienia dla każdego późniejszego testu. Bez tej linii w notatkach następne porównanie jest tylko domysłem.

Przetestuj połączenie bezpośrednie, zanim dotkniesz tunelu

Jeśli gra oferuje opcję bezpośredniego połączenia, użyj adresu tunelu hosta i udokumentowanego portu gry, a własne uwierzytelnianie gry i reguły zapory hosta pozostaw nietknięte. Udane dołączenie zawęża problem do wykrywania. Nieudane dołączenie nadal wymaga własnego dochodzenia i żaden przekaźnik go nie naprawi.

Nie zakładaj, że port wykrywania i port sesji to ta sama liczba. Gry zwykle ogłaszają się na jednym porcie UDP i przyjmują graczy na innym, a przekaźnik zbudowany dla niewłaściwego daje listę, która wciąż pozostaje pusta.

Sprawdź też, który adapter wybrał proces hostowania. Proces przypisany do adresu domowej sieci LAN ogłosi ten adres, a zdalny gracz nie może do niego routować, nawet gdy ogłoszenie dotrze. Lista może się zapełnić, a dołączenie nadal może się nie udać tylko z tego powodu.

Zrozum, gdzie kończy się rozgłaszanie

Routowany tunel TUN przenosi pakiety IP między równorzędnymi węzłami i nie odtwarza lokalnego rozgłaszania w sieci każdego z nich. Ograniczony adres rozgłaszania 255.255.255.255 pozostaje wewnątrz interfejsu, który go wysyła, a rozgłaszanie skierowane do podsieci to osobny przypadek, a nie ogólna licencja na zalewanie sieci ogłoszeniami przez routery.

To właściwość projektu, a nie defekt do załatania opcją. OpenVPN i jego client-to-client ustawienie steruje ruchem między węzłami wewnątrz tunelu i nie jest przekaźnikiem wykrywania, choć w wielu wątkach jest proponowane właśnie w tym celu. Przekaźnik to osobny komponent z własną konfiguracją i własnymi trybami awarii. Założenie, że istniejąca opcja już to obejmuje, jest najczęstszą przyczyną zablokowania tego dochodzenia.

Wykrywanie multicast ma ten sam problem z inną klasą adresów i wymaga routingu multicast lub przekaźnika, a nie wyjątku od rozgłaszania.

Gdy przekaźnik jest uzasadniony, trzymaj go wąsko

Jeśli automatyczne wykrywanie jest wymogiem, najpierw zidentyfikuj faktyczną wymianę: rozgłaszanie czy multicast, adres docelowy, port UDP, interfejs, który to wysyła, oraz adres wewnątrz odpowiedzi. Przekaźnik zgodny z protokołem i ograniczony do tych pięciu faktów jest znacznie węższy niż rozszerzanie całego segmentu Ethernet.

Przekazywanie pakietu bez zmian może wciąż być niewystarczające. Jeśli ładunek każe odbiorcy połączyć się z adresem, do którego nie dotrze, przekaźnik dostarcza bezużyteczną odpowiedź, dlatego przed powstaniem jakiegokolwiek przekaźnika należy wypróbować własny interfejs gry lub ustawienie ogłaszanego adresu.

Ogranicz przekaźnik do interfejsów i węzłów, które go potrzebują, i określ, jak odpowiedzi znajdują pytającego. Powtarzanie niepowiązanych rozgłoszeń ujawnia inne lokalne usługi i tworzy pętle, które później trudno debugować.

Most tylko wtedy, gdy projekt wymaga Ethernetu

Ramki Ethernet podróżują wewnątrz TAP, więc tunel TAP może należeć do celowo pomostowanej domeny rozgłaszania. Samo dev tun na dev tap nie buduje tego mostu, nie czyni konfiguracji serwera zgodną i nie skłania aplikacji do wybrania nowego interfejsu. Przewodnik OpenVPN po mostach opisuje szerszy układ, a nie lekarstwo na jedno puste lobby.

Mostkowanie spłaszcza też plan adresów, dlatego decyzja zasługuje na powód wykraczający poza niecierpliwość. Dwie sieci, które były rozdzielone, stają się jedną, a każda usługa po obu stronach zaczyna widzieć rozgłoszenia drugiej strony. Ta konsekwencja należy do rejestru zmian, zanim ktokolwiek ją włączy. Nie ma reguły, że klienci gier muszą siedzieć w zakresie 192.168; wybierz plan bez nakładania się i sprawdź ograniczenia konkretnej gry, zamiast przenumerowywać tunel, bo jakiś post na forum tak zrobił.

Na koniec trzymaj oba wyniki osobno: czy można dołączyć do hosta i czy odpowiedź wykrywania ogłasza cel, którego drugi gracz naprawdę może użyć. Naprawianie drugiego bez potwierdzenia pierwszego to sposób, w jaki ludzie kończą z utrzymywaniem mostu dla problemu, który nigdy nie dotyczył rozgłaszania.