Празен списък с LAN игри през OpenVPN? Проверете пътя на откриване

Да пингвате тунелния адрес на друг играч и да видите играта, която той е хоствал, са две различни постижения. Списъкът в лобито обикновено зависи от обмен на откриване, писан за една локална мрежа, докато игровата сесия е обикновена връзка към адрес и порт. Ако приемете празния списък за проблем с маршрутизацията, ще тръгнете към мост, който може да не ви трябва, затова разделете двата въпроса, преди да промените нещо.

Разделете присъединяването към сесия от намирането ѝ

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

Запишете резултата, преди да пипнете конфигурацията на VPN. Това е най-евтиният тест в цялото разследване и елиминира половината от пространството за решения. Запишете и адреса, който сте използвали, защото той става отправна точка за всеки следващ тест. Без този ред в бележките следващото сравнение е догадка.

Тествайте директно присъединяване, преди да пипнете тунела

Ако играта предлага опция за директна връзка, използвайте тунелния адрес на хоста и документирания порт на играта, а собствената автентикация на играта и правилата на защитната стена на хоста оставете непокътнати. Успешното присъединяване стеснява проблема до откриването. Неуспешното присъединяване все още изисква собствено разследване и никакъв релей няма да го поправи.

Не предполагайте, че портът за откриване и портът на сесията са едно и също число. Игрите обикновено обявяват на един UDP порт и приемат играчи на друг, а релей, изграден за грешния, дава списък, който пак остава празен.

Проверете и кой адаптер е избрал процесът на хоста. Процес, вързан към адреса на домашната LAN, ще обяви точно този адрес и отдалеченият играч не може да маршрутизира към него, дори обявата да пристигне. Списъкът може да се напълни, а присъединяването пак да се провали само заради това.

Разберете къде спира broadcast

Маршрутизираният TUN тунел пренася IP пакети между партньори и не възпроизвежда локален broadcast в мрежата на всеки партньор. Ограниченият broadcast адрес 255.255.255.255 остава вътре в интерфейса, който го излъчва, а broadcast, насочен към подмрежа, е отделен случай, а не общ лиценз рутерите да заливат с обяви.

Това е свойство на дизайна, а не дефект, който се кърпи с опция. OpenVPN и неговата настройка client-to-client управлява трафика между партньорите в тунела и не е релей за откриване, въпреки че в много теми се предлага точно за тази цел. Релеят е отделен компонент със своя конфигурация и свои режими на отказ. Предположението, че съществуваща опция вече го покрива, е най-честата причина разследването да зацикли.

Multicast откриването има същия проблем с различен клас адреси и изисква multicast маршрутизация или релей, а не изключение за broadcast.

Когато релеят е оправдан, дръжте го тесен

Ако автоматичното откриване е изискване, първо определете действителния обмен: broadcast или multicast, адрес на местоназначение, UDP порт, интерфейсът, който го изпраща, и адреса в отговора. Релей, съобразен с протокола и ограничен до тези пет факта, е много по-тесен от разширяване на цял Ethernet сегмент.

Препредаването на пакета без промяна може да е недостатъчно. Ако полезният товар казва на получателя да се свърже с адрес, до който не може да стигне, релеят дава безполезен отговор, затова собственият интерфейс на играта или настройката за обявен адрес трябва да се опитат, преди да има какъвто и да е релей.

Ограничете релея до интерфейсите и партньорите, които се нуждаят от него, и определете как отговорите намират питащия. Повтарянето на несвързани broadcast пакети излага други локални услуги и създава цикли, които после се дебъгват болезнено.

Мост само когато дизайнът изисква Ethernet

Ethernet кадрите пътуват в TAP, така че TAP тунел може да принадлежи на умишлено мостов broadcast домейн. Простото превключване от dev tun към dev tap не изгражда този мост, не прави сървърната конфигурация съвместима и не кара приложението да избере новия интерфейс. Ръководството на OpenVPN за мостове описва по-широката схема, а не лек за едно празно лоби.

Мостът също изравнява адресния план и затова решението заслужава причина отвъд нетърпението. Две мрежи, които са били отделни, стават една и всяка услуга от двете страни започва да вижда broadcast пакетите на другата. Това последствие принадлежи в записа за промяната, преди някой да я включи. Няма правило, че игралните клиенти трябва да са в диапазон 192.168; изберете план без припокриване и проверете ограниченията на конкретната игра, вместо да преномерирате тунела, защото някой форумен пост го е направил.

Накрая дръжте двата резултата отделно: дали към хоста може да се присъедините и дали отговорът за откриване обявява адрес, който другият играч наистина може да използва. Поправянето на второто без потвърждение на първото е начинът, по който хората в крайна сметка поддържат мост за проблем, който никога не е бил за broadcast.