Изходящият ESP без отговор не означава, че VPN е мъртва
ESP защитава една посока на асоциация и не потвърждава нищо. Съпоставете вътрешния разговор и входящата SA, преди да наречете сървъра неотговарящ.
Записахте трафик на IPsec хоста, видяхте ESP пакети да излизат, не видяхте нищо да се връща и заключихте, че далечната страна е счупена. Записът не подкрепя това заключение. ESP защитава една посока от разговора и не потвърждава нищо на IP слоя, затова липсващият върнат ESP може също толкова лесно да означава, че приложението не е имало какво да каже, колкото че тунелът е мъртъв. Прочетете вътрешния обмен и състоянието на приемащата страна, преди да обвините който и да е край.
Митът: всеки защитен пакет заслужава отговор
ESP не е протокол заявка-отговор. Той криптира и удостоверява каквото избере политиката, а получателят валидира, декриптира и доставя този вътрешен пакет, без да генерира свой собствен пакет. UDP заявка, която дестинацията игнорира, или ICMP ехо, което входящата политика отхвърля, произвеждат тишина и в двете посоки като правилен резултат. Да третирате тази тишина като транспортна повреда ви изпраща да търсите мрежова неизправност, която никога не е съществувала.
Това, което еднопосочният запис всъщност доказва, е, че стекът на подателя е криптирал нещо в тази точка на наблюдение. Нищо за пристигането и нищо за намерението да се отговори. Полезният въпрос не е "защо няма отговор", а "какво е трябвало да произведе вътрешният разговор".
Две SA, два SPI, един разговор
Асоциациите за сигурност на IPsec са еднопосочни, затова нормалният защитен обмен включва входяща и изходяща асоциация с отделни идентификатори и независимо състояние. Да търсите върнатия трафик по SPI на изходящия пакет е категориална грешка, защото всеки отговор пътува под собствената изходяща SA на партньора със свой собствен SPI. Съпоставете двойката по селектори на трафик и адреси на партньора.
Прегенерацията на ключове усложнява картината за по няколко секунди наведнъж, тъй като старото и заменящото състояние могат да се припокрият. Ако симптомът е започнал около прегенерация на ключове, събирайте идентификаторите на асоциациите и времевите маркери заедно, а не само името на връзката.
Какво трябва да направи получателят, преди нещо да отговори
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Всеки ред се проваля независимо и всеки провал има различен собственик, затова един запис не може да ги различи. Входящият брояч е единственото пряко доказателство за пристигане, защото пакет, който не премине удостоверяване или проверка за повторение, се изхвърля без никакъв отговор. Партньор, чийто входящ брояч не е мръднал, следователно не ви дава никаква информация за политиката си.
Доставянето е отделна стъпка от декриптирането. Състоянието може да е валидно и пакетът пак да бъде изхвърлен след това от входяща политика или маршрут, който не включва вътрешната дестинация, затова проверете дали целевият хост е видял открит текст, вместо да приемате, че чист брояч означава, че пакетът е отишъл където искате.
Собственият ESP не е UDP
Собственият ESP е IP протокол 50, който не е нито TCP, нито UDP и няма никакви портове. Затова правило на защитна стена, което разрешава IKE на UDP 500, не казва нищо за пътя на данните, а филтър, написан около портове, може да позволи на тунела да преговаря и след това да изхвърли всичко, пренасяно вътре в него. Тествайте пътя на данните отделно, в режима, който действително сте наблюдавали.
Зад NAT формата се променя: защитеният полезен товар пътува вътре в UDP, обикновено на порт 4500, както определя RFC 3948. Запишете активния режим, преди да напишете каквото и да е правило, защото устройство по пътя може да третира собствения ESP и ESP в UDP обвивка напълно различно, а някои междинни устройства разрешават едното и изхвърлят другото.
Четете броячи, които принадлежат на този инцидент
На strongSwan хост swanctl --list-sas отчита броячи на пакети и байтове за всяка асоциация в двете посоки, което е достатъчно да раздели "никога не е пристигнало" от "пристигна и не получи отговор". На Linux /proc/net/xfrm_stat брои обобщени провали като липсващо състояние, липсваща политика и протоколни грешки. Тези сборове се натрупват от зареждането и принадлежат на едно мрежово пространство от имена, затова голямо число не е приписване.
Вземете две измервания около прозореца на инцидента в правилното пространство от имена и сравнете разликите, иначе ще закачите грешките от миналата седмица на днешния тикет. Сложете пространството от имена и двата времеви маркера в тикета, за да може следващият читател да възпроизведе сравнението, вместо да вярва на сбор.
Назовавайте етапа, не заподозрения
Полезното заключение казва къде е спрял пакетът: никога не получен, получен и изхвърлен, доставен но без отговор, или отговорен и изгубен по обратния път. Всяка от тези точки сочи различен собственик и различна следваща команда. "Няма отговор от VPN сървъра" смачква четири отделни повреди в едно изречение, което записът никога не е оправдавал.
Пазете записите тесни и дръжте суровото състояние на ядрото извън тикетите, защото то може да носи ключов материал, който няма работа да напуска хоста. Разликите в броячите и времевите маркери са частите, които си струва да предадете на следващия човек.