VPN in cloud hosting / ambienti server dedicati, tunnel IPSec vs tinc

Sto progettando una configurazione di rete privata virtuale per un ambiente di cloud hosting. Dati i nostri requisiti, non lo vedo davvero diverso da un ambiente server dedicato. L'idea è che vogliamo consentire ai clienti di essere in grado di richiedere ai loro utenti di connettersi a macchine virtuali specifiche o server dedicati utilizzando una VPN che potrebbe fornire la crittografia ausiliaria (ad esempio per i lavori di stampa inviati alle reti dei clienti).

Stiamo cercando di supportare l'host per ospitare IPSec (ESP e AH) e ovviamente i tunnel SSH, ma nessuno di questi offre davvero la possibilità di utilizzare adattatori VPN. Di conseguenza stiamo valutando di aggiungere almeno alcune delle seguenti, ma poiché lo spazio è un premio, vogliamo standardizzare non più di uno o due di questi (uno sarebbe meglio):

1. Supporto tunnel IPSec sull'host virtuale o dedicato
2. tinc
3. PPTP

Poiché i nostri server che eseguono backup ecc. Potrebbero trovarsi in diversi data center, preferiremmo essere in grado di riutilizzare il nostro approccio VPN qui. Ciò sembrerebbe escludere PPTP. Il mio pensiero attuale è che IPSec probabilmente sarà migliore perché possiamo usare adattatori VPN standard, ma impostare il routing (in base alle esigenze dei clienti) sarà probabilmente molto più difficile, motivo per cui stiamo anche guardando alla tinc.

Quale di questi due è preferibile? La mia paura è che la gestione del routing sia probabilmente un forte mal di testa con IPSec ingiustificato? C'è un modo semplice per aggirare questo? Ci sono altri gotchas che mi mancano della tin (ovvero diversi dal richiedere un client separato)?

Aggiornamento in risposta alla risposta di @ Wintermute :

Sì, questa domanda è dal punto di vista del server. Il motivo è che si tratta di server effettivamente disconnessi dalle reti del client. Sì, il nostro mercato di riferimento è la rete di PMI. Sì, ci aspettiamo di utilizzare IP pubblici per ciascun server client a meno che non abbiano bisogno di qualcosa di diverso (e quindi possiamo parlare).

La soluzione a cui ci stiamo appoggiando è quella in cui i clienti definiscono i tunnel IP e le gamme di rete accessibili da quei tunnel e dove li stringiamo insieme ai nostri strumenti di gestione (che sono in fase di sviluppo), che collegano le richieste dei clienti alle modifiche di configurazione. Il problema è che poiché non è probabile che eseguiamo software di routing su vms e server, la tabella di routing deve essere gestita staticamente, quindi i clienti che commettono errori di configurazione scopriranno che le VPN non funzionano correttamente.

È anche probabile che utilizzeremo ESP sulla rete per le nostre operazioni interne (per cose come i backup). L'intera configurazione è piuttosto complessa e ha molte prospettive diverse, da server-centric (il nostro client vpn a istanza ospitata) a network-centric (cose interne), a database-centric (i nostri strumenti). Quindi non direi che la domanda è rappresentativa del nostro intero approccio (e le domande vengono poste su un sacco di siti SE).

Niente di tutto ciò influisce davvero sulla questione nel suo insieme. È forse un contesto utile però.

Non sono sicuro della tinta ma IPSEC è quasi obbligatorio. Nessuna impresa seria si fiderebbe di PPTP.

Non sono sicuro di come IPSEC influenzi il routing. Un tunnel è un tunnel è un tunnel indipendentemente dalla crittografia. Incontrerai gli stessi problemi relativamente a: dividere il tunnel o no, convincere i clienti a capire il concetto / oh guardare gli scontri IP della LAN di un particolare cliente con il pool VPN che hai scelto, ecc.

Sembra che tu stia mirando al mercato delle PMI (singoli server, accesso diretto ecc.) In modo da escludere soluzioni più sofisticate, ma elencherò comunque due possibili approcci

• una specie di concentratore VPN che consente i profili. Tutti i clienti accedono al concentratore VPN, quindi a seconda del profilo / gruppo / qualunque sia la tematica del fornitore, ottengono le autorizzazioni per utilizzare il protocollo da X a IP Y (ovvero il proprio server).

• Router virtuali Cisco ASR1000V: ogni cliente ne ottiene uno, è quindi possibile eseguire tunnel IPSEC diretti (con i VTI in modo che il routing appaia semplice) o persino indirizzare MPLS ai clienti in modo che il router appaia come un altro ramo nella loro topologia, quindi allocare i VNIC VLAN ecc. All'interno, in modo da ottenere un bel "ramo" virtuale.

• una versione in scala ridotta di quanto sopra, abbiamo usato il monowall con grande efficacia per questo scopo (cioè ogni cliente ottiene un dispositivo virtuale di livello 3 che funge da router / firewall, VPN in questo dispositivo e accesso solo alle loro VLAN) tuttavia ogni router / firewall necessita del proprio indirizzo IP pubblico.

Ri: il tuo attuale approccio, ti rendi conto che ogni server ha bisogno di un IP pubblico o hai un sistema complicato e contorto di NAT in cui il percorso VPN di ogni cliente viene assegnato una porta singola o simile.

Ti consiglierei di avere un networker a tempo pieno per esaminare qualsiasi progetto / proposta tu abbia, sembra che tu ci stia arrivando da uno sfondo del server.

Sì hai ragione. Sembra che dovrai fare i conti con indirizzi IP separati a meno che non si aggreghi tramite un concentratore VPN. TBH il concentratore è probabilmente la soluzione migliore, avrai solo bisogno di 1 IP in più per tutte le connessioni VPN, ma la sua interfaccia esterna dovrà risiedere in una sottorete / VLAN diversa dagli host IP pubblici. Vorrei andare con quello, altrimenti stai configurando IPSEC VPN direttamente su ogni singolo server, che incubo