Czy jeden interfejs WAN może obsłużyć VPN między lokalizacjami i dostęp zdalny?

Jeden publiczny adres może jednocześnie obsługiwać tunel oddziału i pulę użytkowników mobilnych. Nie może jednak obsługiwać jednej wspólnej reguły dopuszczania. Peer oddziału i użytkownik mobilny różnią się tym, za kogo się podają, jak ten dowód jest sprawdzany, jakie adresy otrzymują i które prefiksy mogą im odpowiadać. Gdy zaczniesz traktować adres zewnętrzny jako szczegół transportu, a nie tożsamość, projekt staje się znacznie prostszy.

Szybki test zdrowego rozsądku: spróbuj zapisać oba rekordy dopuszczania, zanim dotkniesz routera. Jeśli jeden warunek dopasowania musi objąć oba, polityka jest już niejednoznaczna, a pierwszy objaw będzie wyglądał na awarię routingu lub zapory, choć w rzeczywistości jest awarią tożsamości.

Dwa rekordy przed jakąkolwiek konfiguracją

Rekord oddziału jest krótki i stabilny. Wymienia adres peera lub nazwę certyfikatu, klucz współdzielony z góry lub punkt zaufania certyfikatu, chronione podsieci po obu stronach, interfejs tunelu i trasę statyczną, która kieruje ruch do oddziału do tego tunelu. Każde pole dotyczy jednego znanego peera i stałego zestawu prefiksów.

Rekord mobilny jest szerszy i bardziej osobisty. Wymienia protokół i port klienta, sposób uwierzytelniania użytkownika lub urządzenia, pulę adresów przydzielaną przy połączeniu, zasoby osiągalne z tej puli, prefiksy tunelu dzielonego, serwery DNS wypychane do klienta oraz dowolny drugi czynnik. Każde pole odpowiada na pytanie o nieznaną liczbę użytkowników, a nie o jedną bramę.

Ta różnica szczegółowości jest całym powodem rozdzielenia obu ról. Profil oddziału może bezpiecznie zaufać jednemu kluczowi, bo klucz należy do jednego urządzenia w jednej lokalizacji. Profil mobilny ufający jednemu kluczowi grupowemu dla wszystkich unicestwia odpowiedzialność na użytkownika, co zwykle odkrywa się później, podczas przeglądu incydentu, a nie podczas wdrożenia.

Gdzie rozchodzą się dopasowanie peerów i uwierzytelnianie

Na IOS XE profil IKEv2 niesie parametry, o których nie można negocjować, oraz warunki służące do wyboru peera. To oznacza, że strona oddziału i strona mobilna potrzebują każda własnego profilu, nawet gdy kończą na tym samym interfejsie i nawet gdy dzielą jedną PKI kryptograficzną. Cisco dokumentuje role profilu, uwierzytelniania i dopasowania w swoim przewodniku konfiguracji IKEv2 dla IOS XE 17.

Profil oddziału zwykle dopasowuje wąską tożsamość: adres zdalny, FQDN lub podmiot certyfikatu. Coś takiego jak match identity remote address 198.51.100.10 255.255.255.255 przypina jednego peera, a authentication remote pre-share z kluczem przechowywanym dla każdej lokalizacji wystarcza. Utrzymuj dopasowanie tak konkretne, jak pozwala inwentarz peerów, bo nakładający się wildcard wyżej w kolejności wyboru może wciągnąć ruch oddziału do niewłaściwego profilu.

Profil mobilny nie może przypiąć adresu, więc dopasowuje grupę, key-id lub pole certyfikatu, a następnie przekazuje rzeczywistą kontrolę użytkownika do AAA lub do polityki autoryzacji przypiętej do profilu. To rozdzielenie ma znaczenie: uwierzytelnianie peera odpowiada, czy klient może zbudować tunel, a autoryzacja na użytkownika odpowiada, którą pulę i jakie zasoby otrzymuje. Użycie klucza oddziału jako uniwersalnego logowania wyrzuca drugą odpowiedź.

Przekazywanie i translacja potrzebują tego samego rozdzielenia

Dopuszczanie i osiągalność to osobne problemy. Udana wymiana IKE i IPsec dowodzi, że strony zgadzają się co do kluczy; nie tworzy trasy do puli, którą otrzymał klient. Dlatego pule dostępu zdalnego potrzebują drogi powrotnej: trasy statycznej wskazującej interfejs tunelu albo protokołu routingu wstrzykującego podsumowanie puli. Prefiksy oddziału zwykle przychodzą przez ten sam proces routingu, który obsługuje resztę lokalizacji.

Translacja to miejsce, w którym obie role najczęściej się zderzają. Ruch między lokalizacjami, który musi zachować swoje adresy prywatne, potrzebuje wyjątku NAT ograniczonego do tych dwóch prefiksów, w obu kierunkach. Klienci mobilni zwykle też potrzebują wyjątku dla ruchu w tunelu, ale ich ruch do internetu albo omija tunel przez tunel dzielony, albo wychodzi w koncentratorze po NAT. Wyłączenie wszystkiego, co przychodzi z tunelu, to klasyczny błąd, bo odbiera translację także ruchowi, który naprawdę jej potrzebuje.

Utrzymuj reguły wyjątków tak wąskie jak reguły dopuszczania. Jeśli podsumowanie puli i prefiks oddziału się nakładają, droga powrotna staje się niejednoznaczna na długo przed odrzuceniem choćby jednego pakietu, a objaw wygląda jak lokalizacja, która co jakiś czas traci podsieć, a nie jak czysta awaria tunelu.

Przypadki odbiorcze, które ujawniają skrzyżowaną politykę

Zbuduj cztery przypadki i uruchom je po kolei. Host w oddziale osiąga zasób tylko dla oddziału. Klient mobilny osiąga ten sam zasób przez adres ze swojej puli. Klient mobilny próbuje prefiksu oddziału, którego nie powinien dotykać. Peer oddziału próbuje uzyskać adres z puli dostępu zdalnego. Dwa ostatnie łapią wspólny profil, bo w normalnym monitoringu zawodzą po cichu.

Potem potwierdź płaszczyznę danych, a nie konfigurację. show crypto ikev2 sa i show crypto ipsec sa mówią, który profil i które selektory niosły każdy przepływ, a show ip nat translations i liczniki tunelu pokazują, czy droga powrotna i wyjątek rzeczywiście się zgadzały. Tracer lub przechwycenie pakietów na interfejsie tunelu zamyka pętlę.

Zapisz zaobserwowaną tożsamość, adres z puli i wybraną politykę obok każdego wyniku. Przebieg jest skończony, gdy każdy przypadek odpowiada dokładnie jednemu rekordowi i żaden przypadek nie potrzebuje tymczasowego wyjątku, aby przejść.