Meerdere LAN's op één AWS VPN-tunnel: wat de SA-limiet betekent
AWS staat één IPsec SA-paar per tunnel toe, en dat is geen limiet van één subnet. Scheid eerst de beschermingsscope van routing en toegang.
Een tweede vestigings-LAN toevoegen aan een AWS Site-to-Site VPN vereist geen tweede onafhankelijke IPsec-associatie in die tunnel. De limiet waar mensen over struikelen is echt, maar smaller dan het klinkt: AWS documenteert één uniek IPsec SA-paar per tunnel, één inkomend en één uitgaand, en de twee tunnels in één verbinding krijgen elk hun eigen paar. Dat is een eigenschap van de dienst, geen regel dat IPsec één subnet tegelijk beschermt. Het onderscheid is het belangrijkst wanneer een op beleid gebaseerde klantgateway elke beleidsvermelding in een eigen associatie verandert.
Begin bij de verbinding, niet bij de LAN-lijst
Open de verbinding in de console en let op hoe deze wordt gerouteerd. Een statische verbinding draagt de externe prefixen die u hebt opgegeven. Een BGP-verbinding leert ze van de klantgateway.
Hoe dan ook, de tunnel is routegebaseerd. Wat erin gaat, wordt bepaald door de selectors die uw apparaat onderhandelt, niet door het aantal subnetten dat u in een formulier kunt typen.
Let op wat de klantgateway onderhandelt
Een op beleid gebaseerd apparaat kan elke beleidsvermelding in een eigen SA veranderen. Twee LAN's betekenen twee vermeldingen, wat twee SA's betekent, en daar begint de limiet per tunnel te tellen. De eisen van de klantgateway waarschuwen precies voor dit gedrag en stellen geconsolideerde regels voor op die apparaten. Controleer de onderhandelde selectors in plaats van het aantal ACL's op het apparaat.
Het apparaat moet zo worden geconfigureerd dat het beide prefixen onder één beleid presenteert, anders kan de andere kant het resultaat simpelweg niet vasthouden.
Drie inventarissen, apart gehouden
Meng deze drie lijsten en elke wijziging wordt giswerk. Houd ze als aparte kolommen en vul elke in voor uw eigen netwerk.
| Inventory | What belongs there |
|---|---|
| Required networks | 10.20.10.0/24 and 10.20.30.0/24, as presented after any deliberate translation |
| Protection agreement | the selectors the tunnel actually negotiated for those prefixes |
| Delivery and permission | VPC routes, return routes, security groups and any filtering |
Alleen de middelste kolom wordt beperkt door de SA-limiet. De eerste kolom is een zakelijk feit, en de derde is wat een applicatie laat werken. Lees de geaccepteerde selectors op het apparaat in plaats van dekking af te leiden uit het aantal ACL-regels dat u hebt geschreven.
Consolideer zonder de toestemming te verruimen
Een samengevatte route is de voor de hand liggende manier om één beleidsvermelding te krijgen, en het is ook hoe een beschermde set stilletjes groeit. Een /20 die beide /24's dekt, dekt ook adressen die geen van beide vestigingen gebruikt, en de tunnel draagt ze graag. Als u moet samenvatten, koppel het dan aan filtering aan de ontvangende kant zodat de extra ruimte wordt geweigerd in plaats van alleen niet aangekondigd. Een geweigerd pakket is bewijs. Een niet-aangekondigd adres is alleen een afwezigheid van bewijs.
Het consolideren van het beschermingsbeleid is een wijziging van wat mag worden versleuteld. Het is geen verlening van toegang en moet niet als zodanig worden behandeld.
Test beide LAN's en houd dan beide tunnels
Na een gecoördineerde wijziging inspecteert u de actieve beschermingsscope en oefent u vervolgens een echte applicatie vanaf elk LAN. Dat één subnet werkt bewijst niets over de selectordekking van het tweede, en nog minder over het antwoordpad ervan.
Houd beide tunnels in het ontwerp. Beleid consolideren is geen toestemming om redundantie weg te gooien, en één tunnel die elk vestigings-LAN draagt maakt het volgende onderhoudsvenster tot een storing.
Schrijf de onderhandelde selectors, de twee prefixen en de route-eigenaren in hetzelfde wijzigingsrecord. Wanneer een derde LAN komt, vertelt dat record u of u een selector toevoegt of opnieuw begint.