Üres LAN-játéklista OpenVPN-en? Ellenőrizze a felderítési útvonalat

Egy másik játékos alagútcímére pingelni és látni az általa hosztolt játékot két különböző teljesítmény. A lobby listája általában egyetlen helyi hálózatra írt felderítési cserétől függ, míg a játékmunkamenet egy címre és portra irányuló hétköznapi kapcsolat. Ha az üres listát útválasztási hibának tekinti, olyan híd felé indul, amelyre talán nincs is szüksége, ezért válassza szét a két kérdést, mielőtt bármit módosítana.

Válassza szét a munkamenethez csatlakozást a megtalálásától

A sikertelen csatlakozás útvonalakra, tűzfalszabályokra és figyelő szolgáltatásra utal. Az üres lista melletti sikeres csatlakozás a felderítésre vagy a hirdetményben szereplő címre utal. Ez a két eredmény teljesen más munkához vezet, és csak úgy tudja megkülönböztetni őket, ha az elsőt szándékosan kipróbálja.

Írja le az eredményt, mielőtt hozzányúl a VPN-konfigurációhoz. Ez a legolcsóbb teszt az egész vizsgálatban, és a tervezési tér felét kizárja. Jegyezze fel a használt címet is, mert ez lesz a viszonyítási pont minden későbbi teszthez. Ha ez a sor nincs a jegyzeteiben, a következő összehasonlítás találgatás.

Tesztelje a közvetlen csatlakozást, mielőtt hozzányúl az alagúthoz

Ha a játék kínál közvetlen kapcsolódási lehetőséget, használja a gazdagép alagútcímét és a dokumentált játékportot, és hagyja érintetlenül a játék saját hitelesítését és a gazdagép tűzfalszabályait. A sikeres csatlakozás a felderítésre szűkíti a problémát. A sikertelen csatlakozásnak továbbra is saját vizsgálat kell, és egyetlen relé sem javítja meg.

Ne feltételezze, hogy a felderítési port és a munkamenet-port ugyanaz a szám. A játékok általában az egyik UDP-porton hirdetnek, és egy másikon fogadják a játékosokat, a rossz portra épített relé pedig olyan listát ad, amely továbbra is üres marad.

Azt is ellenőrizze, melyik adaptert választotta a hosztoló folyamat. A háztartási LAN-címhez kötött folyamat azt a címet hirdeti, és a távoli játékos nem tud oda útvonalat vezetni, még ha a hirdetmény meg is érkezik. A lista megtelhet, és a csatlakozás pusztán ezért sikertelen lehet.

Értse meg, hol áll meg a broadcast

Az útválasztott TUN-alagút IP-csomagokat szállít a partnerek között, és nem reprodukálja a helyi broadcastot minden partner hálózatán. A korlátozott broadcast-cím 255.255.255.255 az őt kibocsátó interfészen belül marad, és az alhálózatra irányuló broadcast külön eset, nem általános engedély a routereknek a hirdetmények elárasztására.

Ez a tervezés tulajdonsága, nem opcióval foltozható hiba. OpenVPN és annak client-to-client beállítása az alagúton belüli partnerforgalmat szabályozza, és nem felderítési relé, bár sok fórumszálban épp erre a célra javasolják. A relé külön komponens, saját konfigurációval és saját hibaüzemmódokkal. Az a feltevés, hogy egy meglévő opció ezt már lefedi, a leggyakoribb oka annak, hogy ez a vizsgálat elakad.

A multicast-felderítésnél ugyanez a probléma más címosztállyal, és multicast-útválasztásra vagy relére van szüksége, nem broadcast-kivételre.

Ha a relé indokolt, tartsa szűken

Ha az automatikus felderítés követelmény, először azonosítsa a tényleges cserét: broadcast vagy multicast, célcím, UDP-port, az azt küldő interfész és a válaszban lévő cím. Az ezekre az öt tényre korlátozott, protokollhoz illő relé sokkal szűkebb, mint egy teljes Ethernet-szegmens kiterjesztése.

A csomag változatlan továbbítása még mindig elégtelen lehet. Ha a hasznos teher arra utasítja a fogadót, hogy olyan címhez csatlakozzon, amelyet nem ér el, a relé haszontalan választ ad, ezért a játék saját interfészét vagy a hirdetett cím beállítását kell kipróbálni, mielőtt bármilyen relé létezne.

Korlátozza a relét azokra az interfészekre és partnerekre, amelyeknek szükségük van rá, és határozza meg, hogyan találják meg a válaszok a kérőt. Az össze nem tartozó broadcastok ismétlése más helyi szolgáltatásokat tár fel, és olyan hurkokat hoz létre, amelyeket később fájdalmas hibakeresni.

Híd csak akkor, ha a tervezés Ethernetet igényel

Az Ethernet-keretek a TAP-on belül utaznak, ezért egy TAP-alagút tartozhat szándékosan áthidalt broadcast-tartományhoz. Az egyszerű átváltás dev tun és dev tap között nem építi fel azt a hidat, nem teszi kompatibilissé a szerverkonfigurációt, és nem veszi rá az alkalmazást az új interfész választására. Az OpenVPN áthidalási útmutatója a szélesebb elrendezést írja le, nem egyetlen üres lobby gyógymódját.

Az áthidalás ellaposítja a címtervet is, ezért a döntés a türelmetlenségen túli indokot érdemel. Két hálózat, amely külön volt, eggyé válik, és mindkét oldalon minden szolgáltatás elkezdi látni a másik oldal broadcastjait. Ennek a következménynek a változási naplóban van a helye, mielőtt bárki bekapcsolja. Nincs szabály arra, hogy a játékklienseknek 192.168-as tartományban kell lenniük; válasszon átfedésmentes tervet, és ellenőrizze az adott játék korlátait ahelyett, hogy újraszámozza az alagutat, mert egy fórumbejegyzés ezt tette.

A végén tartsa külön a két eredményt: csatlakozható-e a gazdagép, és hirdet-e a felderítési válasz olyan célt, amelyet a másik játékos ténylegesen használhat. A második javítása az első megerősítése nélkül az, ahogyan az emberek végül egy hidat tartanak fenn egy olyan problémára, amely soha nem a broadcastról szólt.