Може ли един 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 и броячите на тунела показват дали обратният път и изключението наистина са съвпаднали. Трасето или снемането на пакети на интерфейса на тунела затваря цикъла.

Запишете наблюдаваната идентичност, адреса от пула и избраната политика до всеки резултат. Пробегът е завършен, когато всеки случай съответства на точно един запис и нито един случай не се нуждае от временно изключение, за да мине.