Llista de jocs LAN buida amb OpenVPN? Reviseu el camí de descoberta

Fer ping a l'adreça de túnel d'un altre jugador i veure el seu joc allotjat són dues fites diferents. La llista del lobi normalment depèn d'un intercanvi de descobriment escrit per a una sola xarxa local, mentre que la sessió de joc és una connexió ordinària a una adreça i un port. Tractar una llista buida com una fallada d'encaminament us porta cap a un pont que potser no necessiteu, així que separeu les dues preguntes abans de canviar res.

Separeu unir-vos a una sessió de trobar-la

Una unió fallida apunta a rutes, regles de tallafoc i un servei que escolta. Una unió correcta amb una llista buida apunta al descobriment o a l'adreça que porta l'anunci. Aquests dos resultats porten a feines completament diferents, i només els podeu distingir provant el primer deliberadament.

Anoteu el resultat abans de tocar la configuració de la VPN. És la prova més barata de tota la investigació i elimina la meitat de l'espai de disseny. Anoteu també l'adreça que heu fet servir, perquè es converteix en el punt de referència de cada prova posterior. Sense aquesta línia a les notes, la comparació següent és una conjectura.

Proveu una unió directa abans de tocar el túnel

Si el joc ofereix una opció de connexió directa, feu servir l'adreça de túnel de l'amfitrió i el port documentat del joc, i deixeu intactes l'autenticació pròpia del joc i les regles de tallafoc de l'amfitrió. Una unió correcta redueix el problema al descobriment. Una unió fallida encara necessita la seva pròpia investigació, i cap relé no la resoldrà.

No assumiu que el port de descobriment i el port de sessió són el mateix número. Els jocs solen anunciar-se en un port UDP i acceptar jugadors en un altre, i un relé construït per al port equivocat produeix una llista que continua buida.

Comproveu també quin adaptador ha triat el procés d'allotjament. Un procés lligat a l'adreça de la LAN de casa anunciarà aquesta adreça, i el jugador remot no hi pot encaminar encara que l'anunci arribi. La llista es pot omplir i la unió pot fallar només per aquest motiu.

Entengueu on s'atura la difusió

Un túnel TUN encaminat transporta paquets IP entre iguals i no reprodueix la difusió local a la xarxa de cada igual. L'adreça de difusió limitada 255.255.255.255 es queda dins de la interfície que l'emet, i una difusió dirigida a la subxarxa és un cas a part, no una llicència general perquè els encaminadors inundin anuncis.

Això és una propietat del disseny, no un defecte que es pugui pedaçar amb una opció. OpenVPN i la seva opció client-to-client governa el trànsit entre iguals dins del túnel i no és un relé de descobriment, tot i que en molts fils es proposa precisament per a això. Un relé és un component a part amb la seva configuració i els seus modes de fallada. Suposar que una opció existent ja ho cobreix és la manera més habitual que aquesta investigació s'encalli.

El descobriment per multicast té el mateix problema amb una altra classe d'adreces, i necessita encaminament multicast o un relé, no una excepció de difusió.

Quan un relé estigui justificat, manteniu-lo estret

Si el descobriment automàtic és un requisit, identifiqueu primer l'intercanvi real: difusió o multicast, adreça de destinació, port UDP, la interfície que l'envia i l'adreça dins de la resposta. Un relé adequat al protocol i limitat a aquests cinc fets és molt més estret que estendre un segment Ethernet sencer.

Retransmetre el paquet sense canvis pot continuar essent insuficient. Si la càrrega útil diu al receptor que es connecti a una adreça que no pot abastar, el relé lliura una resposta inútil, i per això cal provar la interfície pròpia del joc o l'ajust d'adreça anunciada abans que existeixi cap relé.

Limiteu el relé a les interfícies i els iguals que el necessiten, i definiu com les respostes troben el sol·licitant. Repetir difusions no relacionades exposa altres serveis locals i crea bucles que després són penosos de depurar.

Pont només quan el disseny necessiti Ethernet

Les trames Ethernet viatgen dins de TAP, així que un túnel TAP pot pertànyer a un domini de difusió deliberadament pontat. Simplement canviar dev tun per dev tap no construeix aquest pont, no fa compatible la configuració del servidor i no fa que l'aplicació triï la nova interfície. La guia de ponts d'OpenVPN descriu l'arranjament més ampli, no una cura per a un lobi buit.

El pont també aplana el pla d'adreces, i per això la decisió mereix una raó més enllà de la impaciència. Dues xarxes que estaven separades es converteixen en una, i cada servei de cada costat comença a veure les difusions de l'altre costat. Aquesta conseqüència ha de figurar al registre de canvis abans que ningú l'activi. No hi ha cap regla que els clients de joc hagin de seure en un rang 192.168; trieu un pla sense solapament i comproveu les restriccions del joc concret en lloc de renumerar el túnel perquè un missatge de fòrum ho va fer.

Al final manteniu els dos resultats separats: si s'hi pot unir a l'amfitrió i si la resposta de descobriment anuncia una destinació que l'altre jugador realment pot fer servir. Arreglar el segon sense confirmar el primer és com la gent acaba mantenint un pont per a un problema que mai no era de difusió.