OpenVPN арқылы LAN ойын тізімі бос па? Анықтау жолын тексеріңіз

Басқа ойыншының туннель мекенжайына ping жіберу және оның хосттаған ойынын көру — екі түрлі жетістік. Лоббидегі тізім әдетте бір ғана жергілікті желіге арналып жазылған анықтау алмасуына тәуелді, ал ойын сессиясы мекенжай мен портқа қарапайым қосылым. Бос тізімді маршруттау ақауы деп қабылдау сізді қажет болмауы мүмкін көпірге бағыттайды, сондықтан бірдеңені өзгертудің алдында екі сұрақты ажыратыңыз.

Сессияға қосылуды оны табудан ажыратыңыз

Сәтсіз қосылу маршруттарға, firewall ережелеріне және тыңдап тұрған қызметке меңзейді. Бос тізіммен сәтті қосылу анықтауға немесе хабарлама алып жүрген мекенжайға меңзейді. Бұл екі нәтиже мүлдем басқа жұмысқа әкеледі және оларды тек біріншісін әдейі байқап көру арқылы ажырата аласыз.

VPN конфигурациясына тиюдің алдында нәтижені жазып қойыңыз. Бұл бүкіл тергеудің ең арзан сынағы және жобалау кеңістігінің жартысын жояды. Пайдаланған мекенжайды да жазыңыз, өйткені ол әрбір кейінгі сынақ үшін тірек нүктесіне айналады. Жазбаларыңызда сол жол болмаса, келесі салыстыру — болжам ғана.

Туннельге тиюдің алдында тікелей қосылуды байқап көріңіз

Егер ойын тікелей қосылу нұсқасын ұсынса, хосттың туннель мекенжайын және ойынның құжатталған портын пайдаланыңыз, ал ойынның өз аутентификациясы мен хосттың firewall ережелерін сол қалпында қалдырыңыз. Сәтті қосылу мәселені анықтауға дейін тарылтады. Сәтсіз қосылу әлі де өз тергеуін қажет етеді және оны ешбір реле түзетпейді.

Анықтау порты мен сессия порты бірдей сан деп ойламаңыз. Ойындар әдетте бір UDP портында жариялап, ойыншыларды екіншісінде қабылдайды, ал дұрыс емес порт үшін құрастырылған реле бос қалатын тізім береді.

Хостинг процесі қай адаптерді таңдағанын да тексеріңіз. Үй LAN мекенжайына байланған процесс сол мекенжайды жариялайды, ал қашықтағы ойыншы хабарлама жетсе де оған маршрут құра алмайды. Тізім толады, бірақ қосылу дәл осы себеппен сәтсіз болуы мүмкін.

Broadcast қайда тоқтайтынын түсініңіз

Маршрутталған TUN туннелі IP пакеттерін теңдестер арасында тасымалдайды және әр теңдестің желісінде жергілікті broadcast-ты қайталамайды. Шектеулі broadcast мекенжайы 255.255.255.255 оны шығаратын интерфейстің ішінде қалады, ал ішкі желіге бағытталған broadcast бөлек жағдай, маршрутизаторларға хабарламаларды жауып тастауға берілетін жалпы лицензия емес.

Бұл — жобалаудың қасиеті, опциямен жамалатын ақау емес. OpenVPN және оның client-to-client параметрі туннель ішіндегі теңдестер трафигін басқарады және анықтау релесі емес, көптеген ағындарда дәл осы мақсатқа ұсынылғанымен. Реле — өз конфигурациясы мен өз істен шығу режимдері бар жеке компонент. Қолданыстағы опция мұны әлдеқашан қамтиды деп болжау — бұл тергеудің тұрып қалуының ең көп тараған себебі.

Multicast арқылы анықтаудың басқа мекенжай класымен дәл осындай мәселесі бар және оған broadcast ерекшелігі емес, multicast маршруттау немесе реле қажет.

Реле ақталған жағдайда оны тар ұстаңыз

Егер автоматты анықтау талап болса, алдымен нақты алмасуды айқындаңыз: broadcast немесе multicast, межелі мекенжай, UDP порты, оны жіберетін интерфейс және жауаптың ішіндегі мекенжай. Осы бес фактімен шектелген протоколға сай реле бүкіл Ethernet сегментін кеңейтуден әлдеқайда тар.

Пакетті өзгеріссіз жіберу жеткіліксіз болуы мүмкін. Егер пайдалы жүктеме алушыға жете алмайтын мекенжайға қосылуды айтса, реле пайдасыз жауап береді, сондықтан кез келген реле пайда болмай тұрып ойынның өз интерфейсін немесе жарияланған мекенжай параметрін байқап көру керек.

Релені оған мұқтаж интерфейстермен және теңдестермен шектеңіз және жауаптардың сұраушыны қалай табатынын анықтаңыз. Қатысы жоқ broadcast-тарды қайталау басқа жергілікті қызметтерді әшкерелейді және кейін жөндеу қиын циклдер жасайды.

Көпірді тек жобаға Ethernet қажет болғанда жасаңыз

Ethernet кадрлары TAP ішінде жүреді, сондықтан TAP туннелі әдейі көпірленген broadcast доменіне жатуы мүмкін. Тек dev tun мәнін dev tap мәніне ауыстыру сол көпірді салмайды, сервер конфигурациясын үйлесімді етпейді және қолданбаны жаңа интерфейсті таңдауға мәжбүрлемейді. OpenVPN көпірлеу нұсқаулығы бір бос лоббиге ем емес, кеңірек құрылымды сипаттайды.

Көпірлеу мекенжай жоспарын да тегістейді, сондықтан шешім шыдамсыздықтан тыс себепке лайық. Бөлек болған екі желі бір болады және екі жақтағы әр қызмет қарсы жақтың broadcast-тарын көре бастайды. Бұл салдар өзгеріс журналында болуы керек, оны біреу қоспас бұрын. Ойын клиенттері 192.168 ауқымында болуы тиіс деген ереже жоқ; қабаттаспайтын жоспар таңдап, форумдағы жазба солай істеді деп туннельді қайта нөмірлеудің орнына нақты ойынның шектеулерін тексеріңіз.

Соңында екі нәтижені бөлек ұстаңыз: хостқа қосылуға бола ма және анықтау жауабы басқа ойыншы шынымен пайдалана алатын межелі мекенжайды жариялай ма. Біріншісін растамай екіншісін түзету — адамдардың ешқашан broadcast-қа қатысы болмаған мәселе үшін көпірді ұстап қалу жолы.