Mehrere LANs an einem AWS-VPN-Tunnel: Was das SA-Limit bedeutet

Ein zweites Zweigstellen-LAN an einer AWS-Site-to-Site-VPN-Verbindung hinzuzufügen erfordert keine zweite unabhängige IPsec-Assoziation innerhalb dieses Tunnels. Die Grenze, über die Leute stolpern, ist real, aber enger, als es klingt: AWS dokumentiert ein einzigartiges IPsec-SA-Paar pro Tunnel, eines eingehend und eines ausgehend, und die beiden Tunnel einer Verbindung erhalten jeweils ihr eigenes Paar. Das ist eine Eigenschaft des Dienstes, keine Regel, dass IPsec jeweils nur ein Subnetz schützt. Die Unterscheidung ist am wichtigsten, wenn ein richtlinienbasiertes Customer Gateway jeden Richtlinieneintrag in eine eigene Assoziation verwandelt.

Beginnen Sie mit der Verbindung, nicht mit der LAN-Liste

Öffnen Sie die Verbindung in der Konsole und prüfen Sie, wie sie geroutet wird. Eine statische Verbindung trägt die von Ihnen angegebenen Remote-Präfixe. Eine BGP-Verbindung lernt sie vom Customer Gateway.

So oder so ist der Tunnel routenbasiert. Was in ihn hineingeht, entscheiden die Selektoren, die Ihr Gerät aushandelt, nicht die Anzahl der Subnetze, die Sie in ein Formular eintippen können.

Achten Sie darauf, was das Customer Gateway aushandelt

Ein richtlinienbasiertes Gerät kann jeden Richtlinieneintrag in eine eigene SA verwandeln. Zwei LANs bedeuten zwei Einträge, das bedeutet zwei SAs, und dort beginnt das Limit pro Tunnel zu greifen. Die Anforderungen an das Customer Gateway warnen genau vor diesem Verhalten und schlagen konsolidierte Regeln auf diesen Geräten vor. Prüfen Sie die ausgehandelten Selektoren statt der ACL-Anzahl auf dem Gerät.

Das Gerät muss so konfiguriert sein, dass es beide Präfixe unter einer einzigen Richtlinie präsentiert, sonst kann die Gegenseite das Ergebnis schlicht nicht halten.

Drei Inventare, getrennt gehalten

Mischen Sie diese drei Listen, und jede Änderung wird zum Rätselraten. Halten Sie sie als separate Spalten und füllen Sie jede für Ihr eigenes Netzwerk aus.

Nur die mittlere Spalte ist durch das SA-Limit eingeschränkt. Die erste Spalte ist eine geschäftliche Tatsache, und die dritte Spalte ist das, was eine Anwendung funktionieren lässt. Lesen Sie die akzeptierten Selektoren auf dem Gerät, statt die Abdeckung aus der Anzahl der von Ihnen geschriebenen ACL-Zeilen abzuleiten.

Konsolidieren, ohne die Berechtigung zu erweitern

Eine Summary-Route ist der naheliegende Weg zu einem einzigen Richtlinieneintrag, und sie ist auch der Weg, auf dem eine geschützte Menge still wächst. Ein /20, das beide /24 abdeckt, deckt auch Adressen ab, die keine der beiden Zweigstellen nutzt, und der Tunnel wird sie bereitwillig tragen. Wenn Sie zusammenfassen müssen, kombinieren Sie es mit Filterung auf der Empfängerseite, damit der zusätzliche Raum abgelehnt und nicht bloß nicht angekündigt wird. Ein abgelehntes Paket ist ein Beweis. Eine nicht angekündigte Adresse ist nur die Abwesenheit eines Beweises.

Die Schutzrichtlinie zu konsolidieren ist eine Änderung dessen, was verschlüsselt werden darf. Es ist keine Gewährung von Zugriff und sollte auch nicht als solche behandelt werden.

Testen Sie beide LANs und behalten Sie dann beide Tunnel

Prüfen Sie nach einer koordinierten Änderung den aktiven Schutzbereich und führen Sie dann eine echte Anwendung von jedem LAN aus. Ein funktionierendes Subnetz beweist nichts über die Selektorabdeckung des zweiten und noch weniger über dessen Antwortpfad.

Behalten Sie beide Tunnel im Design. Eine konsolidierte Richtlinie ist keine Erlaubnis, Redundanz zu verwerfen, und ein einzelner Tunnel, der jedes Zweigstellen-LAN trägt, macht das nächste Wartungsfenster zum Ausfall.

Schreiben Sie die ausgehandelten Selektoren, die beiden Präfixe und die Routenverantwortlichen in denselben Änderungsdatensatz. Wenn ein drittes LAN hinzukommt, sagt Ihnen dieser Datensatz, ob Sie einen Selektor hinzufügen oder von vorn beginnen.