Кой VRF достига до партньора по VPN и кой носи пакета?

Всеки тунел в контекста за маршрутизация на клиент все още трябва да достигне до отдалечения си партньор и това търсене може да се случи в напълно друга таблица. Грешката тук поражда една от най-объркващите повреди в IPsec с поддръжка на VRF: тунелът се вдига, маршрутите изглеждат налични, а трафикът умира, защото едно от двете търсения е използвало грешен контекст. Изпълнете четирите стъпки по-долу по ред и запишете двете дестинации отделно.

Две търсения, един тунел

Външният инкапсулиран пакет е адресиран до транспортния адрес на партньора и се маршрутизира преди да съществува каквато и да е защита. Вътрешният пакет е адресиран до сървър на клиента и се маршрутизира след декапсулация, в контекста на клиента. Това са две дестинации, две търсения и често две различни таблици.

Документацията на Cisco за IPsec с поддръжка на VRF ги нарича VRF на предната врата и вътрешен VRF. Предната врата носи шифрования транспорт, а вътрешният контекст носи защитения трафик. Нищо в именуването на тунел на името на клиент не кара нито един от маршрутите да се появи.

Затова избройте четири факта, преди да промените конфигурация: транспортния адрес на партньора и контекста, който го достига, след това префикса на сървъра и контекста, който го достига. Ако не можете да попълните и четирите, предстои ви да гадаете. Гаденето в тази област е скъпо, защото маршрут, добавен в грешната таблица, може да накара един поток да работи, докато тихо чупи друг. Събирането на четирите факта отнема десет минути и спестява ден анализ на прихващане.

Потвърдете транспортното търсене за партньора

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

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Първата команда отговаря дали адресът на партньора е достижим в този контекст, втората изброява VRF, които действително съществуват, а третата показва дали е образувана асоциация за сигурност. Адрес на партньор, който се разрешава само в глобалната таблица, е класическата грешка на предната врата и изглежда като IKE преговори, които никога не започват.

Проверете и присвояването на интерфейса. Документираното поведение изисква VRF на предната врата на тунела и VRF на WAN интерфейса да съвпадат; несъответствие може да пропусне пакет да излезе и въпреки това да попречи отговорът да бъде обработен в правилния контекст.

Потвърдете вътрешното търсене за сървъра

След като предната врата е доказана, преминете към контекста на клиента и задайте същия въпрос за префикса на сървъра. Това търсене решава дали декапсулиран пакет може да бъде препратен нататък.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Първата команда показва вътрешния маршрут, а втората състоянието на сесията заедно с контекстите, които платформата е свързала с нея. Ако маршрутът съществува, но детайлите на сесията посочват грешен вътрешен контекст, тунелът препраща в таблица, която не знае префикса на клиента.

Маршрут в глобалната таблица не е доказателство за нито едно от двете търсения. Глобалните маршрути се използват, когато пакетът не е свързан с VRF, а интерфейс на тунел, присвоен на клиентски контекст, променя тази връзка. Ако вътрешният маршрут липсва, пакетът се декапсулира и след това се изхвърля поради липса на запис за препращане, което изглежда като загуба на пакети, а не като грешка в маршрутизацията.

Поставете настройката там, където моделът я очаква

Същата документация разграничава конфигурационни модели и настройка, която принадлежи на един, не принадлежи непременно на друг. За интерфейси на тунел със защита на тунела вътрешният VRF се дефинира на интерфейса на тунела. За решения, базирани на crypto map, вътрешният VRF е част от записа на crypto map. Преместването на подобно именувана команда между модели без проверка на ролята ѝ е начинът, по който работещ дизайн става нестабилен.

Маршрутизацията и идентичността са отделни въпроси. Достижимостта никога не замества профил на партньор, който устройството ще приеме, и преименуването на VRF не бива да променя предлаганите идентификационни данни. Проверете и двете след всяка промяна, защото тунел, който преговаря с грешен профил, може все пак да образува асоциация и да не препраща нищо.

Накрая запишете четирите факта и командите, които ги доказаха, в записа за промени. Следващият инженер ще наследи тунела, а не разсъжденията, и кратка бележка с имената на двата контекста струва повече от диаграма, която никой не обновява.