Bring Your Own IP su un VPS con BGP: guida completa

Questa pagina è il punto centrale dell'intero percorso BYOIP. Collega ogni passaggio dall'ottenimento di un ASN al monitoraggio degli annunci BGP in produzione. Ogni sezione rimanda a un articolo dedicato con configurazioni, comandi e passaggi di verifica.

Se sai già cosa sono BGP e BYOIP, vai direttamente a Di cosa hai bisogno prima della prima sessione BGP?.

Cosa significa portare il proprio IP su un VPS?

Bring Your Own IP (BYOIP) significa annunciare spazio di indirizzi IP che possiedi o noleggi da un Regional Internet Registry (RIR) attraverso la rete di un provider di hosting usando BGP. Invece di usare gli indirizzi IP del provider, il tuo VPS origina le rotte per i tuoi prefissi. Il traffico destinato a quegli IP raggiunge il tuo server attraverso i link upstream e gli internet exchange del provider.

Mantieni il controllo degli indirizzi. Se cambi provider, i tuoi IP si spostano con te. Nessuna modifica DNS, nessun reset della reputazione, nessun downtime percepito dai clienti oltre la finestra di convergenza.

Perché portare i propri IP?

Continuità della reputazione IP. La deliverability delle email, la reputazione DNS e le allowlist dei firewall seguono l'indirizzo, non il server. Cambiare provider con IP assegnati dal provider significa ricostruire la reputazione da zero.

Portabilità tra provider. I tuoi prefissi non sono legati a nessun singolo host. Puoi passare a un altro provider, o operare in multi-homing su due, senza cambiare gli indirizzi a cui si connettono i tuoi clienti.

Multi-homing e ridondanza. Annuncia lo stesso prefisso da più posizioni. BGP gestisce il failover automaticamente. Il tuo servizio resta raggiungibile anche quando un sito va giù.

Conformità e audit. Alcuni ambienti regolamentati richiedono documentazione sulla proprietà degli indirizzi IP. Possedere la propria allocazione tramite un RIR fornisce quella tracciabilità.

Anycast. Annuncia lo stesso prefisso da nodi geograficamente distribuiti. Gli utenti vengono instradati verso il più vicino. È così che funzionano i server DNS root e gli edge CDN.

Come si inserisce BGP nel BYOIP?

BGP (Border Gateway Protocol) è il protocollo che i router usano per scambiare informazioni di raggiungibilità tra sistemi autonomi su Internet. Quando porti il tuo IP su un VPS, esegui un daemon BGP sul tuo server. Quel daemon stabilisce una sessione con il router del tuo provider e annuncia i tuoi prefissi. Il provider propaga quegli annunci ai suoi upstream e peer. In pochi minuti, i router in tutto Internet apprendono che il tuo spazio IP è raggiungibile attraverso la rete del tuo provider.

È lo stesso protocollo che ogni ISP, provider cloud e rete di contenuti utilizza. La differenza è la scala: annunci uno o due prefissi invece di migliaia.

Non devi capire ogni attributo BGP per iniziare. Devi sapere come configurare una sessione, annunciare un prefisso e filtrare ciò che accetti. Gli articoli di approfondimento in questo cocoon coprono ciascuno di questi punti nel dettaglio.

Di cosa hai bisogno prima della prima sessione BGP?

Sei blocchi fondamentali, in ordine di dipendenza:

