Lista giochi LAN vuota su OpenVPN? Controlla il percorso di scoperta

Fare ping all'indirizzo del tunnel di un altro giocatore e vedere il suo gioco ospitato sono due risultati diversi. La lista della lobby di solito dipende da uno scambio di scoperta scritto per un'unica rete locale, mentre la sessione di gioco è una connessione normale a un indirizzo e una porta. Trattare una lista vuota come un guasto di routing ti manda verso un bridge che forse non ti serve, quindi separa le due domande prima di cambiare qualsiasi cosa.

Separa l'unirsi a una sessione dal trovarla

Un'unione fallita indica rotte, regole del firewall e un servizio in ascolto. Un'unione riuscita con una lista vuota indica la scoperta, o l'indirizzo che l'annuncio porta. Questi due esiti portano a un lavoro completamente diverso, e puoi distinguerli solo provando deliberatamente il primo.

Annota il risultato prima di toccare la configurazione della VPN. È il test più economico dell'intera indagine ed elimina metà dello spazio di progetto. Annota anche l'indirizzo usato, perché diventa il punto di riferimento per ogni test successivo. Senza quella riga nelle note, il confronto successivo è solo un'ipotesi.

Prova un'unione diretta prima di toccare il tunnel

Se il gioco offre un'opzione di connessione diretta, usa l'indirizzo del tunnel dell'host e la porta documentata del gioco, e lascia intatti l'autenticazione del gioco stesso e le regole del firewall dell'host. Un'unione riuscita restringe il problema alla scoperta. Un'unione fallita richiede comunque una propria indagine, e nessun relay la risolverà.

Non dare per scontato che la porta di scoperta e la porta di sessione siano lo stesso numero. I giochi di solito annunciano su una porta UDP e accettano giocatori su un'altra, e un relay costruito per quella sbagliata produce una lista che resta vuota.

Controlla anche quale adattatore ha scelto il processo di hosting. Un processo legato all'indirizzo della LAN domestica annuncerà quell'indirizzo, e il giocatore remoto non può instradare verso di esso anche se l'annuncio arriva. La lista può popolarsi e l'unione può comunque fallire solo per questo.

Capisci dove si ferma il broadcast

Un tunnel TUN instradato trasporta pacchetti IP tra peer e non riproduce il broadcast locale sulla rete di ogni peer. L'indirizzo di broadcast limitato 255.255.255.255 resta dentro l'interfaccia che lo emette, e un broadcast diretto alla sottorete è un caso a parte, non una licenza generale per i router di inondare gli annunci.

È una proprietà del progetto, non un difetto da rattoppare con un'opzione. OpenVPN e la sua client-to-client impostazione governa il traffico tra peer dentro il tunnel e non è un relay di scoperta, anche se viene suggerita proprio per questo scopo in molti thread. Un relay è un componente separato con la propria configurazione e i propri modi di guasto. Presumere che un'opzione esistente lo copra già è il modo più comune in cui questa indagine si blocca.

La scoperta multicast ha lo stesso problema con una classe di indirizzi diversa, e richiede routing multicast o un relay invece di un'eccezione al broadcast.

Quando un relay è giustificato, tienilo stretto

Se la scoperta automatica è un requisito, identifica prima lo scambio reale: broadcast o multicast, indirizzo di destinazione, porta UDP, l'interfaccia che lo invia e l'indirizzo dentro la risposta. Un relay adatto al protocollo e limitato a questi cinque fatti è molto più stretto che estendere un intero segmento Ethernet.

Inoltrare il pacchetto senza modifiche può comunque non bastare. Se il payload dice al destinatario di connettersi a un indirizzo che non riesce a raggiungere, il relay fornisce una risposta inutile, perciò l'interfaccia del gioco stesso o l'impostazione dell'indirizzo annunciato va provata prima che esista qualsiasi relay.

Limita il relay alle interfacce e ai peer che ne hanno bisogno, e definisci come le risposte trovano il richiedente. Ripetere broadcast non correlati espone altri servizi locali e crea loop che poi sono penosi da debuggare.

Bridge solo quando il progetto richiede Ethernet

I frame Ethernet viaggiano dentro TAP, quindi un tunnel TAP può appartenere a un dominio di broadcast deliberatamente pontato. Il semplice passaggio da dev tun a dev tap non costruisce quel bridge, non rende compatibile la configurazione del server e non porta l'applicazione a scegliere la nuova interfaccia. La guida al bridging di OpenVPN descrive la disposizione più ampia, non una cura per una singola lobby vuota.

Il bridging appiattisce anche il piano degli indirizzi, ed è per questo che la decisione merita una ragione oltre l'impazienza. Due reti che erano separate diventano una, e ogni servizio su ciascun lato inizia a vedere i broadcast dell'altro lato. Quella conseguenza appartiene al registro delle modifiche prima che qualcuno la attivi. Non esiste una regola per cui i client di gioco debbano stare in un intervallo 192.168; scegli un piano senza sovrapposizioni e controlla le restrizioni del gioco specifico invece di rinumerare il tunnel perché un post sul forum lo ha fatto.

Alla fine tieni separati i due risultati: se all'host ci si può unire, e se la risposta di scoperta annuncia una destinazione che l'altro giocatore può davvero usare. Correggere il secondo senza confermare il primo è il modo in cui la gente finisce per mantenere un bridge per un problema che non ha mai riguardato il broadcast.