Tyhjä LAN-pelilista OpenVPN:n yli? Tarkista löytämispolku

Toisen pelaajan tunneliosoitteen pingaaminen ja hänen hostaamansa pelin näkeminen ovat kaksi eri saavutusta. Lobbyn lista riippuu yleensä yhdelle paikallisverkolle kirjoitetusta löytämisvaihdosta, kun taas peli-istunto on tavallinen yhteys osoitteeseen ja porttiin. Tyhjän listan pitäminen reititysvirheenä ohjaa sinut sillalle, jota et ehkä tarvitse, joten erota kaksi kysymystä ennen kuin muutat mitään.

Erota istuntoon liittyminen sen löytämisestä

Epäonnistunut liittyminen viittaa reitteihin, palomuurisääntöihin ja kuuntelevaan palveluun. Onnistunut liittyminen tyhjällä listalla viittaa löytämiseen tai osoitteeseen, jonka ilmoitus kantaa. Nämä kaksi tulosta johtavat täysin eri työhön, ja voit erottaa ne vain kokeilemalla ensimmäistä tarkoituksella.

Kirjoita tulos muistiin ennen kuin kosket VPN-kokoonpanoon. Se on koko tutkinnan halvin testi ja poistaa puolet suunnittelutilasta. Merkitse myös käyttämäsi osoite, sillä siitä tulee vertailukohta jokaiselle myöhemmälle testille. Ilman sitä riviä muistiinpanoissasi seuraava vertailu on arvailua.

Testaa suoraa liittymistä ennen kuin kosket tunneliin

Jos peli tarjoaa suoran yhteyden vaihtoehdon, käytä isännän tunneliosoitetta ja dokumentoitua peliporttia, ja jätä pelin oma todennus ja isännän palomuurisäännöt ennalleen. Onnistunut liittyminen rajaa ongelman löytämiseen. Epäonnistunut liittyminen tarvitsee yhä oman tutkintansa, eikä mikään rele korjaa sitä.

Älä oleta, että löytämisportti ja istuntoportti ovat sama numero. Pelit ilmoittavat yleensä yhdellä UDP-portilla ja hyväksyvät pelaajia toisella, ja väärälle portille rakennettu rele tuottaa listan, joka jää silti tyhjäksi.

Tarkista myös, minkä sovittimen hostausprosessi valitsi. Kodin LAN-osoitteeseen sidottu prosessi ilmoittaa sen osoitteen, eikä etäpelaaja voi reitittää siihen, vaikka ilmoitus saapuisi. Lista voi täyttyä ja liittyminen voi silti epäonnistua pelkästään siitä syystä.

Ymmärrä, mihin lähetys pysähtyy

Reititetty TUN-tunneli kuljettaa IP-paketteja vertaisten välillä eikä toista paikallista lähetystä kunkin vertaisen verkossa. Rajoitettu lähetysosoite 255.255.255.255 pysyy sen lähettävän liitännän sisällä, ja aliverkkoon suunnattu lähetys on erillinen tapaus eikä yleinen lupa reitittimille tulvia ilmoituksia.

Se on suunnittelun ominaisuus, ei puute, jota paikataan valinnalla. OpenVPN ja sen client-to-client asetus ohjaa vertaisten liikennettä tunnelin sisällä eikä ole löytämisrele, vaikka sitä ehdotetaan juuri tähän tarkoitukseen monissa ketjuissa. Rele on erillinen komponentti, jolla on oma kokoonpanonsa ja omat vikatilansa. Oletus, että olemassa oleva valinta kattaa sen jo, on yleisin syy siihen, että tämä tutkinta juuttuu.

Multicast-löytämisellä on sama ongelma eri osoiteluokalla, ja se tarvitsee multicast-reitityksen tai relen eikä lähetyspoikkeusta.

Kun rele on perusteltu, pidä se kapeana

Jos automaattinen löytäminen on vaatimus, tunnista ensin todellinen vaihto: lähetys vai multicast, kohdeosoite, UDP-portti, sen lähettävä liitäntä ja vastauksen sisällä oleva osoite. Protokollaan sopiva rele, joka on rajattu näihin viiteen tosiasiaan, on paljon kapeampi kuin koko Ethernet-segmentin laajentaminen.

Paketin välittäminen muuttumattomana voi silti olla riittämätöntä. Jos hyötykuorma käskee vastaanottajaa yhdistämään osoitteeseen, johon se ei pääse, rele toimittaa hyödyttömän vastauksen, minkä vuoksi pelin omaa liitäntää tai ilmoitetun osoitteen asetusta pitäisi kokeilla ennen kuin mitään relettä on olemassa.

Rajaa rele niihin liitäntöihin ja vertaisiin, jotka sitä tarvitsevat, ja määritä, miten vastaukset löytävät pyytäjän. Toisiinsa liittymättömien lähetysten toistaminen paljastaa muita paikallisia palveluita ja luo silmukoita, joita on myöhemmin työlästä selvittää.

Sillaa vain silloin, kun suunnittelu vaatii Ethernetiä

Ethernet-kehykset kulkevat TAP:n sisällä, joten TAP-tunneli voi kuulua tarkoituksella sillattuun lähetysalueeseen. Pelkkä vaihtaminen dev tun tilalle dev tap ei rakenna sitä siltaa, ei tee palvelinkokoonpanosta yhteensopivaa eikä saa sovellusta valitsemaan uutta liitäntää. OpenVPN:n sillausopas kuvaa laajemman järjestelyn, ei parannuskeinoa yhdelle tyhjälle lobbylle.

Sillaus myös litistää osoitesuunnitelman, minkä vuoksi päätös ansaitsee muunkin syyn kuin kärsimättömyyden. Kaksi erillistä verkkoa yhdistyy yhdeksi, ja kummankin puolen jokainen palvelu alkaa nähdä toisen puolen lähetyksiä. Se seuraus kuuluu muutoskirjaan ennen kuin kukaan ottaa sen käyttöön. Ei ole sääntöä, että peliasiakkaiden täytyy olla 192.168-alueella; valitse päällekkäisyydetön suunnitelma ja tarkista kyseisen pelin rajoitukset sen sijaan, että numeroisit tunnelin uudelleen siksi, että foorumiviesti teki niin.

Pidä lopussa kaksi tulosta erillään: voiko isäntään liittyä ja ilmoittaako löytämisvastaus kohteen, jota toinen pelaaja voi todella käyttää. Toisen korjaaminen vahvistamatta ensimmäistä on se, miten ihmiset päätyvät ylläpitämään siltaa ongelmalle, joka ei koskaan liittynyt lähetykseen.