Un Autonomous System Number (ASN). La tua identità nell'Internet BGP. Lo ottieni da un RIR (RIPE NCC in Europa, ARIN in Nord America, APNIC in Asia-Pacifico) tramite un LIR sponsor. L'elaborazione richiede 2-5 giorni lavorativi al RIPE NCC.
Un'allocazione IP. Minimo un /24 per IPv4 o un /48 per IPv6. Prefissi più piccoli vengono filtrati dalla maggior parte delle reti e non si propagano. Puoi detenere spazio IPv4 da un RIR (sempre più scarso e costoso) o noleggiarlo da un broker. Le allocazioni IPv6 sono facilmente disponibili da tutti i RIR.
Oggetti route IRR. Voci nell'Internet Routing Registry che documentano quale ASN è autorizzato a originare il tuo prefisso. Molti provider di transito costruiscono i loro filtri BGP dai dati IRR. Senza un oggetto route corrispondente, il tuo annuncio potrebbe essere scartato silenziosamente. Creali nel database RIPE (o nell'equivalente del tuo RIR) prima della prima sessione.
ROA RPKI (Route Origin Authorizations). Oggetti crittografici che legano il tuo prefisso al tuo ASN. Oltre il 51% delle rotte IPv4 e il 57% delle rotte IPv6 hanno ora ROA validi. Le reti che eseguono Route Origin Validation (ROV) rifiuteranno gli annunci che non superano i controlli RPKI. Crea i ROA nel portale del tuo RIR.
Un daemon di routing. Software sul tuo VPS che parla BGP. Le tre opzioni principali sono BIRD2, FRRouting (FRR) e VyOS. Vedi il confronto sotto.
Un provider con supporto sessioni BGP. Non tutti i provider VPS offrono questo servizio. Hai bisogno di un provider che configuri una sessione BGP tra il suo router e il tuo VPS, accetti i tuoi annunci di prefisso e li propaghi upstream.

Checklist pre-avvio

Prima di richiedere una sessione BGP al tuo provider, assicurati di avere:

Elemento	Dove ottenerlo	Tempo stimato
ASN	RIR tramite LIR sponsor	2-5 giorni lavorativi
IPv4 /24 o più grande	Allocazione RIR o noleggio	Giorni a settimane
IPv6 /48 o più grande	Allocazione RIR	1-2 giorni lavorativi
Oggetti route/route6 IRR	Database RIPE o equivalente	Minuti (dopo ASN)
ROA RPKI per ogni prefisso	Portale membri RIR	Minuti
LOA (Lettera di autorizzazione)	La firmi tu, il provider può richiederla	Minuti
Provider con supporto BGP	o simile	Variabile

Il tuo provider avrà tipicamente bisogno del tuo ASN, dei prefissi che intendi annunciare e possibilmente di una LOA che confermi che sei autorizzato ad annunciarli.

Come si collegano ASN, allocazione IP e RPKI?

Questi tre formano la catena di fiducia che permette a Internet di verificare che i tuoi annunci siano legittimi.

Il tuo ASN identifica la tua rete. Ogni annuncio BGP porta l'ASN di origine nel suo AS-path. Le reti upstream usano questo per costruire la policy di routing.

La tua allocazione IP è lo spazio di indirizzi che sei autorizzato a usare. Il database del RIR registra te (o il tuo LIR sponsor) come titolare.

Gli oggetti IRR sono il livello della policy di routing. Un oggetto route nel database RIPE dice "AS64500 è autorizzato a originare 192.0.2.0/24." I provider di transito interrogano i dati IRR per costruire filtri di prefissi. Se il tuo oggetto route manca o è errato, i filtri automatizzati del tuo provider di transito possono rifiutare il tuo annuncio.

I ROA RPKI sono il livello crittografico. Un ROA è un oggetto firmato memorizzato nel repository RPKI del tuo RIR. Dice la stessa cosa dell'oggetto route IRR, ma è verificabile crittograficamente. Le reti che eseguono validatori ROV (Routinator, rpki-client, Fort, RIPE NCC RPKI Validator) recuperano i ROA e inviano i risultati della validazione ai loro router. Un annuncio senza un ROA valido ha sempre più probabilità di essere scartato.

La catena di dipendenze è questa:

ASN (from RIR)
  └── IP allocation (from RIR)
        ├── IRR route objects (RIPE Database)
        ├── RPKI ROAs (RIR portal)
        └── BGP session (provider router <-> your daemon)
              └── Prefix announcement (your daemon originates routes)

Metti in ordine i livelli superiori prima di toccare la configurazione BGP. Un annuncio senza record IRR e RPKI corrispondenti verrà filtrato o segnalato come potenziale hijack.

Quale daemon di routing scegliere: BIRD2, FRR o VyOS?

Tre opzioni dominano BGP su ambienti VPS Linux. Tutte e tre supportano dual-stack (IPv4 + IPv6), validazione RPKI e le funzionalità necessarie per BYOIP. La scelta dipende dallo stile di configurazione preferito e dai requisiti operativi.

