Prázdny zoznam hier v LAN cez OpenVPN? Preverte cestu zisťovania

Pingnúť adresu tunela iného hráča a vidieť jeho hostovanú hru sú dva rôzne úspechy. Zoznam v lobby zvyčajne závisí od výmeny zisťovania napísanej pre jednu miestnu sieť, kým herná relácia je obyčajné spojenie na adresu a port. Ak prázdny zoznam považujete za chybu smerovania, vydáte sa k bridge, ktorý možno vôbec nepotrebujete, preto obe otázky oddeľte skôr, než čokoľvek zmeníte.

Oddeľte pripojenie k relácii od jej hľadania

Neúspešné pripojenie ukazuje na trasy, pravidlá firewallu a načúvajúcu službu. Úspešné pripojenie s prázdnym zoznamom ukazuje na zisťovanie alebo na adresu, ktorú nesie oznámenie. Tieto dva výsledky vedú k úplne inej práci a rozlíšiť ich môžete len tak, že prvý vedome vyskúšate.

Výsledok si zapíšte skôr, než sa dotknete konfigurácie VPN. Je to najlacnejší test v celom vyšetrovaní a odstraňuje polovicu návrhového priestoru. Poznamenajte si aj použitú adresu, pretože sa stane referenčným bodom pre každý ďalší test. Bez tohto riadka v poznámkach je ďalšie porovnanie len dohad.

Vyskúšajte priame pripojenie skôr, než sa dotknete tunela

Ak hra ponúka priame pripojenie, použite adresu tunela hostiteľa a dokumentovaný port hry a vlastnú autentizáciu hry aj pravidlá firewallu hostiteľa nechajte nedotknuté. Úspešné pripojenie zúži problém na zisťovanie. Neúspešné pripojenie si stále vyžaduje vlastné vyšetrovanie a žiadny relay ho neopraví.

Nepredpokladajte, že port zisťovania a port relácie sú rovnaké číslo. Hry zvyčajne oznamujú na jednom porte UDP a hráčov prijímajú na inom, a relay postavený pre ten nesprávny dáva zoznam, ktorý zostáva prázdny.

Skontrolujte aj, ktorý adaptér zvolil proces hostovania. Proces viazaný na adresu domácej LAN bude oznamovať túto adresu a vzdialený hráč na ňu nemôže smerovať, aj keď oznámenie dorazí. Zoznam sa môže naplniť a pripojenie môže zlyhať len preto.

Pochopte, kde broadcast končí

Smerovaný tunel TUN prenáša IP pakety medzi peerami a neopakuje miestny broadcast v sieti každého peera. Obmedzená broadcast adresa 255.255.255.255 zostáva vnútri rozhrania, ktoré ju vysiela, a broadcast smerovaný do podsiete je samostatný prípad, nie všeobecná licencia, aby smerovače zaplavovali siete oznámeniami.

To je vlastnosť návrhu, nie chyba, ktorá sa záplatuje voľbou. OpenVPN a jeho voľba client-to-client riadi prevádzku medzi peerami vnútri tunela a nie je relay na zisťovanie, hoci sa v mnohých vláknach odporúča práve na to. Relay je samostatná komponenta s vlastnou konfiguráciou a vlastnými režimami zlyhania. Predpoklad, že to existujúca voľba už pokrýva, je najčastejší dôvod, prečo sa toto vyšetrovanie zasekne.

Multicastové zisťovanie má rovnaký problém s inou triedou adries a potrebuje multicastové smerovanie alebo relay, nie výnimku pre broadcast.

Keď je relay opodstatnený, držte ho úzky

Ak je automatické zisťovanie požiadavkou, najprv určte skutočnú výmenu: broadcast alebo multicast, cieľovú adresu, port UDP, rozhranie, ktoré ju posiela, a adresu vnútri odpovede. Relay zodpovedajúci protokolu a obmedzený na týchto päť faktov je oveľa užší než rozšírenie celého Ethernet segmentu.

Preposielanie paketu bez zmeny nemusí stačiť. Ak užitočné zaťaženie hovorí príjemcovi, aby sa pripojil k adrese, na ktorú nedosiahne, relay doručí zbytočnú odpoveď, preto treba pred vznikom akéhokoľvek relay vyskúšať vlastné rozhranie hry alebo nastavenie inzerovanej adresy.

Obmedzte relay na rozhrania a peery, ktoré ho potrebujú, a definujte, ako odpovede nájdu žiadateľa. Opakovanie nesúvisiacich broadcastov odhaľuje iné miestne služby a vytvára slučky, ktoré sa potom ladia bolestne.

Bridge len vtedy, keď návrh potrebuje Ethernet

Rámce Ethernet cestujú vnútri TAP, takže tunel TAP môže patriť do zámerne premosťovanej broadcastovej domény. Samotné dev tun na dev tap ten bridge nepostaví, neurobí konfiguráciu servera kompatibilnou a neprinúti aplikáciu zvoliť nové rozhranie. Príručka OpenVPN k premosťovaniu opisuje širšie usporiadanie, nie liek na jedno prázdne lobby.

Premosťovanie tiež splošťuje plán adries, a preto si rozhodnutie zaslúži dôvod nad rámec netrpezlivosti. Dve siete, ktoré boli oddelené, sa stanú jednou a každá služba na oboch stranách začne vidieť broadcasty druhej strany. Tento dôsledok patrí do záznamu o zmene skôr, než to niekto zapne. Neexistuje pravidlo, že herní klienti musia sedieť v rozsahu 192.168; zvoľte plán bez prekrytia a skontrolujte obmedzenia konkrétnej hry, namiesto prečíslovania tunela preto, že tak urobil príspevok na fóre.

Na konci držte oba výsledky oddelene: či sa dá k hostiteľovi pripojiť a či odpoveď zisťovania inzeruje cieľ, ktorý druhý hráč skutočne môže použiť. Opraviť druhé bez potvrdenia prvého je spôsob, akým ľudia skončia údržbou bridge pri probléme, ktorý sa nikdy netýkal broadcastu.