Чи може один інтерфейс WAN обслуговувати і VPN між майданчиками, і віддалений доступ?

Одна публічна адреса може одночасно обслуговувати тунель філії та пул мобільних користувачів. Але вона не може обслуговувати одне спільне правило допуску. Партнер філії та мобільний користувач різняться тим, ким вони себе заявляють, як цей доказ перевіряється, які адреси вони отримують і які префікси можуть їм відповідати. Щойно ви починаєте ставитися до зовнішньої адреси як до деталі транспорту, а не як до особистості, проєктування стає значно простішим.

Швидкий тест на здоровий глузд: спробуйте записати обидва записи допуску, перш ніж торкатися маршрутизатора. Якщо одна умова зіставлення має покривати обидва, політика вже неоднозначна, і перший симптом виглядатиме як збій маршрутизації або міжмережевого екрана, хоча насправді це збій ідентичності.

Два записи до будь-якої конфігурації

Запис філії короткий і стабільний. Він перелічує адресу партнера або ім'я сертифіката, попередньо розділений ключ або точку довіри сертифіката, захищені підмережі з обох боків, інтерфейс тунелю та статичний маршрут, який надсилає трафік до філії в цей тунель. Кожне поле стосується одного відомого партнера та фіксованого набору префіксів.

Запис мобільного користувача ширший і особистіший. Він перелічує протокол і порт клієнта, спосіб автентифікації користувача або пристрою, пул адрес, що видається під час підключення, ресурси, доступні цьому пулу, префікси розділеного тунелю, DNS-сервери, що передаються клієнту, і будь-який другий фактор. Кожне поле відповідає на питання про невідому кількість користувачів, а не про один шлюз.

Саме ця різниця в деталізації є причиною розходження двох ролей. Профіль філії може безпечно довіряти одному ключу, бо ключ належить одному пристрою на одному майданчику. Профіль мобільності, який довіряє одному груповому ключу всім, руйнує відповідальність за користувачами, і це зазвичай виявляється пізніше, під час розбору інциденту, а не під час впровадження.

Де розходяться зіставлення партнерів і автентифікація

У IOS XE профіль IKEv2 несе параметри, про які не можна домовитися, та умови, за якими вибирається партнер. Це означає, що стороні філії та стороні мобільності потрібен кожній свій профіль, навіть коли вони завершуються на одному інтерфейсі й навіть коли вони використовують одну криптографічну PKI. Cisco описує ролі профілю, автентифікації та зіставлення у своєму посібнику з налаштування IKEv2 для IOS XE 17.

Профіль філії зазвичай зіставляється з вузькою ідентичністю: віддаленою адресою, FQDN або суб'єктом сертифіката. Щось на кшталт match identity remote address 198.51.100.10 255.255.255.255 закріплює одного партнера, а authentication remote pre-share з ключем, що зберігається для кожного майданчика, достатньо. Тримайте зіставлення настільки точним, наскільки дозволяє інвентар партнерів, бо перекривний шаблон вище в порядку вибору може втягнути трафік філії в неправильний профіль.

Профіль мобільності не може закріпити адресу, тому зіставляється з групою, key-id або полем сертифіката, а далі передає справжню перевірку користувача до AAA або до політики авторизації, прив'язаної до профілю. Це розділення важливе: автентифікація партнера відповідає, чи дозволено клієнту будувати тунель, а авторизація за користувачем відповідає, який пул і які ресурси він отримує. Використання ключа філії як універсального входу відкидає другу відповідь.

Пересилання й трансляція потребують того самого розділення

Допуск і доступність — різні задачі. Успішний обмін IKE та IPsec доводить, що сторони згодні щодо ключів; він не створює маршрут до пулу, який отримав клієнт. Тому пулам віддаленого доступу потрібен зворотний шлях: або статичний маршрут на інтерфейс тунелю, або протокол маршрутизації, що вставляє зведення пулу. Префікси філії зазвичай надходять через той самий процес маршрутизації, який обслуговує решту майданчика.

Трансляція — місце, де дві ролі найчастіше зіштовхуються. Трафіку між майданчиками, який має зберегти свої приватні адреси, потрібен виняток із NAT, обмежений цими двома префіксами, в обидва боки. Мобільним клієнтам зазвичай теж потрібен виняток для трафіку в тунелі, але їхній трафік до інтернету або обходить тунель через розділений тунель, або виходить на концентраторі після NAT. Звільняти все, що приходить із тунелю, — класична помилка, бо це позбавляє трансляції й той трафік, якому вона справді потрібна.

Тримайте правила винятків такими ж вузькими, як правила допуску. Якщо зведення пулу та префікс філії перетинаються, зворотний шлях стає неоднозначним задовго до того, як буде відкинуто бодай один пакет, і симптом виявляється як майданчик, що час від часу втрачає підмережу, а не як чистий збій тунелю.

Приймальні випадки, які викривають перехресну політику

Побудуйте чотири випадки й пройдіть їх по черзі. Хост у філії досягає ресурсу, доступного лише філії. Мобільний клієнт досягає того самого ресурсу за адресою зі свого пулу. Мобільний клієнт намагається звернутися до префікса філії, якого не має торкатися. Партнер філії намагається отримати адресу з пулу віддаленого доступу. Останні два й ловлять спільний профіль, бо за звичайного моніторингу вони відмовляють мовчки.

Потім підтвердьте площину даних, а не конфігурацію. show crypto ikev2 sa і show crypto ipsec sa показують, який профіль і які селектори несли кожен потік, а show ip nat translations і лічильники тунелю показують, чи справді збіглися зворотний шлях і виняток. Трасування або захоплення пакетів на інтерфейсі тунелю замикає цикл.

Запишіть спостережену ідентичність, адресу з пулу та обрану політику поруч із кожним результатом. Прогін завершено, коли кожен випадок відповідає рівно одному запису і жодному випадку не потрібен тимчасовий виняток, щоб пройти.