Funzionalità	BIRD2	FRRouting (FRR)	VyOS
Stile di configurazione	Linguaggio dichiarativo proprietario	CLI tipo Cisco IOS (vtysh)	CLI tipo JunOS (set/commit)
Linguaggio di filtraggio	Filtri potenti, Turing-completi	Route-maps + prefix-lists	Route-maps (FRR sotto il cofano)
Dual-stack	File di configurazione unico, multi-tabella	Blocchi address-family separati	Blocchi address-family separati
Supporto RPKI	Protocollo `rpki` integrato	Modulo rpki integrato	Tramite integrazione FRR
Uso memoria	Inferiore (2x più efficiente di FRR nei benchmark)	Superiore, specialmente con tabelle complete	Superiore (overhead di un OS completo)
Curva di apprendimento	Più ripida se vieni da Cisco	Bassa per utenti Cisco/IOS	Bassa per utenti JunOS
Ideale per	Route server IXP, setup con molte policy	Workflow familiare tipo Cisco	Esperienza completa di router OS

BIRD2 ha il linguaggio di filtraggio più espressivo. Puoi scrivere policy di import/export complesse in un singolo file di configurazione. Gestisce sia IPv4 che IPv6 in una singola istanza del daemon. L'impronta di memoria è circa la metà di FRR per carichi equivalenti. Il compromesso: la sua sintassi di configurazione non ha equivalenti nel mondo dei vendor. Impari il linguaggio di BIRD o non usi BIRD.

FRRouting (FRR) usa un CLI tipo Cisco IOS tramite vtysh. Se hai lavorato con Cisco, Arista o il vecchio Quagga, FRR risulta subito familiare. Route-maps e prefix-lists funzionano come ti aspetti. È la suite di routing open-source più diffusa.

VyOS è un sistema operativo di rete completo che usa FRR come motore di routing. Configuri tutto attraverso un workflow set / commit in stile JunOS. Fornisce un'esperienza router completa: firewall, NAT, VPN, DHCP e routing in un unico pacchetto. Su Virtua Cloud, puoi deployare VyOS con un clic. Il compromesso: è un OS completo, non solo un daemon. Perdi la flessibilità di un server Linux generico.

Quale scegliere? Se vuoi il massimo controllo ed efficienza, scegli BIRD2. Se vuoi la familiarità Cisco su un server Linux, scegli FRR. Se vuoi un appliance router dedicato, scegli VyOS.

Come mettere in sicurezza un deployment BGP?

La sicurezza in BGP non è opzionale. Una sessione BGP mal configurata può far trapelare rotte, accettare prefissi dirottati o esporre la tua rete all'iniezione di traffico. Ogni deployment BGP dovrebbe includere questi livelli dal primo giorno.

RPKI e Route Origin Validation

Configura il tuo daemon per validare le rotte ricevute contro i dati RPKI. Esegui una cache RPKI locale (Routinator o rpki-client) o connettiti a un validatore ospitato. Rifiuta le rotte con stato RPKI "invalid". Questo impedisce al tuo router di accettare prefissi dirottati.

Nel 2025, oltre il 51% delle rotte IPv4 e il 57% delle rotte IPv6 hanno ROA validi. Tutti i principali provider di transito eseguono ROV. Se i tuoi prefissi non hanno ROA, alcune reti scarteranno i tuoi annunci.

Filtraggio delle rotte

Non usare mai export all o import all in produzione. Sono l'equivalente BGP di chmod 777.

Sul lato export, annuncia solo i prefissi che sei autorizzato a originare. Usa una prefix-list che corrisponda esplicitamente alle tue allocazioni. Sul lato import, se sei single-homed (un upstream), tipicamente accetti solo una rotta di default. Se sei multi-homed, filtra le importazioni per prefix-list e AS-path per prevenire route leak.

