Prima di iniziare
Annota indirizzi, porte, versione degli artifact e servizi pubblici. Conserva configurazione ed elenco delle fonti autorizzate di proxy e filtro. Prepara una manutenzione annunciata e un ritorno verificabile prima di cambiare il percorso dei giocatori verso l’origine.
Elencare gli endpoint pubblici
Distingui indirizzo di gioco, lista, download e amministrazione. Se proteggi soltanto un accesso, gli altri richiedono comunque una valutazione. Usa porte assegnate dal pannello: txAdmin non sostituisce la porta di gioco. Su un nodo condiviso non puoi scegliere porte di altre istanze o aggiungere servizi senza rispettare lo schema operativo del gestore.
Controlla anche gli indirizzi di dominio, i vecchi indirizzi pubblici e gli endpoint pubblicizzati da FXServer. Un servizio secondario può esporre l'origine anche quando il collegamento principale utilizza un proxy. Utilizza questo inventario per stabilire l'ambito con il fornitore.
Verificare TCP e UDP
Controlla separatamente ingresso, file e gestione. Una risposta HTTP o una porta TCP aperta non validano tutto il percorso UDP. Un proxy HTTP copre la parte configurata per HTTP; il gioco richiede il proprio trattamento di rete e trasporto. Chiedi una descrizione della topologia prima di interpretare L7 come protezione completa di ogni funzione FiveM.
Se utilizzi una cache di file, controlla le destinazioni e le condizioni di accesso. Le impostazioni proxy e file dipendono dalla versione FXServer. Un'impostazione nella documentazione più recente potrebbe essere assente da un artefatto precedente: conferma la disponibilità prima di modificare la configurazione.
Usare la configurazione ufficiale del proxy
Cfx.re documenta proxy e distribuzione esterna dei file. Le impostazioni devono corrispondere alla versione degli artifact e agli endpoint effettivi. Non copiare una guida per un’altra versione senza verificarla. Limita i proxy attendibili alle fonti autorizzate: fidarsi di tutto Internet elimina quella separazione. Definisci quali collegamenti dovranno funzionare dopo la modifica e provali in modo controllato.
Mantieni elenchi precisi e documentati di fonti attendibili. Un'indennità globale o un indirizzo proxy errato possono compromettere la protezione; un blocco fuori posto può impedire ai giocatori di unirsi. La rotazione di uno IP o di una porta non sostituisce la protezione dell'origine e non deve essere descritta come automatica senza un meccanismo fornito.
Esaminare i percorsi diretti all’origine
Un attaccante può evitare l’intermediario se un’origine non protetta rimane raggiungibile. Controlla DNS, URL delle risorse e porte aggiuntive. Cambiare IP pubblico non cancella i percorsi già noti. Limita l’origine dopo aver confermato fonti e ritorno. La rotazione automatica IP è disponibile soltanto quando la funzione è documentata e realmente configurata nel servizio specifico.
Non esporre pubblicamente un database o uno strumento di amministrazione senza una necessità identificata e controlli adeguati. Il pannello hosting e txAdmin sono ambienti separati; proteggere l'uno non garantisce la sicurezza dell'altro. Mantenere il software e rivedere l'accesso dopo i cambiamenti del team.
Mettere in sicurezza risorse ed eventi
La protezione della rete non sostituisce la validazione sul server. Controlla permessi, limiti ed eventi che generano lavoro; i dati inviati dal client non vanno considerati attendibili senza verifiche. Associa errori al carico di script e database. Una risorsa costosa può sembrare un problema di connessione, e più RAM o un filtro diverso non correggono automaticamente il codice.
Monitora gli errori ripetuti e le operazioni che diventano costose sotto carico. Testa le modifiche su una copia, conserva le versioni precedenti e gestisci le dipendenze. I framework e le risorse richiedono manutenzione; l'aggiunta della protezione non rende automaticamente sicuri gli script.
Provare l’esperienza del giocatore
Dopo una modifica rilevante prova lista, ingresso, file e gioco da accessi indipendenti. Registra ora e carico per un confronto. Un test della pagina web non prova la latenza UDP. I 15 Tbps sono capacità aggregata a monte, non la porta del server. Conferma limiti e copertura; test intensivi che coinvolgono altre istanze devono essere concordati.
Durante un incidente, conserva l'ora, le reti interessate, i messaggi e gli eventi di mitigazione disponibili. Distinguere saturazione, falsi positivi, difetti delle risorse ed errori di amministrazione. Coordina i test attivi con il provider anziché inviare traffico di carico improvvisato alla produzione.
Cosa fare nel tuo caso
| Situazione | Prossimo passo |
|---|---|
| Solo HTTP è protetto | Verifica anche TCP/UDP e accessi diretti all’origine. Una pagina raggiungibile non copre tutto il gioco. |
| Guasto dopo una regola | Confronta fonti e ritorno con il progetto e usa il ripristino preparato. |
| Rete normale, gioco bloccato | Profila risorse, eventi e database insieme ai dati di rete. |
Fonti ufficiali
Queste fonti descrivono i protocolli e le impostazioni citati. Controlla sempre la documentazione della tua versione.