Prázdný seznam her v LAN přes OpenVPN? Prověřte cestu zjišťování

Pingnout adresu tunelu jiného hráče a vidět jeho hostovanou hru jsou dva různé úspěchy. Seznam v lobby obvykle závisí na výměně zjišťování napsané pro jednu místní síť, zatímco herní relace je obyčejné spojení na adresu a port. Pokud prázdný seznam považujete za chybu směrování, vydáte se k bridge, který možná vůbec nepotřebujete, takže obě otázky oddělte dřív, než cokoli změníte.

Oddělte připojení k relaci od jejího hledání

Neúspěšné připojení ukazuje na trasy, pravidla firewallu a naslouchající službu. Úspěšné připojení s prázdným seznamem ukazuje na zjišťování nebo na adresu, kterou nese oznámení. Tyto dva výsledky vedou ke zcela jiné práci a rozeznat je můžete jen tak, že první z nich vědomě vyzkoušíte.

Výsledek si zapište, než sáhnete na konfiguraci VPN. Je to nejlevnější test v celém vyšetřování a odstraňuje polovinu prostoru návrhu. Poznamenejte si i adresu, kterou jste použili, protože se stane referenčním bodem pro každý další test. Bez tohoto řádku v poznámkách je další srovnání jen dohad.

Vyzkoušejte přímé připojení, než sáhnete na tunel

Pokud hra nabízí přímé připojení, použijte adresu tunelu hostitele a dokumentovaný port hry a vlastní autentizaci hry i pravidla firewallu hostitele nechte nedotčená. Úspěšné připojení zúží problém na zjišťování. Neúspěšné připojení stejně potřebuje vlastní vyšetřování a žádný relay ho neopraví.

Nepředpokládejte, že port zjišťování a port relace jsou stejné číslo. Hry obvykle oznamují na jednom portu UDP a hráče přijímají na jiném, a relay postavený pro ten špatný dává seznam, který zůstává prázdný.

Zkontrolujte také, který adaptér zvolil proces hostování. Proces vázaný na adresu domácí LAN bude oznamovat tuto adresu a vzdálený hráč na ni nemůže směrovat, i když oznámení dorazí. Seznam se může naplnit a připojení může selhat jen kvůli tomu.

Pochopte, kde broadcast končí

Směrovaný tunel TUN přenáší IP pakety mezi peery a neopakuje místní broadcast v síti každého peeru. Omezená broadcast adresa 255.255.255.255 zůstává uvnitř rozhraní, které ji vysílá, a broadcast směřovaný do podsítě je samostatný případ, nikoli obecná licence, aby směrovače zaplavovaly sítě oznámeními.

To je vlastnost návrhu, ne vada, která se záplatuje volbou. OpenVPN a jeho volba client-to-client řídí provoz mezi peery uvnitř tunelu a není relay pro zjišťování, i když se v mnoha vláknech doporučuje právě k tomu. Relay je samostatná komponenta s vlastní konfigurací a vlastními režimy selhání. Předpoklad, že to stávající volba už pokrývá, je nejčastější důvod, proč se vyšetřování zasekne.

Multicastové zjišťování má stejný problém s jinou třídou adres a potřebuje multicastové směrování nebo relay, nikoli výjimku pro broadcast.

Když je relay opodstatněný, držte ho úzký

Pokud je automatické zjišťování požadavek, nejprve určete skutečnou výměnu: broadcast nebo multicast, cílovou adresu, port UDP, rozhraní, které ji posílá, a adresu uvnitř odpovědi. Relay odpovídající protokolu a omezený na těchto pět faktů je mnohem užší než rozšíření celého Ethernet segmentu.

Předávání paketu beze změny může stále nestačit. Pokud užitečné zatížení říká příjemci, aby se připojil k adrese, na kterou nedosáhne, relay doručí zbytečnou odpověď, a proto je třeba vyzkoušet vlastní rozhraní hry nebo nastavení inzerované adresy dřív, než nějaký relay vznikne.

Omezte relay na rozhraní a peery, které ho potřebují, a definujte, jak odpovědi najdou žadatele. Opakování nesouvisejících broadcastů vystavuje další místní služby a vytváří smyčky, které se pak ladí bolestně.

Bridge jen tehdy, když návrh potřebuje Ethernet

Rámce Ethernet cestují uvnitř TAP, takže tunel TAP může patřit do záměrně přemostěné broadcastové domény. Pouhé přepnutí z dev tun na dev tap ten bridge nepostaví, neučiní konfiguraci serveru kompatibilní a nepřiměje aplikaci zvolit nové rozhraní. Průvodce přemostěním OpenVPN popisuje širší uspořádání, nikoli lék na jedno prázdné lobby.

Přemostění také zplošťuje plán adres, a proto si rozhodnutí zaslouží důvod nad rámec netrpělivosti. Dvě sítě, které byly oddělené, se stanou jednou a každá služba na obou stranách začne vidět broadcasty druhé strany. Tento důsledek patří do záznamu o změně dřív, než to někdo zapne. Neexistuje pravidlo, že herní klienti musí sedět v rozsahu 192.168; zvolte plán bez překryvu a zkontrolujte omezení konkrétní hry, místo abyste tunel přečíslovali, protože to udělal nějaký příspěvek na fóru.

Na konci držte oba výsledky oddělené: zda se lze k hostiteli připojit a zda odpověď zjišťování inzeruje cíl, který druhý hráč skutečně může použít. Opravit druhé bez potvrzení prvního je způsob, jak lidé skončí údržbou bridge u problému, který nikdy nebyl o broadcastu.