Rifiuta i prefissi bogon (spazio RFC 1918, range di documentazione, blocchi non allocati) in importazione. Rifiuta i prefissi più lunghi di /24 per IPv4 o /48 per IPv6. Imposta limiti max-prefix per proteggerti da un peer che scarica accidentalmente un'intera tabella di routing nella tua sessione.

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) garantisce che i pacchetti BGP arrivino con un TTL di 255, il che significa che sono originati da un vicino direttamente connesso. Questo blocca gli attaccanti remoti dall'iniettare pacchetti BGP. La maggior parte dei provider lo supporta. Abilitalo dal tuo lato quando il tuo provider conferma il supporto.

Regole firewall

Consenti la porta TCP 179 solo dall'IP del router BGP del tuo provider. Scarta tutto il resto destinato alla porta 179. È una singola regola nftables o iptables, ma previene tentativi di connessione BGP non autorizzati.

Errori comuni

rp_filter che rompe il traffico. Il reverse path filtering di Linux (rp_filter=1, il default su molte distribuzioni) scarta i pacchetti che arrivano su un'interfaccia se la tabella di routing del kernel dice che l'IP sorgente dovrebbe arrivare su un'interfaccia diversa. Con prefissi annunciati via BGP su interfacce dummy, questo rompe il traffico legittimo. Imposta rp_filter=0 o rp_filter=2 (modalità loose) sulle interfacce interessate. Testa dopo ogni aggiornamento del kernel.

Confusione tra configurazione BIRD 1.x e BIRD 2.x. BIRD 2 usa una sintassi di configurazione completamente diversa da BIRD 1.x. Molti tutorial online (inclusi risultati in cima alle ricerche di Vultr e altri) mostrano ancora la sintassi BIRD 1.x. Se copi-incolli la configurazione da un vecchio tutorial in BIRD 2, il daemon si rifiuterà di avviarsi. Controlla sempre quale versione stai eseguendo con birdc show status.

Oggetti IRR mancanti. Hai creato i ROA RPKI ma hai dimenticato l'oggetto route IRR. Il costruttore di filtri automatizzato del tuo upstream interroga IRR, non trova nessun oggetto corrispondente e scarta silenziosamente il tuo annuncio. Il tuo prefisso è RPKI-valid ma resta irraggiungibile. Crea sempre entrambi.

Cosa puoi fare con BGP oltre agli annunci di base?

Una volta che il tuo prefisso è annunciato e raggiungibile, BGP apre diversi casi d'uso avanzati.

Anycast

Annuncia lo stesso prefisso da più posizioni geografiche. Ogni sito esegue un servizio identico (resolver DNS, edge CDN, endpoint API). Gli utenti vengono instradati al sito più vicino dalla selezione del percorso BGP. Se un sito fallisce, la sua sessione BGP cade, il prefisso viene ritirato da quella posizione e il traffico si sposta automaticamente ai siti rimanenti.

Anycast è il principio di funzionamento del sistema dei server DNS root. Puoi eseguire lo stesso pattern con due o tre nodi VPS in data center diversi.

Failover e multi-homing

Annuncia il tuo prefisso da due provider o due posizioni con lo stesso provider. Usa LOCAL_PREF e MED per impostare la preferenza primario/backup. Quando il primario fallisce, il traffico si sposta al backup entro la finestra di convergenza BGP (tipicamente 30-90 secondi con BFD abilitato).

Per la manutenzione pianificata, usa la community graceful shutdown (RFC 8326). Il tuo daemon segnala ai peer di deprioritizzare il prefisso prima che tu chiuda la sessione. Il traffico drena al sito di backup senza perdita di pacchetti.

Community BGP per il traffic engineering

Le community sono tag allegati agli annunci BGP che influenzano il modo in cui le reti upstream gestiscono le tue rotte. Usi comuni:

Community blackhole: Segnala al tuo upstream di scartare tutto il traffico verso un prefisso specifico durante un attacco DDoS.
Controllo del prepending: Chiedi al tuo upstream di fare prepend del tuo AS per rendere un percorso meno preferito, dirottando il traffico verso un altro upstream.
Annuncio selettivo: Annuncia ai peer ma non al transito, o viceversa, controllando dove si propaga il tuo prefisso.
Scope geografico: Limita l'annuncio a regioni o IXP specifici.

