Aggiungere una seconda LAN di filiale a una VPN site-to-site AWS non richiede una seconda associazione IPsec indipendente all'interno di quel tunnel. Il limite su cui le persone inciampano è reale ma più stretto di quanto sembri: AWS documenta una coppia IPsec SA univoca per tunnel, una in ingresso e una in uscita, e i due tunnel di una connessione ricevono ciascuno la propria coppia. È una proprietà del servizio, non una regola secondo cui IPsec protegge una sottorete alla volta. La distinzione conta soprattutto quando un gateway client basato su policy trasforma ogni voce di policy in una propria associazione.

Partite dalla connessione, non dall'elenco delle LAN

Aprite la connessione nella console e notate come viene instradata. Una connessione statica trasporta i prefissi remoti che avete dichiarato. Una connessione BGP li apprende dal gateway client.

In ogni caso, il tunnel è basato sull'instradamento. Ciò che vi entra è deciso dai selettori negoziati dal dispositivo, non dal numero di sottoreti che potete digitare in un modulo.

Osservate cosa negozia il gateway client

Un dispositivo basato su policy può trasformare ogni voce di policy in una propria SA. Due LAN significano due voci, quindi due SA, ed è qui che il limite per tunnel inizia a contare. Requisiti del gateway client avvertono esattamente di questo comportamento e suggeriscono regole consolidate su quei dispositivi. Verificate i selettori negoziati anziché il conteggio delle ACL sul dispositivo.

Il dispositivo deve essere configurato per presentare entrambi i prefissi sotto un'unica policy, altrimenti l'estremità remota semplicemente non può mantenere il risultato.

Tre inventari, tenuti separati

Mescolate questi tre elenchi e ogni modifica diventa una congettura. Teneteli come colonne separate e compilate ciascuna per la vostra rete.

InventoryWhat belongs there
Required networks10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation
Protection agreementthe selectors the tunnel actually negotiated for those prefixes
Delivery and permissionVPC routes, return routes, security groups and any filtering

Solo la colonna centrale è vincolata dal limite SA. La prima colonna è un fatto aziendale, e la terza è ciò che fa funzionare un'applicazione. Leggete i selettori accettati sul dispositivo invece di dedurre la copertura dal numero di righe ACL che avete scritto.

Consolidate senza ampliare l'autorizzazione

Una rotta riepilogata è il modo ovvio per ottenere un'unica voce di policy, ed è anche il modo in cui un insieme protetto cresce silenziosamente. Un /20 che copre entrambe le /24 copre anche indirizzi che nessuna delle due filiali usa, e il tunnel li trasporterà volentieri. Se dovete riepilogare, abbinatelo a un filtraggio sul lato ricevente così lo spazio extra viene rifiutato anziché semplicemente non annunciato. Un pacchetto rifiutato è una prova. Un indirizzo non annunciato è solo un'assenza di prova.

Consolidare la policy di protezione è un cambiamento in ciò che può essere cifrato. Non è una concessione di accesso e non va trattata come tale.

Provate entrambe le LAN, poi mantenete entrambi i tunnel

Dopo una modifica coordinata, ispezionate il perimetro di protezione attivo e poi eseguite un'applicazione reale da ciascuna LAN. Il funzionamento di una sottorete non dimostra nulla sulla copertura dei selettori della seconda, e ancor meno sul suo percorso di risposta.

Mantenete entrambi i tunnel nel progetto. Consolidare la policy non è un permesso per scartare la ridondanza, e un solo tunnel che trasporta ogni LAN di filiale rende la prossima finestra di manutenzione un'interruzione.

Scrivete i selettori negoziati, i due prefissi e i proprietari delle rotte nello stesso registro delle modifiche. Quando arriva una terza LAN, quel registro vi dice se state aggiungendo un selettore o ricominciando da capo.

Articoli correlati