Leë LAN-speellys oor OpenVPN? Toets die ontdekkingsroete

Om 'n ander speler se tonneladres te ping en om hul gehoste speletjie te sien, is twee verskillende prestasies. Die voorportaallys hang gewoonlik van 'n ontdekkingsuitruiling af wat vir 'n enkele plaaslike netwerk geskryf is, terwyl die speletjiesessie 'n gewone verbinding na 'n adres en poort is. Om 'n leë lys as 'n roeteringsfout te beskou, stuur jou na 'n brug wat jy dalk nie nodig het nie; skei dus die twee vrae voordat jy enigiets verander.

Skei die aansluit by 'n sessie van die vind daarvan

'n Mislukte aansluit wys na roetes, brandmuurreëls en 'n luisterdiens. 'n Suksesvolle aansluit met 'n leë lys wys na ontdekking, of na die adres wat die aankondiging dra. Daardie twee uitkomste lei tot heeltemal verskillende werk, en jy kan hulle net onderskei deur die eerste een doelbewus te probeer.

Skryf die resultaat neer voordat jy aan die VPN-konfigurasie raak. Dit is die goedkoopste toets in die hele ondersoek en dit skakel die helfte van die ontwerpruimte uit. Let ook op die adres wat jy gebruik het, want dit word die verwysingspunt vir elke latere toets. Sonder daardie reël in jou notas is die volgende vergelyking raaiwerk.

Toets 'n direkte aansluit voordat jy aan die tonnel raak

As die speletjie 'n direkte verbindingsopsie bied, gebruik die gasheer se tonneladres en die gedokumenteerde speletjiepoort, en laat die speletjie se eie verifikasie en die gasheer se brandmuurreëls ongeskonde. 'n Suksesvolle aansluit vernou die probleem tot ontdekking. 'n Mislukte aansluit het steeds sy eie ondersoek nodig, en geen aflos sal dit regmaak nie.

Moenie aanneem die ontdekkingspoort en die sessiepoort is dieselfde nommer nie. Speletjies kondig gewoonlik op een UDP-poort aan en aanvaar spelers op 'n ander, en 'n aflos wat vir die verkeerde een gebou is, lewer 'n lys wat steeds leeg bly.

Kontroleer ook watter adapter die gasheerproses gekies het. 'n Proses wat aan die huis-LAN-adres gebind is, sal daardie adres aankondig, en die afstandspeler kan nie daarheen roeteer nie, selfs wanneer die aankondiging aankom. Die lys kan vul en die aansluit kan steeds om daardie rede alleen misluk.

Verstaan waar uitsending stop

'n Geroteerde TUN-tonnel dra IP-pakkette tussen eweknieë en reproduseer nie plaaslike uitsending op elke eweknie se netwerk nie. Die beperkte uitsendingsadres 255.255.255.255 bly binne die koppelvlak wat dit uitstuur, en 'n subnetgerigte uitsending is 'n aparte geval eerder as 'n algemene lisensie vir roeteerders om aankondigings te oorstroom.

Dit is 'n eienskap van die ontwerp, nie 'n gebrek wat met 'n opsie gepleister moet word nie. OpenVPN se client-to-client instelling beheer eweknieverkeer binne die tonnel en is nie 'n ontdekkingsaflos nie, al word dit in baie drade vir hierdie doel voorgestel. 'n Aflos is 'n aparte komponent met sy eie konfigurasie en sy eie foutmodusse. Om aan te neem dat 'n bestaande opsie dit reeds dek, is die algemeenste manier waarop hierdie ondersoek vasdraai.

Multikaster-ontdekking het dieselfde probleem met 'n ander adresklas, en dit benodig multikaster-roetering of 'n aflos eerder as 'n uitsendingsuitsondering.

Wanneer 'n aflos geregverdig is, hou dit smal

As outomatiese ontdekking 'n vereiste is, identifiseer eers die werklike uitruiling: uitsending of multikaster, bestemmingsadres, UDP-poort, die koppelvlak wat dit stuur, en die adres binne die antwoord. 'n Protokolgepaste aflos wat op daardie vyf feite beperk is, is baie smaller as om 'n hele Ethernet-segment te verleng.

Om die pakket onveranderd aan te stuur kan steeds onvoldoende wees. As die loonvrag die ontvanger sê om aan 'n adres te koppel wat hy nie kan bereik nie, lewer die aflos 'n nuttelose antwoord; daarom moet die speletjie se eie koppelvlak of aangekondigde-adres-instelling probeer word voordat enige aflos bestaan.

Beperk die aflos tot die koppelvlakke en eweknieë wat dit nodig het, en definieer hoe antwoorde die versoeker vind. Om onverwante uitsendings te herhaal, stel ander plaaslike dienste bloot en skep lusse wat later moeilik is om te ontfout.

Brug slegs wanneer die ontwerp Ethernet nodig het

Ethernet-rame reis binne TAP, so 'n TAP-tonnel kan aan 'n doelbewus oorbrugde uitsendingsdomein behoort. Om bloot dev tun na dev tap te skakel, bou nie daardie brug nie, maak nie die bedienerkonfigurasie versoenbaar nie en laat nie die toepassing die nuwe koppelvlak kies nie. Die OpenVPN-brugids beskryf die breër reëling eerder as 'n kuur vir een leë voorportaal.

Oorbrugging plat ook die adresplan, en daarom verdien die besluit 'n rede verder as ongeduld. Twee netwerke wat apart was, word een, en elke diens aan weerskante begin die ander kant se uitsendings sien. Daardie gevolg hoort in die veranderingsrekord voordat iemand dit aanskakel. Daar is geen reël dat speletjiekliënte in 'n 192.168-reeks moet sit nie; kies 'n nie-oorvleuelende plan en kyk na die individuele speletjie se beperkings in plaas daarvan om die tonnel te hernommer omdat 'n forumplasing dit gedoen het.

Hou die twee resultate aan die einde apart: of daar by die gasheer aangesluit kan word, en of die ontdekkingsantwoord 'n bestemming adverteer wat die ander speler werklik kan gebruik. Om die tweede reg te maak sonder om die eerste te bevestig, is hoe mense uiteindelik 'n brug instandhou vir 'n probleem wat nooit oor uitsending gegaan het nie.