Passa al contenuto
Protezione DDoS · Peeryx · 15 Tbps+
Tutte le guide

GRE, reverse proxy o BGP: come ricevere traffico protetto

GRE, reverse proxy e BGP svolgono compiti differenti. La scelta dipende da servizi, responsabilità di rete e percorso in entrambe le direzioni. Nessuna tecnica equivale da sola a protezione DDoS completa o garantisce una latenza precisa per ogni applicazione.

← Tutte le guideCubixServ

Prima di iniziare

Disegna endpoint pubblico, origine, protocolli e ritorno. Verifica autorizzazioni su indirizzi e reti e condizioni del gestore. Conserva configurazione, prepara manutenzione e definisci il ripristino prima di modificare instradamento o filtri condivisi con altri servizi.

Definire il problema da risolvere

Devi pubblicare un’applicazione HTTP, inoltrare un gioco TCP/UDP oppure annunciare un prefisso autorizzato? Sono esigenze diverse. Specifica anche se l’applicazione deve conoscere l’indirizzo originale del client. Il nome commerciale di un prodotto non spiega ritorno e servizi consentiti: conferma topologia e responsabilità di entrambi gli estremi prima di copiare una configurazione.

Per FiveM, endpoint di connessione, file e gameplay separati. Controlla gli indirizzi e i servizi pubblicizzati che rimangono diretti. Stabilisci se gli indirizzi dei client vengono conservati, quali informazioni raggiungono l'origine e quali regole di attendibilità corrispondono alla tua versione.

Capire il tunnel GRE

GRE incapsula pacchetti tra endpoint. In IPv4 usa il protocollo IP 47, non una porta TCP 47. Può trasportare traffico già filtrato se entrambi gli estremi sono configurati. Da solo non offre cifratura o autenticazione: limita fonti e proteggi gli endpoint. L’incapsulamento aumenta la dimensione e può ridurre la MTU utile, quindi verifica trasferimenti reali.

Verificare che le apparecchiature e le reti consentano GRE. In IPv4 utilizza un numero di protocollo IP, anziché semplicemente una porta TCP o UDP da aprire. L'incapsulamento aggiunge intestazioni: adatta e testa l'effettiva MTU, i percorsi e il percorso di ritorno. Una connessione che funziona con pacchetti piccoli potrebbe comunque fallire con pacchetti più grandi.

Distinguere proxy HTTP e trasporto

Un reverse proxy HTTP interpreta richieste HTTP. Altri servizi richiedono inoltro TCP o UDP adatto, per esempio il modulo Stream di NGINX quando previsto. Controlla durata delle sessioni, timeout e UDP. Una pagina funzionante non dimostra il funzionamento del gioco. La conservazione dell’indirizzo client dipende dai meccanismi che l’origine supporta davvero, non dalla sola presenza del proxy.

Sono necessari un contratto di routing, risorse autorizzate e i prerequisiti del fornitore. Annunciare prefissi di terze parti richiede una vera autorizzazione. Le dimensioni dei prefissi, i filtri e i processi di convalida accettati variano a seconda degli operatori. Un indirizzo VPS non garantisce automaticamente il diritto o la capacità di annunciare un prefisso su Internet.

Verificare requisiti BGP

BGP scambia informazioni di instradamento. Annunciare una rete richiede risorse autorizzate, accordi e politiche del gestore: un IP assegnato a un VPS non è un prefisso liberamente annunciabile. BGP non filtra attacchi da solo. Il transito protetto combina instradamento e filtro. Chiarisci dimensioni dei prefissi, condizioni, ritorno e responsabilità durante un guasto.

Identifica anche i percorsi di bypass: vecchi indirizzi, DNS secondari, file, strumenti vocali o di amministrazione. Prima di limitare un'origine, verificare le fonti legittime e i servizi richiesti. La protezione remota non elimina la necessità di controllare l'esposizione diretta della destinazione.

Provare MTU e percorso di ritorno

Prova dati di dimensioni rappresentative, non solo piccoli pacchetti o una singola porta. Una MTU errata può interrompere trasferimenti mentre un controllo semplice riesce. Percorsi asimmetrici possono influire su componenti con stato: documenta entrambe le direzioni. Non cambiare MTU o rotte globali senza considerare gli altri servizi e mantenere un ritorno verificabile alla configurazione precedente.

Modifica un componente alla volta con una configurazione di rollback disponibile. Coordinare e limitare qualsiasi carico di prova. La modifica simultanea di DNS, proxy, tunnel e firewall rende difficile identificare il motivo per cui un test fallisce.

Scegliere una soluzione gestibile

Un sito isolato ha esigenze diverse da più protocolli o una rete propria. Considera monitoraggio, recupero e chi interviene durante un’interruzione. La tecnica più ampia non è automaticamente la migliore. Prova le applicazioni prima di migrare e documenta collegamenti, perdita, ritardi e limiti. Il nome del metodo non implica capacità dedicata o protezione applicativa universale.

Confronta responsabilità, disponibilità effettiva, limiti di traffico e prezzi per l'ambito scelto. La combinazione di meccanismi può aiutare, ma ogni livello aggiunge impostazioni e requisiti di monitoraggio. Mantieni una descrizione semplice che il tuo team e il tuo fornitore possano verificare insieme.

Cosa fare nel tuo caso

SituazioneProssimo passo
Una singola applicazione HTTPValuta un proxy HTTP con regole per l’origine e amministrazione separata.
Più servizi TCP/UDPConfronta tunnel e inoltro di trasporto, includendo MTU, indirizzo client e ritorno.
Una rete IP propria autorizzataConcorda BGP e transito con il gestore. Un singolo indirizzo VPS non basta ad annunciare un prefisso.

Fonti ufficiali

Queste fonti descrivono i protocolli e le impostazioni citati. Controlla sempre la documentazione della tua versione.

  1. RFC Editor / IETF/rfc/rfc2784
  2. RFC Editor / IETF/rfc/rfc4271
  3. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  4. Cfx.re/docs/server-manual/proxy-setup/