IPsec ESP: какво пренася и как да докажем, че трафикът тече
ESP обвива вътрешен IP пакет в тунелен режим и идентифицира асоциацията си чрез SPI. Прочетете състоянието, после вижте как един поток движи броячите.
ESP пренася трафика в IPsec VPN и неговият runbook започва с едно правило: прочетете security association, преди да промените политика. Повечето необяснимо поведение на ESP се свежда до селектор, който не е съвпаднал, режим, който е бил предположен, а не прочетен, или брояч, който никой не е проверил, докато е бил изпращан един поток. Трите стъпки по-долу установяват какво какво пренася, доказват, че един поток го използва, и оставят връщане назад, което не зависи от паметта. Всяка стъпка дава едно наблюдение, което си струва да се запише.
Познайте полетата, преди да ги прочетете
ESP поставя заглавка пред защитените данни и трейлър след тях. Заглавката носи индекс на параметрите за сигурност, който идентифицира коя асоциация трябва да използва получателят, пореден номер за откриване на повторения и подпълване в трейлъра, което поддържа полезния товар подравнен за шифъра. Полето за следваща заглавка в трейлъра казва какво е защитеното съдържание и така получателят разбира какво е декапсулирал.
Режимът променя какво стои вътре в тази защита. В тунелен режим защитеният материал е пълен вътрешен IP пакет и нова външна заглавка го пренася между крайните точки. В транспортен режим защитата обвива полезния товар от горния слой на съществуващ пакет, така че няма втора IP заглавка за отваряне. Кой режим се използва е факт от конфигурацията, а не въпрос на интерпретация. Прочетете го от записа за състоянието, вместо да го извеждате от диаграма.
Нито един от двата режима не скрива външното адресиране, което трябва да достави пакета. Това е свойство на дизайна, а не недостатък, и затова междинен наблюдател все още вижда кои два адреса разговарят, дори когато полезният товар е непрозрачен.
Стъпка първа: прочетете състоянието, после политиката
Записите за състоянието държат ключовете и броячите; записите за политиката държат селекторите, които решават какво може да ги използва. В Linux и двете се виждат без прихващане на пакети и четенето им в този ред държи двата въпроса разделени.
ip xfrm state
ip xfrm policyВ изхода за състоянието проверете източника и дестинацията на асоциацията, режима и дали капсулирането показва UDP портове. Тези портове означават, че се използва преминаване през NAT, което променя какво трябва да разреши междинният firewall, но не и кои селектори или ключове важат в крайните точки.
След това прочетете селекторите в политиката. Селектор, който назовава по-тесен префикс от тествания трафик, е най-честата причина работещ тунел да изглежда, че пренебрегва поток, а селектор за грешен протокол дава същото мълчание.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
Инструментите на доставчиците показват същата информация в по-удобна форма. ipsec statusall в strongSwan изброява дъщерните асоциации, техните селектори и броячите им на байтове, което често е по-бързо от четенето на суров xfrm изход, когато вече знаете коя дъщерна асоциация да гледате.
Стъпка втора: докажете, че един поток движи броячите
Броячите имат смисъл само ако знаете какво е трябвало да ги премести, затова изберете източник и дестинация, които селекторът определено покрива, и изпратете една безвредна заявка. После прочетете отново същия запис и сравнете.
ip -s xfrm state
tcpdump -ni any espДве четения разказват различни истории. Пакети, които нарастват на изходящата страна, но никога на входящата, сочат към проблем с препращането или обратния път, а не с ключа, защото пакетът е бил капсулиран и е тръгнал. Ако не се движи нито един брояч, трафикът изобщо не е съвпаднал с политиката, и селекторът е мястото, където да гледате.
Прихващането в същата стъпка потвърждава капсулирането по кабела, включително дали външните пакети са ESP или ESP с UDP капсулиране. То също ви показва адресите, които действително са пренесли потока, а те понякога се различават от тези в конфигурацията, която сте чели.
Стъпка трета: променете едно нещо и запазете връщане назад
Запишете източника, дестинацията, режима, селекторите и броячите на асоциацията, преди да редактирате каквото и да е. Ако промяна влоши нещата, точно този запис ви позволява да възстановите предишното състояние, вместо да пресъздавате работеща конфигурация от догадка. Този запис отнема минута и спестява час по-късно. Той е и единственият артефакт, който остава след човека, направил промяната.
Променете един селектор или един параметър, презаредете го и повторете втората стъпка срещу същия поток. Изтриването на асоциация разрушава всеки поток, който я използва, затова целенасочена редакция и презареждане на дъщерната асоциация са почти винаги по-добри от изчистване на състоянието, за да видите какво ще стане.
Връщането назад при редакция на селектор е възстановяване на предишната политика и презареждане, с уговорката, че партньорът може да се нуждае от съответстваща промяна, ако селекторът се договаря, а не е локален. Запишете тази зависимост, докато е свежа, защото наполовина възстановена двойка е по-трудна за разсъждение от всяко от двете крайни състояния.
Накрая, дръжте обхвата честен. Работеща ESP асоциация доказва, че двата шлюза защитават и доставят сегмента, и не казва нищо за това дали приложението отгоре удостоверява потребителите си или шифрова това, което съхранява. Това са отделни контроли с отделни доказателства и runbook е завършен само когато следващият човек може да го повтори по бележките.