Празна листа LAN игара преко OpenVPN-а? Проверите путању откривања

Пинговати тунелску адресу другог играча и видети његову хостовану игру два су различита постигнућа. Листа у лобију обично зависи од размене откривања написане за једну локалну мрежу, док је сесија игре обична веза на адресу и порт. Ако празну листу схватите као грешку рутирања, идете према мосту који вам можда није потребан, зато раздвојите два питања пре него што ишта промените.

Раздвојите придруживање сесији од њеног проналажења

Неуспешно придруживање указује на руте, правила заштитног зида и услугу која слуша. Успешно придруживање с празном листом указује на откривање или на адресу коју носи објава. Та два исхода воде сасвим различитом послу, а разликовати их можете само ако први свесно испробате.

Запишите резултат пре него што дирнете VPN конфигурацију. То је најјефтинији тест у целој истрази и уклања пола простора дизајна. Забележите и адресу коју сте користили, јер она постаје референтна тачка за сваки каснији тест. Без тог реда у белешкама следеће поређење је нагађање.

Испробајте директно придруживање пре него што дирнете тунел

Ако игра нуди опцију директног повезивања, употребите тунелску адресу хоста и документовани порт игре, а сопствену аутентификацију игре и правила заштитног зида хоста оставите нетакнутима. Успешно придруживање сужава проблем на откривање. Неуспешно придруживање и даље тражи сопствену истрагу и ниједан релеј га неће поправити.

Не претпостављајте да су порт за откривање и порт сесије исти број. Игре обично објављују на једном UDP порту и примају играче на другом, а релеј направљен за погрешан даје листу која и даље остаје празна.

Проверите и који је адаптер изабрао процес хостовања. Процес везан за адресу кућне LAN мреже објавиће ту адресу, а удаљени играч не може да рутира до ње чак и кад објава стигне. Листа се може напунити, а придруживање ипак не успети само због тога.

Схватите где се емитовање зауставља

Рутирани TUN тунел преноси IP пакете између вршњака и не репродукује локално емитовање на мрежи сваког вршњака. Ограничена адреса емитовања 255.255.255.255 остаје унутар интерфејса који је емитује, а емитовање усмерено на подмрежу је посебан случај, а не општа дозвола рутерима да поплаве објаве.

То је својство дизајна, а не дефект који се крпи опцијом. OpenVPN и његова client-to-client поставка управља саобраћајем између вршњака унутар тунела и није релеј за откривање, иако се у многим темама предлаже управо за ту сврху. Релеј је засебна компонента са сопственом конфигурацијом и сопственим режимима отказа. Претпоставка да постојећа опција то већ покрива најчешћи је разлог зашто ова истрага заглави.

Multicast откривање има исти проблем са другом класом адреса и тражи multicast рутирање или релеј, а не изузетак за емитовање.

Кад је релеј оправдан, држите га уским

Ако је аутоматско откривање услов, прво идентификујте стварну размену: емитовање или multicast, одредишну адресу, UDP порт, интерфејс који је шаље и адресу унутар одговора. Релеј примерен протоколу и ограничен на тих пет чињеница много је ужи од проширења целог Ethernet сегмента.

Прослеђивање пакета непромењеног може и даље бити недовољно. Ако корисни терет каже примаоцу да се повеже на адресу до које не може да стигне, релеј даје бескористан одговор, зато сопствени интерфејс игре или поставку објављене адресе треба испробати пре него што икакав релеј постоји.

Ограничите релеј на интерфејсе и вршњаке којима је потребан и дефинишите како одговори проналазе подносиоца захтева. Понављање неповезаних емитовања излаже друге локалне услуге и ствара петље које је касније болно отклањати.

Мост само кад дизајн тражи Ethernet

Ethernet оквири путују унутар TAP-а, па TAP тунел може припадати намерно премошћеном домену емитовања. Пуко пребацивање са dev tun на dev tap не гради тај мост, не чини конфигурацију сервера компатибилном и не наводи апликацију да изабере нови интерфејс. OpenVPN водич за премошћавање описује шире уређење, а не лек за једно празно лоби.

Премошћавање такође изравнава план адреса, зато одлука заслужује разлог више од нестрпљења. Две мреже које су биле одвојене постају једна и свака услуга са обе стране почиње да види емитовања друге стране. Та последица припада у запис о промени пре него што је неко укључи. Нема правила да клијенти игара морају бити у опсегу 192.168; изаберите план без преклапања и проверите ограничења конкретне игре уместо да пренумеришете тунел зато што је тако учинио пост на форуму.

На крају држите два резултата одвојено: може ли се хосту придружити и објављује ли одговор откривања одредиште које други играч заиста може да користи. Поправљање другог без потврде првог начин је на који људи заврше одржавајући мост за проблем који никада није био о емитовању.