Ogni provider definisce i propri valori di community. Consulta la documentazione delle community BGP del tuo provider prima di usarle.

Come monitorare gli annunci BGP?

Devi sapere quando qualcosa cambia con i tuoi prefissi. Dirottamenti di rotte, ritiri accidentali, cambiamenti di stato RPKI e cali di visibilità richiedono tutti attenzione immediata. Non dare per scontato che i tuoi annunci siano stabili perché funzionavano ieri.

BGPalerter è uno strumento di monitoraggio self-hosted che sorveglia i tuoi prefissi e ASN. Si connette a fonti di dati BGP pubbliche (RIPE RIS, RouteViews) e ti avvisa su:

Dirottamenti di prefisso (un altro ASN che origina il tuo prefisso)
Dirottamenti di sotto-prefisso (qualcuno che annuncia un più specifico del tuo prefisso)
Route leak
Cambiamenti di stato RPKI invalid
Cali di visibilità (il tuo prefisso scompare da un numero significativo di punti di osservazione)

Eseguilo come servizio systemd su un VPS separato da quello che fa BGP. Se il tuo nodo BGP va giù, vuoi comunque ricevere gli alert. Configura le notifiche verso Slack, email o il tuo stack di monitoraggio.

Strumenti di validazione esterna

Usali per verificare che i tuoi annunci appaiano corretti dall'esterno:

bgp.tools -- Vista in tempo reale del tuo prefisso, AS-path, stato RPKI e coerenza IRR
RIPE Stat -- Looking glass gestito dal RIR con cronologia di routing e validazione RPKI
Hurricane Electric BGP Toolkit (bgp.he.net) -- Informazioni AS, report sui prefissi, stato IRR e RPKI
Server looking glass -- La maggior parte dei provider di transito e degli IXP offre accesso looking glass per verificare come il tuo prefisso appare dalla loro prospettiva

Controlla questi strumenti dopo il tuo primo annuncio e periodicamente in seguito. Un annuncio che sembra corretto dalla prospettiva del tuo daemon potrebbe essere filtrato o dirottato più a monte.

Il percorso completo: da zero a BGP monitorato

Ecco il percorso completo, con i link all'articolo che copre ogni passaggio:

Ottenere un ASN dal tuo RIR tramite un LIR sponsor.
Ottenere spazio IP. Minimo /24 IPv4, /48 IPv6. Dal tuo RIR o da un broker.
Creare oggetti route IRR nel database RIPE per ogni prefisso.
Creare ROA RPKI nel portale del tuo RIR per ogni prefisso.
Scegliere un daemon di routing: BIRD2 , FRR o VyOS .
Configurare BGP sul tuo VPS. Stabilire la sessione, annunciare i tuoi prefissi, applicare i filtri.
Mettere in sicurezza il deployment. Validazione RPKI, filtraggio delle rotte, GTSM, regole firewall.
Verificare dall'esterno. Controllare bgp.tools, RIPE Stat e il looking glass del tuo provider.
Configurare il monitoraggio. Deployare BGPalerter per monitorare dirottamenti e problemi di visibilità.
Esplorare casi d'uso avanzati. Community , anycast , failover .

Serve un proprio ASN o basta uno privato?

Se annunci prefissi a un solo upstream e non prevedi mai multi-homing o peering a un IXP, un ASN privato (64512-65534 per 16 bit, 4200000000-4294967294 per 32 bit) può funzionare. Il tuo provider lo rimuove dall'AS-path prima di propagare le tue rotte upstream.

Ottieni il tuo ASN pubblico se si applica uno di questi casi:

Prevedi di connetterti a più upstream (multi-homing)
Vuoi fare peering a un internet exchange
Vuoi che il tuo ASN sia visibile nei traceroute e nei looking glass BGP
Vuoi usare community BGP che referenziano il tuo ASN
Gestisci un servizio dove l'identità di rete conta (CDN, DNS, infrastruttura email)

La differenza di costo è minima. Un ASN pubblico tramite RIPE NCC costa la tariffa del LIR sponsor (tipicamente qualche centinaio di euro all'anno). Per la maggior parte dei casi d'uso, un ASN pubblico è la scelta giusta.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.