Wiele sieci LAN w jednym tunelu AWS VPN: co oznacza limit SA
AWS zezwala na jedną parę IPsec SA na tunel, i nie jest to limit jednej podsieci. Najpierw oddziel zakres ochrony od routingu i dostępu.
Dodanie drugiej sieci LAN oddziału do AWS Site-to-Site VPN nie wymaga drugiego niezależnego skojarzenia IPsec w tym tunelu. Limit, na który ludzie się potykają, jest realny, ale węższy, niż brzmi: AWS dokumentuje jedną unikalną parę IPsec SA na tunel, jedną przychodzącą i jedną wychodzącą, a dwa tunele w jednym połączeniu otrzymują każdy własną parę. To właściwość usługi, a nie reguła, że IPsec chroni jedną podsieć naraz. Rozróżnienie ma największe znaczenie, gdy brama klienta oparta na politykach zamienia każdy wpis polityki we własne skojarzenie.
Zacznij od połączenia, a nie od listy sieci LAN
Otwórz połączenie w konsoli i zwróć uwagę, jak jest routowane. Połączenie statyczne przenosi zadeklarowane przez Ciebie prefiksy zdalne. Połączenie BGP uczy się ich od bramy klienta.
Tak czy inaczej, tunel jest oparty na trasach. O tym, co do niego trafia, decydują selektory negocjowane przez urządzenie, a nie liczba podsieci, które można wpisać w formularzu.
Obserwuj, co negocjuje brama klienta
Urządzenie oparte na politykach może zamienić każdy wpis polityki we własne SA. Dwie sieci LAN oznaczają dwa wpisy, czyli dwa SA, i tu limit na tunel zaczyna mieć znaczenie. Wymagania bramy klienta ostrzegają dokładnie przed takim zachowaniem i sugerują reguły łączone na takich urządzeniach. Sprawdzaj wynegocjowane selektory, a nie liczbę reguł ACL na urządzeniu.
Urządzenie musi być skonfigurowane tak, aby prezentowało oba prefiksy w ramach jednej polityki, w przeciwnym razie druga strona po prostu nie utrzyma wyniku.
Trzy inwentarze, prowadzone osobno
Wymieszaj te trzy listy, a każda zmiana staje się zgadywaniem. Prowadź je jako osobne kolumny i wypełnij każdą dla własnej sieci.
| 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 |
Tylko środkowa kolumna jest ograniczona limitem SA. Pierwsza kolumna to fakt biznesowy, a trzecia to to, co sprawia, że aplikacja działa. Czytaj zaakceptowane selektory na urządzeniu, zamiast wnioskować o pokryciu z liczby zapisanych wierszy ACL.
Konsoliduj bez rozszerzania uprawnień
Trasa podsumowana to oczywisty sposób na uzyskanie jednego wpisu polityki, a zarazem sposób, w jaki chroniony zbiór cicho rośnie. /20 obejmujący obie /24 obejmuje także adresy, których nie używa żaden oddział, a tunel chętnie je przeniesie. Jeśli musisz podsumować, połącz to z filtrowaniem po stronie odbiorcy, aby dodatkowa przestrzeń była odrzucana, a nie tylko nieogłaszana. Odrzucony pakiet jest dowodem. Nieogłoszony adres to tylko brak dowodu.
Konsolidacja polityki ochrony to zmiana tego, co może być szyfrowane. Nie jest to nadanie dostępu i nie należy tego tak traktować.
Przetestuj obie sieci LAN, a następnie zachowaj oba tunele
Po skoordynowanej zmianie sprawdź aktywny zakres ochrony, a następnie uruchom rzeczywistą aplikację z każdej sieci LAN. Działanie jednej podsieci niczego nie dowodzi o pokryciu selektorów drugiej, a jeszcze mniej o jej ścieżce odpowiedzi.
Zachowaj oba tunele w projekcie. Konsolidacja polityki nie jest zgodą na odrzucenie nadmiarowości, a jeden tunel przenoszący każdą sieć LAN oddziału zamienia następne okno serwisowe w awarię.
Zapisz wynegocjowane selektory, oba prefiksy i właścicieli tras w tym samym rekordzie zmiany. Gdy pojawi się trzecia sieć LAN, ten rekord powie Ci, czy dodajesz selektor, czy zaczynasz od nowa.