Come scegliere i gateway VPN tra sedi che interoperano

Due gateway di sede di fornitori diversi formeranno un tunnel se le loro implementazioni concordano sui parametri che vengono negoziati. Marchi identici non sono un requisito, e marchi corrispondenti non sono nemmeno una garanzia. La questione della compatibilità riguarda funzioni e versioni; la questione della capacità riguarda il lavoro che il dispositivo deve svolgere nel software. Trattatele come due verifiche, esattamente in quest’ordine.

Percorrete l’elenco e fermatevi al primo punto che non ha risposta.

Partite dalle funzioni del protocollo, non dal marchio

Per il protocollo che intendete eseguire, elencate ciò che serve al progetto: il metodo di autenticazione, le proposte di cifratura e integrità concordate, l’interfaccia o la costruzione di traffico protetto, la modalità di routing e se uno dei due lati si trova dietro NAT. Ognuna è una funzione che l’implementazione deve supportare, non una casella in una pagina di prodotto.

I requisiti di gateway cliente di AWS sono un modello utile anche se non vi collegate ad AWS, perché enunciano il contratto come un insieme di obblighi di protocollo e di routing. Un file di esempio del fornitore per un modello specifico è una prova discreta che qualcuno ha testato quella combinazione. Un’etichetta generica che dichiara supporto IPsec non dimostra né la versione né il modello di politica. Leggete le note di rilascio invece del riassunto di marketing.

Verificate la versione, non l’etichetta sulla scheda tecnica

L’interoperabilità di IKEv2 è decisa dai parametri negoziati, quindi la domanda è quali proposte il firmware attuale offre e accetta. Un dispositivo che supporta il protocollo in generale può comunque rifiutare la combinazione precisa che l’altro capo pretende. Confermate la stringa di versione e l’elenco delle proposte su entrambi i lati.

Una nota che una funzione è arrivata in una successiva serie di firmware è abbastanza comune da meritare un proprio punto nella lista di controllo.

Trattate la capacità come una questione separata

La cifratura costa lavoro, e quanto dipende dall’implementazione tanto quanto dall’algoritmo. Alcuni percorsi di accelerazione valgono solo per determinati algoritmi o determinati percorsi di inoltro, quindi un dispositivo può essere veloce in una configurazione e lento in un’altra. La velocità normale di una WAN non è la velocità di un tunnel cifrato. Dimensionate il dispositivo sul traffico che proteggerete davvero.

Anche la dimensione dei pacchetti conta, perché l’incapsulamento e ogni ulteriore sovraccarico riducono il carico utile che ogni pacchetto trasporta.

Decidete la politica di routing in modo esplicito

Tra sedi non significa che solo il traffico selezionato possa usare il tunnel, né che tutto debba. Un progetto può trasportare prefissi privati specifici, oppure instradare una rotta predefinita attraverso il gateway. Sceglietene una e scrivetela, perché entrambi i lati devono concordare su ciò che viene annunciato e ciò che viene accettato. Un disallineamento qui produce un tunnel che è su e una rete che è a metà raggiungibile.

I progetti con routing dinamico aggiungono un altro requisito: supporto del protocollo di routing alle due estremità.

Cosa confrontare prima di comprare

Confrontate la cadenza degli aggiornamenti, le prove di interoperabilità, il ripristino della configurazione e il comportamento di commutazione previsto accanto alla velocità di punta del trasferimento. Chiedete cosa succede quando il dispositivo si riavvia con una configurazione obsoleta. Chiedete se il fornitore pubblica un elenco di interoperabilità per il peer esatto che pensate di usare. Chiedete a chi appartiene il cambiamento quando un aggiornamento del firmware altera una proposta predefinita.

Una garanzia hardware non risponde a nessuna di queste domande.

Poi provate la coppia prima di impegnarvi su una flotta. Un tunnel, le proposte reali, la modalità di routing reale e un trasferimento simile al carico di lavoro vi diranno più di qualsiasi tabella di specifiche.