Flere LAN på én AWS VPN-tunnel: hva SA-grensen innebærer
AWS tillater ett IPsec SA-par per tunnel, og det er ikke en grense på ett subnett. Skill først beskyttelsesomfanget fra ruting og tilgang.
Å legge til et andre filial-LAN i en AWS Site-to-Site VPN krever ikke en andre uavhengig IPsec-tilknytning inne i den tunnelen. Grensen folk snubler i, er reell, men snevrere enn den høres ut: AWS dokumenterer ett unikt IPsec SA-par per tunnel, ett inngående og ett utgående, og de to tunnelene i én tilkobling får hver sitt par. Det er en egenskap ved tjenesten, ikke en regel om at IPsec beskytter ett subnett om gangen. Forskjellen betyr mest når en policybasert kundegateway gjør hver policyoppføring til sin egen tilknytning.
Start med tilkoblingen, ikke med LAN-listen
Åpne tilkoblingen i konsollen og legg merke til hvordan den rutes. En statisk tilkobling bærer fjernprefiksene du deklarerte. En BGP-tilkobling lærer dem fra kundegatewayen.
Uansett er tunnelen rutebasert. Hva som går inn i den, avgjøres av selektorene enheten din forhandler, ikke av antallet subnett du kan skrive i et skjema.
Følg med på hva kundegatewayen forhandler
En policybasert enhet kan gjøre hver policyoppføring til sin egen SA. To LAN betyr to oppføringer, som betyr to SA-er, og det er der grensen per tunnel begynner å bety noe. Kravene til kundegatewayen advarer nettopp om denne atferden og foreslår konsoliderte regler på slike enheter. Kontroller de forhandlede selektorene i stedet for antallet ACL-er på boksen.
Enheten må konfigureres til å presentere begge prefiksene under én enkelt policy, ellers kan den fjerne enden rett og slett ikke holde resultatet.
Tre oversikter, holdt atskilt
Bland disse tre listene, og enhver endring blir gjetning. Hold dem som separate kolonner og fyll ut hver for ditt eget nettverk.
| 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 |
Bare den midterste kolonnen er begrenset av SA-grensen. Den første kolonnen er et forretningsfaktum, og den tredje er det som får en applikasjon til å fungere. Les de aksepterte selektorene på enheten i stedet for å utlede dekning fra antallet ACL-linjer du skrev.
Konsolider uten å utvide tillatelsen
En oppsummert rute er den åpenbare måten å få én policyoppføring på, og det er også slik et beskyttet sett stille vokser. Et /20 som dekker begge /24-ene, dekker også adresser ingen av filialene bruker, og tunnelen bærer dem gjerne. Hvis du må oppsummere, koble det til filtrering på mottakersiden slik at den ekstra plassen avvises i stedet for bare ikke annonseres. En avvist pakke er bevis. En ikke-annonsert adresse er bare fravær av bevis.
Å konsolidere beskyttelsespolitikken er en endring av hva som kan krypteres. Det er ikke en tildeling av tilgang og bør ikke behandles som en.
Test begge LAN og behold deretter begge tunnelene
Etter en koordinert endring, inspiser det aktive beskyttelsesomfanget og øv deretter på en ekte applikasjon fra hvert LAN. At ett subnett virker beviser ingenting om det andres selektordekning, og enda mindre om dets svarvei.
Behold begge tunnelene i designet. Å konsolidere policy er ikke tillatelse til å kaste redundans, og én tunnel som bærer hvert filial-LAN gjør neste vedlikeholdsvindu til et avbrudd.
Skriv de forhandlede selektorene, de to prefiksene og ruteeierne inn i samme endringsoppføring. Når et tredje LAN kommer, forteller den oppføringen deg om du legger til en selektor eller starter på nytt.