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

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