Flera LAN på en enda AWS VPN-tunnel: vad SA-gränsen innebär
AWS tillåter ett IPsec SA-par per tunnel, och det är inte en gräns för ett enda subnät. Skilj först skyddsomfattningen från routing och åtkomst.
Att lägga till ett andra filial-LAN i en AWS Site-to-Site VPN kräver inte en andra oberoende IPsec-association inuti den tunneln. Gränsen folk snubblar på är verklig men snävare än den låter: AWS dokumenterar ett unikt IPsec SA-par per tunnel, ett inkommande och ett utgående, och de två tunnlarna i en anslutning får var sitt par. Det är en egenskap hos tjänsten, inte en regel att IPsec skyddar ett subnät åt gången. Skillnaden spelar störst roll när en policybaserad kundgateway gör varje policypost till sin egen association.
Börja med anslutningen, inte med LAN-listan
Öppna anslutningen i konsolen och notera hur den routas. En statisk anslutning bär de fjärrprefix du deklarerade. En BGP-anslutning lär sig dem från kundgatewayen.
Hur som helst är tunneln rutbaserad. Vad som går in i den avgörs av de selektorer din enhet förhandlar, inte av antalet subnät du kan skriva i ett formulär.
Håll koll på vad kundgatewayen förhandlar
En policybaserad enhet kan göra varje policypost till sin egen SA. Två LAN betyder två poster, vilket betyder två SA, och det är där gränsen per tunnel börjar spela roll. Kraven på kundgatewayen varnar just för detta beteende och föreslår konsoliderade regler på sådana enheter. Kontrollera de förhandlade selektorerna i stället för antalet ACL:er på enheten.
Enheten måste konfigureras att presentera båda prefixen under en enda policy, annars kan den bortre änden helt enkelt inte hålla resultatet.
Tre inventeringar, hållna isär
Blanda dessa tre listor och varje ändring blir gissning. Håll dem som separata kolumner och fyll i var och en för ditt eget nätverk.
| 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 |
Bara den mellersta kolumnen begränsas av SA-gränsen. Den första kolumnen är ett affärsfaktum, och den tredje är det som får en applikation att fungera. Läs de accepterade selektorerna på enheten i stället för att härleda täckning från antalet ACL-rader du skrev.
Konsolidera utan att utöka tillståndet
En sammanfattad rutt är det uppenbara sättet att få en enda policy-post, och det är också så en skyddad mängd tyst växer. Ett /20 som täcker båda /24 täcker också adresser som ingen av filialerna använder, och tunneln bär dem gärna. Om du måste sammanfatta, koppla det till filtrering på mottagarsidan så att det extra utrymmet avvisas i stället för att bara inte annonseras. Ett avvisat paket är bevis. En icke-annonserad adress är bara frånvaro av bevis.
Att konsolidera skyddspolicyn är en ändring av vad som får krypteras. Det är inte ett beviljande av åtkomst och bör inte behandlas som ett.
Testa båda LAN och behåll sedan båda tunnlarna
Efter en samordnad ändring, inspektera skyddsomfattningen och kör sedan en riktig applikation från varje LAN. Att ett subnät fungerar bevisar ingenting om det andras selektortäckning, och ännu mindre om dess svarsväg.
Behåll båda tunnlarna i designen. Att konsolidera policy är inte tillstånd att kasta redundans, och en enda tunnel som bär varje filial-LAN gör nästa underhållsfönster till ett avbrott.
Skriv de förhandlade selektorerna, de två prefixen och ruttägarna i samma ändringspost. När ett tredje LAN kommer berättar den posten om du lägger till en selektor eller börjar om.