Празна 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; изберете план без преклопување и проверете ги ограничувањата на конкретната игра наместо да го пренумерирате тунелот затоа што некоја објава на форум го направила тоа.

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