Избор на стабилен източник за регистрация на членове на GET VPN

Някой насочва регистрацията на члена на групата към адрес loopback и обявява, че нестабилността на GET VPN е решена. Понякога е така. Често loopback е достъпен само от собствената таблица за маршрутизация на члена и отникъде другаде, така че регистрацията отново се чупи следващия път, когато uplink, който я е носил, мига. Адресът за регистрация е идентичност на контролния слой и помага само когато съществува реален път в двете посоки. Съзнателният избор си заслужава и е по-малка промяна, отколкото подсказва общоприетото мнение.

Какво идентифицира адресът за регистрация

При внедряване на GDOI членът на групата се регистрира при сървъра за ключове и получава от него групова политика. Адресът, който сървърът за ключове записва, е идентичността на члена за това взаимодействие.

Тази идентичност покрива контролния разговор: регистрация, обновяване на ключовете и изтегляне на политиката. Той не става източник на клиентски трафик, и не променя кои интерфейси защитават кои потоци.

Разделянето на двете е първата стъпка, защото по-голямата част от объркването около тази настройка идва от очакването промяна в контролния слой да оправи симптом в слоя на данните.

Loopback е толкова добър, колкото е добър маршрутът му

Loopback дава на члена логически адрес, който не изчезва, когато един физически uplink откаже. Това е реално предимство на рутер с няколко пътя до сървъра за ключове.

Но това е само адрес. Ако сървърът за ключове няма обратен маршрут до него, регистрацията се проваля точно както преди. Ако таблицата за маршрутизация на члена достига до сървъра за ключове само през един uplink, loopback е стабилен, а пътят не е.

Проверете достижимостта в двете посоки през всеки uplink, който искате да оцелее. Loopback, който остава административно активен, не доказва нищо за препращането, а отказът изглежда като недостъпен сървър за ключове, а не като проблем с интерфейс. Запишете проверката като команда за всеки uplink, а не като предположение. Тогава следващият прозорец за промяна започва с доказателства, а не с диаграма.

Държте контрола и защитения трафик отделно

Ръководството на Cisco за заобикаляне на GDOI документира интерфейса за регистрация и връзката между регистрацията и обработката на заобикалянето. Прочетете поведението за версията, която действително използвате, вместо да третирате една фраза като универсална команда.

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

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

Проверете идентичността по време на прехода

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

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

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

Какво не поправя стабилният източник

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

Това, което прави, е да премахне една променлива: идентичността вече не се променя, когато се промени адресът на uplink. Това си заслужава и е един ред в един дизайн, а не целият дизайн.

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