Ці можа адзін інтэрфейс 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 і лічыльнікі тунеля пакажуць, ці сапраўды супалі зваротны шлях і вызваленне. Трасоўка або захоп пакетаў на інтэрфейсе тунеля замыкае цыкл.

Запішыце назіраную ідэнтычнасць, адрас пула і выбрану палітыку побач з кожным вынікам. Прабег скончаны, калі кожны выпадак адпавядае роўна аднаму запісу і ніводзін выпадак не патрабуе часовага выключэння, каб прайсці.