{"id":4302,"date":"2022-04-01T13:58:00","date_gmt":"2022-04-01T11:58:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=4302"},"modified":"2022-04-01T14:47:49","modified_gmt":"2022-04-01T12:47:49","slug":"networking-per-lhybrid-cloud-backup-di-aws-direct-connect-tramite-aws-site-to-site-vpn","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/networking-per-lhybrid-cloud-backup-di-aws-direct-connect-tramite-aws-site-to-site-vpn\/","title":{"rendered":"AWS Direct Connect con AWS Site-To-Site VPN come failover"},"content":{"rendered":"\n
Oggi, molte soluzioni richiedono approcci che implementino un uso congiunto dei cloud provider pubblici e delle proprie risorse on-premise. In questa serie di articoli, vogliamo fornire una panoramica dei servizi AWS utili per creare una rete ibrida che estende facilmente i carichi di lavoro dalle installazioni locali al cloud pubblico in base alle esigenze aziendali.<\/p>\n\n\n\n
In alcuni scenari, le reti cloud ibride si basano su AWS Direct Connect (DX)<\/strong>. Questo servizio offre un’altra opzione anzich\u00e9 Internet per connettersi ad AWS, fornendo una connessione di rete privata tra la struttura on-premise<\/strong> e il cloud AWS<\/strong>.<\/p>\n\n\n\n Se desideri saperne di pi\u00f9 su Direct Connect, controlla il nostro post precedente<\/a>: spiega nel dettaglio che cos\u2019\u00e8, come funziona e come sceglierlo in relazione ad alle proprie esigenze.<\/p>\n\n\n\n In alcuni casi, questa connessione da sola non \u00e8 sufficiente. \u00c8 sempre meglio garantire una connessione di fallback<\/strong> come backup di DX. Ci sono diverse opzioni, ma implementare il tutto con una VPN Site-To-Site <\/strong>\u00e8 una soluzione conveniente che pu\u00f2 essere sfruttata per ridurre i costi o, nel frattempo, attendere il setup di un secondo DX.<\/p>\n\n\n\n Bisogna tenere presente che questa soluzione non garantisce alcun Accordo sul Livello del Servizio (SLA) ed \u00e8 impossibile ottenerlo con una connessione Internet pubblica.<\/p>\n\n\n\n Questo articolo riprender\u00e0 alcuni argomenti di quanto gi\u00e0 realizzato nell’articolo precedente (Hybrid Cloud Networking: gateway NAT centralizzato tramite AWS Transit Gateway<\/a>). Abbiamo presentato come configurare un Transit Gateway e condividere apparati di rete tra account AWS. Quindi, per favore, potrebbe essere utile leggerlo per comprendere al meglio ci\u00f2 che verr\u00e0 presentato successivamente.<\/p>\n\n\n\n Si supponga che un’azienda fittizia desideri connettere i propri uffici con gli account AWS direttamente tramite DX utilizzando una VPN da sito a sito come backup.<\/p>\n\n\n\n Prima di procedere \u00e8 necessario che sia gi\u00e0 stato richiesto e ordinato un Direct Connect e che l’intera rete AWS sia stata centralizzata tramite Transit Gateway. <\/p>\n\n\n\n Come mostrato di seguito, la connessione tra la struttura locale e AWS tramite la connessione privata Direct Connect pu\u00f2 essere configurata collegando direttamente il DX al Transit Gateway.<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Entrando nel dettaglio:<\/strong><\/p>\n\n\n\n Direct Connect offre una struttura che si basa su un canale di trasporto in fibra ottica Ethernet standard. Un’estremit\u00e0 \u00e8 collegata al router on-premise e l’altra al router di AWS DX. Un utente pu\u00f2 associare direttamente Direct Connect al Transit Gateway tramite Transit Virtual Interface (VIF)<\/strong>. Questa specifica interfaccia \u00e8 differente da una privata\/pubblica perch\u00e9 \u00e8 collegata direttamente con il Transit Gateway. Ci\u00f2 consente la connettivit\u00e0 a tutte le VPC che condividono un Transit Gateway attachment.<\/p>\n\n\n\n Nota bene! Durante la configurazione, bisogna ricordare che \u00e8 possibile collegare solo un\u2019interfaccia virtuale per il Transit Gateway per la connessione DX dedicata. Questo limite non pu\u00f2 essere aumentato.<\/p>\n\n\n\n Al termine della configurazione, l’azienda desidera utilizzare la VPN Site-to-Site<\/strong> come backup. Essa consiste in un collegamento crittografato, chiamato tunnel VPN, che collega gli uffici con AWS. Ogni connessione VPN include due tunnel VPN che si possono utilizzare contemporaneamente per garantire alta disponibilit\u00e0. Nel nostro caso, i due endpoint saranno il Customer Gateway (CGW) per il lato on-prem e il Transit Gateway per quello AWS.<\/p>\n\n\n\n Si tenga presente che la VPN ha un alcuni limiti che devono essere presi in considerazione per questo progetto:<\/p>\n\n\n\n Lo scenario modificato sar\u00e0 il seguente:<\/p>\n\n\n\n <\/p>\n\n\n\n <\/p>\n\n\n\n Con questa configurazione aggiornata, il traffico scorrer\u00e0 principalmente attraverso Direct Connect e, qualora si verificasse<\/strong> un errore sulla DX<\/strong>, verr\u00e0 trasferito al canale VPN di failover<\/strong>. Lo scopo dell’utilizzo di DX come percorso attivo principale garantisce:<\/p>\n\n\n\n L’intero routing e il meccanismo di failover \u00e8 gestito dal protocollo BGP<\/a>, ed \u00e8 un requisito necessario che il router gateway del cliente lo supporti. Il funzionamento consiste nel router che invia vari pacchetti (keep alive) per verificare se il percorso DX \u00e8 attivo. Se viene rilevato un errore, il percorso viene commutato su quello di fallback (VPN). Perci\u00f2 il Customer Gateway, sia esso software o fisico, deve essere configurato in modo appropriato dall’amministratore di rete per scambiare informazioni di routing tra i vari router. Il dispositivo funziona gestendo una tabella di IP (chiamati prefissi) che fornisce informazioni sulla raggiungibilit\u00e0 delle diverse reti che stiamo osservando. Quindi, BGP \u00e8 responsabile dello scambio di annunci di blocchi IP (prefissi IP) ai vari sistemi. <\/p>\n\n\n\n <\/p>\n\n\n\n Quindi, per avere la nostra infrastruttura completamente funzionante, \u00e8 necessario notificare lo stesso prefisso<\/strong> sia per Direct Connect (VIF)<\/strong> che per la VPN<\/strong>, perch\u00e9 se il CGW notifica gli stessi percorsi verso la VPC di AWS, il percorso tramite Direct Connect \u00e8 sempre preferito, indipendentemente dall\u2019AS Path prepending.<\/p>\n\n\n\n Per favore, considerando il punto 3 della tabella, si faccia attenzione si configura la VPN Site-to-Site. All’interno del form guidato della VPN, un utente deve specificare “Dynamic<\/strong>” come Routing Option<\/strong>, altrimenti tutto quanto presentato finora non sarebbe applicabile.<\/p>\n\n\n\n A volte, con questo tipo di configurazione potrebbe verificarsi uno scenario di routing asimmetrico. Il routing asimmetrico <\/strong>implica che un pacchetto attraversa da un punto d’origine a una destinazione in un percorso iniziale e prende un secondo percorso diverso quando ritorna all’origine. <\/p>\n\n\n\n Ovvero, il traffico da AWS all\u2019on-premise potrebbe fluire inizialmente attraverso il collegamento Direct Connect, ma per il ritorno, il traffico potrebbe invece attraversare il tunnel VPN.Per risolvere questo problema, si consideri questa guida di AWS che risolve il problema<\/a>.<\/p>\n\n\n\n Ora che il networking generale \u00e8 stato impostato, condivideremo ci\u00f2 che \u00e8 possibile ottenere sfruttando queste tecnologie:<\/p>\n\n\n\n Supponiamo quindi di creare una soluzione per l\u2019HPC (High-Performance Computing) con istanze EC2 che opereranno su set di dati di grandi dimensioni, che dovranno essere trasferiti tra la struttura on-prem e il cloud di AWS.<\/p>\n\n\n\nInfrastruttura ad Alto Livello<\/h1>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Ma se BGP \u00e8 responsabile nell\u2019annunciare i prefissi, come sono gestite da AWS le priorit\u00e0<\/strong> delle rotte? Bene, per capirlo bisogna spostare l’attenzione sul Transit Gateway e riassumere l\u2019ordine in una tabella:<\/p>\n\n\n\n<\/figure><\/div>\n\n\n\n
Hybrid Cloud<\/h1>\n\n\n\n