Collega le tue sedi. Lavora senza distanze.

Sì. È una funzionalità Cloud inclusa nel Virtual Private Cloud Netsons. Per utilizzarla occorre configurare il collegamento con il gateway della sede, le reti da raggiungere e le relative regole di accesso.

Servono un router virtuale collegato alle subnet Netsons, un gateway remoto compatibile IPsec/IKE con IPv4 pubblico raggiungibile e gli intervalli CIDR delle reti da collegare.

Prepariamo inoltre le policy concordate e la chiave PSK.

Il servizio documentato utilizza IPsec per il tunnel e IKEv1 o IKEv2 per la negoziazione.

La configurazione descritta in questa pagina riguarda questi protocolli; OpenVPN e WireGuard richiedono una soluzione differente.

Sì, con IKEv2. Le subnet si inseriscono negli endpoint group locali e remoti; sul gateway della sede devono essere configurate le reti corrispondenti.

IKEv1 presenta il limite della singola subnet remota.

Gli intervalli IP delle reti collegate devono essere distinti. In presenza di sovrapposizioni occorre rivedere il piano di indirizzamento prima dell’attivazione.

La configurazione utilizza una pre-shared key, o PSK, condivisa tra i due estremi. Inserisci la stessa chiave sui gateway e verifica il peer ID; condividi il segreto solo tramite un canale sicuro.

Le policy IKE e IPsec definiscono algoritmi, gruppi Diffie-Hellman e lifetime. Concorda valori compatibili sui due gateway; imposta una durata IKE superiore a quella IPsec come richiesto dalla procedura di configurazione.

Dead Peer Detection verifica la risposta del peer remoto. Puoi configurare intervallo, timeout e azione, come mantenere lo stato, rimuovere la connessione o tentare il riavvio.

Il controllo riguarda il peer; la disponibilità delle applicazioni richiede verifiche separate.

Questo servizio collega reti tramite gateway, con topologia Site-to-Site. Per collegare un singolo dispositivo serve una soluzione di accesso remoto Point-to-Site, da valutare separatamente.

Sì, se può operare come gateway IPsec/IKE con i parametri concordati. Invia modello e versione firmware: verifichiamo algoritmi, PSK, subnet e raggiungibilità del peer prima di confermare la configurazione.

Sì: le applicazioni delle subnet collegate si raggiungono tramite IP privati. Il gateway espone l’endpoint pubblico del tunnel.

Rotte e firewall devono consentire il traffico previsto in entrambe le direzioni.

Il throughput dipende da collegamento Internet della sede, gateway, cifratura, latenza e dimensione dei pacchetti.

Banda e SLA applicabili si verificano nell’offerta; per dimensionare il servizio servono traffico atteso e caratteristiche del gateway.

Dopo la creazione il tunnel diventa attivo quando anche il gateway remoto è configurato e la negoziazione IKE riesce.

Controlla IP del peer, PSK, policy e subnet sui due lati, oltre alla raggiungibilità dei gateway.

Sì, se la rete remota dispone di un gateway IPsec/IKE compatibile e di subnet distinte.

Occorre concordare le configurazioni con chi gestisce l’altro estremo e verificare le regole di accesso su entrambi i lati.

Le API di rete prevedono creazione e aggiornamento delle connessioni IPsec, con policy, endpoint group e parametri DPD.

Servono credenziali e autorizzazioni del progetto; l’accesso operativo va concordato in fase di attivazione.

Indica sedi da collegare, subnet CIDR, modello e firmware dei gateway, IP pubblici, applicazioni e traffico previsto.

Aggiungi i referenti tecnici dei due estremi: questi dati permettono di verificare compatibilità, attività e condizioni economiche.