Да ли је рутеру између два IPsec партнера потребан IPsec?

Лабораторијска вежба која каже „конфигуришите IPsec између две локације“ крије два различита посла. Две крајње тачке завршавају тунел: преговарају, аутентификују, шифрују и дешифрују. Сваки рутер између прослеђује пакете чије спољашње заглавље припада крајњим тачкама, и то чини не знајући да тунел постоји.

Одлука који се посао тражи од уређаја је први корак вежбе. Већина забуне у лабораторијским извештајима, и добар део забуне у дијаграмима продукције, долази од тога што се „подржава IPsec“ третира као једно својство уместо два.

Прослеђивање није завршавање

У тунелском режиму, спољашње IP заглавље је адресирано на уређаје који завршавају тунел. Рутер у средини проналази одредиште и прослеђује, исто као за било који други пакет, а корисни терет који носи је за њега непрозиран.

Та непрозирност је намерна. Рутер не чува тајну партнера, не води преговоре и не потребна му је база политика. Потребан му је пут до удаљене крајње тачке и дозвола да проследи пакет.

Мешање тога двоје доводи до стварних грешака: тражење од транзитног заштитног зида да „дозволи IPsec“, када је стварни захтев дозволити протокол 50 између одређених адреса, или очекивање да ће посредни уређај дешифровати ради инспекције када нема кључ.

Шта посредни уређај ипак мора да уради исправно

Прослеђивање има своје захтеве. Путање морају да достигну обе спољашње крајње тачке, а свака политика дуж пута мора да дозволи стварни спољашњи саобраћај, а не претпостављени број порта. Правило написано према TCP 443 јер је неко претпоставио TLS неће се поклопити са протоколом 50.

Изворни ESP је IP протокол 50. Није TCP 50 ни UDP 50, а правило које блокира саобраћај који није TCP одбациће га. Ако пројекат користи UDP инкапсулацију, видљиви транспорт се мења на порт инкапсулације, а политика мора да одговара изабраном пројекту.

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

Зашто симулатор мења питање

Симулатор није рутер са краћом листом функција; то је модел са документованим подскупом и сопственим правилима о томе шта се дати уређај може конфигурисати да ради. Често постављана питања за Cisco Packet Tracer јасно наводе да су уређаји и протоколи поједностављени модели.

Тако питање постаје три питања. Да ли симулирани уређај прослеђује пакете који су потребни сценарију? Да ли исти уређај нуди површину за конфигурацију коју лекција претпоставља? И да ли прихваћена команда значи да се понашање заиста симулира или само анализира?

Команда која недостаје може бити ограничење модела, а не грешка у вашој конфигурацији. Присутна команда може прихватити синтаксу без репродуковања сваког продукционог понашања. Проверите помоћ уређаја инсталиране верзије пре него што закључите у било ком смеру.

Писање услова за успех за лабораторију

За лекцију о underlay-у, услов за успех је достижност крајњих тачака плус спољашњи пакети који пролазе кроз посредни уређај. Докажите то бројачима самог симулатора или приказом пакета и именујте протокол који очекујете.

За лекцију о IPsec-у, додајте стање преговора и један заштићени ток од LAN-а до LAN-а. Ако симулатор приказује безбедносне асоцијације, забележите их. Ако не, напишите то у извештају уместо да наговештавате да је тунел верификован.

Чувајте верзију симулатора, изабране уређаје и циљ учења уз датотеку топологије. Управо тај запис омогућава неком другом да понови вежбу и разуме који су делови моделирани.

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