Flere LAN på én AWS VPN-tunnel: hvad SA-grænsen betyder
AWS tillader ét IPsec SA-par pr. tunnel, og det er ikke en grænse på ét subnet. Adskil først beskyttelsesomfanget fra routing og adgang.
At tilføje et andet filial-LAN til en AWS Site-to-Site VPN kræver ikke en anden uafhængig IPsec-association inde i den tunnel. Grænsen, som folk snubler over, er reel, men snævrere, end den lyder: AWS dokumenterer ét unikt IPsec SA-par pr. tunnel, én indgående og én udgående, og de to tunneler i en forbindelse får hver deres par. Det er en egenskab ved tjenesten, ikke en regel om, at IPsec beskytter ét subnet ad gangen. Forskellen betyder mest, når en policybaseret kundegateway gør hver policy-post til sin egen association.
Start med forbindelsen, ikke med LAN-listen
Åbn forbindelsen i konsollen, og læg mærke til, hvordan den routes. En statisk forbindelse bærer de fjernpræfikser, du har erklæret. En BGP-forbindelse lærer dem fra kundegatewayen.
Uanset hvad er tunnelen rutebaseret. Hvad der kommer ind i den, afgøres af de selectors, din enhed forhandler, ikke af antallet af subnets, du kan skrive i en formular.
Hold øje med, hvad kundegatewayen forhandler
En policybaseret enhed kan gøre hver policy-post til sin egen SA. To LAN betyder to poster, hvilket betyder to SA'er, og det er der, grænsen pr. tunnel begynder at betyde noget. Kravene til kundegatewayen advarer netop om denne adfærd og foreslår konsoliderede regler på disse enheder. Kontroller de forhandlede selectors i stedet for antallet af ACL'er på boksen.
Enheden skal konfigureres til at præsentere begge præfikser under én enkelt policy, ellers kan den fjerne ende simpelthen ikke holde resultatet.
Tre oversigter, holdt adskilt
Bland disse tre lister, og enhver ændring bliver gætteri. Hold dem som separate kolonner, og udfyld hver af dem for dit eget netværk.
| 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 |
Kun den midterste kolonne er begrænset af SA-grænsen. Den første kolonne er en forretningsmæssig kendsgerning, og den tredje kolonne er det, der får en applikation til at virke. Læs de accepterede selectors på enheden i stedet for at udlede dækning af antallet af ACL-linjer, du har skrevet.
Konsolidér uden at udvide tilladelsen
En summeret rute er den indlysende måde at få én policy-post på, og det er også sådan et beskyttet sæt stille vokser. Et /20, der dækker begge /24, dækker også adresser, som ingen af filialerne bruger, og tunnelen bærer dem gerne. Hvis du må opsummere, skal du parre det med filtrering på modtagersiden, så den ekstra plads afvises i stedet for blot ikke at blive annonceret. En afvist pakke er bevis. En ikke-annonceret adresse er kun fravær af bevis.
At konsolidere beskyttelsespolitikken er en ændring af, hvad der må krypteres. Det er ikke en tildeling af adgang og bør ikke behandles som en.
Test begge LAN, og behold derefter begge tunneler
Efter en koordineret ændring undersøges det aktive beskyttelsesomfang, og derefter afprøves en rigtig applikation fra hvert LAN. At ét subnet virker beviser intet om det andets selector-dækning, og endnu mindre om dets svarvej.
Behold begge tunneler i designet. At konsolidere politik er ikke tilladelse til at kassere redundans, og en enkelt tunnel, der bærer hvert filial-LAN, gør det næste vedligeholdelsesvindue til et udfald.
Skriv de forhandlede selectors, de to præfikser og ruteejerne ind i den samme ændringspost. Når et tredje LAN dukker op, fortæller den post dig, om du tilføjer en selector eller starter forfra.