Fleire LAN på éin AWS VPN-tunnel: kva SA-grensa inneber
AWS tillèt eitt IPsec SA-par per tunnel, og det er ikkje ei grense på eitt subnett. Skil først verneomfanget frå ruting og tilgang.
Å leggje til eit andre filial-LAN i ein AWS Site-to-Site VPN krev ikkje ei andre sjølvstendig IPsec-tilknyting inne i den tunnelen. Grensa folk snublar i, er reell, men snevrare enn ho høyrest ut: AWS dokumenterer eitt unikt IPsec SA-par per tunnel, eitt inngåande og eitt utgåande, og dei to tunnelane i éi tilkopling får kvar sitt par. Det er ein eigenskap ved tenesta, ikkje ei regel om at IPsec vernar eitt subnett om gongen. Skilnaden betyr mest når ein policybasert kundegateway gjer kvar policyoppføring til si eiga tilknyting.
Start med tilkoplinga, ikkje med LAN-lista
Opne tilkoplinga i konsollen og legg merke til korleis ho blir ruta. Ei statisk tilkopling ber fjernprefiksa du deklarerte. Ei BGP-tilkopling lærer dei frå kundegatewayen.
Uansett er tunnelen rutebasert. Kva som går inn i han, blir avgjort av selektorane eininga di forhandlar, ikkje av talet på subnett du kan skrive i eit skjema.
Følg med på kva kundegatewayen forhandlar
Ei policybasert eining kan gjere kvar policyoppføring til sin eigen SA. To LAN betyr to oppføringar, som betyr to SA-ar, og det er der grensa per tunnel byrjar å bety noko. Krava til kundegatewayen åtvara nettopp om denne åtferda og føreslår konsoliderte reglar på slike einingar. Kontroller dei forhandla selektorane i staden for talet på ACL-ar på boksen.
Eininga må konfigurerast til å presentere begge prefiksa under éin enkelt policy, elles kan den fjerne enden rett og slett ikkje halde resultatet.
Tre oversyn, haldne åtskilde
Bland desse tre listene, og kvar endring blir gjetting. Hald dei som separate kolonnar og fyll ut kvar for ditt eige 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 |
Berre den midterste kolonnen er avgrensa av SA-grensa. Den første kolonnen er eit forretningsfaktum, og den tredje er det som får ein applikasjon til å fungere. Les dei aksepterte selektorane på eininga i staden for å utleie dekning frå talet på ACL-linjer du skreiv.
Konsolider utan å utvide tillatinga
Ei oppsummert rute er den openberre måten å få éi policyoppføring på, og det er også slik eit verna sett stille veks. Eit /20 som dekkjer båe /24-ane, dekkjer også adresser ingen av filialane brukar, og tunnelen ber dei gjerne. Viss du må oppsummere, kople det til filtrering på mottakarsida slik at den ekstra plassen blir avvist i staden for berre ikkje annonsert. Ei avvist pakke er prov. Ei ikkje-annonsert adresse er berre fråvær av prov.
Å konsolidere vernepolitikken er ei endring av kva som kan krypterast. Det er ikkje ei tildeling av tilgang og bør ikkje behandlast som det.
Test båe LAN og hald deretter båe tunnelane
Etter ei koordinert endring, inspiser det aktive verneomfanget og øv deretter på ein ekte applikasjon frå kvar LAN. At eitt subnett virkar provar ingenting om selektordekninga til det andre, og endå mindre om svarvegen hans.
Hald båe tunnelane i designet. Å konsolidere policy er ikkje løyve til å kaste redundans, og éin tunnel som ber kvar filial-LAN gjer neste vedlikehaldsvindauge til eit avbrot.
Skriv dei forhandla selektorane, dei to prefiksa og ruteeigarane inn i den same endringsoppføringa. Når eit tredje LAN kjem, fortel den oppføringa deg om du legg til ein selektor eller startar på nytt.