DPD отговорите доказват, че IKE партньорът е жив, а не че данните ви текат
Отговори за живост, известие за подпълване и стеснени селектори описват три различни неща. Четете ги поотделно, преди да обвините едно от тях за спиране.
IPsec журналите могат да показват отговори за живост, докато приложението пред тях спира, и двата факта могат да са верни едновременно. DPD отговорът установява, че IKE обработката на партньора е отговорила в онзи момент; той не казва нищо за това дали дъщерният SA носи пакета, който ви интересува. Да третирате всяко предупреждение близо до прекъсване като негова причина е начинът, по който проблем със селектор се диагностицира като протоколна грешка. Три наблюдения се бъркат най-често и те отговарят на три различни въпроса. Четете ги по връзка и предназначение, преди да ги четете по времева марка.
Какво доказва всяко наблюдение
Таблицата разделя какво установява всяко наблюдение от това, което то просто придружава.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
Никое от трите не е грешка само по себе си. Всяко става интересно само до потока, който отстранявате, а ред, който не може да се свърже с конкретен поток, е контекст, а не доказателство.
Живостта не е здраве на данните
DPD работи като INFORMATIONAL обмен — разговор на контролната равнина между IKE демони. Отговорът доказва, че IKE процесът на партньора е достъпен и готов да отговори, а изтичането на времето доказва, че не е. Нито един от резултатите не проверява дъщерния SA, селекторите, пътя за препращане или отговора на приложението, затова здрав DPD до спрян трансфер е последователна картина, а не противоречие.
Затова редовете за живост са най-малко полезната част от тикет за равнината на данните, колкото и успокояващо да изглеждат в началото на журнала.
Известието за подпълване е изявление за подпълване
TFC подпълването е най-пречитаният ред в тези журнали. То казва, че подпълване за поверителност на трафичния поток няма да бъде прието за този дъщерен SA, което е изявление за незадължителна функция за подпълване, а не отхвърляне на ESP защитата. Намирането му близо до отказ обикновено е съвпадение на многословие и включването или изключването на подпълването не променя нищо в покритието на селекторите.
Спецификацията IKEv2 дефинира както известието, така и договарянето на селектори, и предупредителният етикет на дадена реализация не заменя протоколния смисъл в нито един от двата случая.
Стесняването е по-тихо и по-вероятно да има значение
Отговарящата страна може да приеме подмножество от предложените селектори и приетото множество може да бъде отпечатано в няколко записа — един с квалификация по порт, друг обхващащ всички портове. Четенето само на първия ред с квалификация по порт подценява приетото; четенето само на широкия ред го надценява. Сравнете отпечатаното предложение с инсталираната политика, защото предложението е това, което партньорите са казали, а политиката е това, което ядрото ще съпостави. Когато те се разминават, тунелът съществува, а трафикът — не, и това е класическото периодично оплакване. Обръщайте локалната и отдалечената перспектива, когато сравнявате партньори, защото локалното на всяка страна е отдалеченото на другата.
Записите, специфични за хост, с ограничение по порт заслужават двойно четене, защото именно те изключват ICMP или втори порт, оставяйки ping към шлюза да работи.
Изградете един запис за проблемния поток
Запишете източник, дестинация, семейство адреси, протокол и порт, както се виждат при решението за защита, включително всяко умишлено преобразуване. Това са стойностите, които трябва да съвпаднат със селектор, и това са също стойностите, които хората преписват по памет, когато тикетът стигне до трети чифт ръце.
След това идентифицирайте дъщерния SA и неговите насочени броячи: swanctl --list-sas дава обобщението на асоциацията на strongSwan хост, а ip -s xfrm state дава броячите. Четете ги след прясна разрешена заявка, а не докато системата бездейства. Липсата на увеличение на изходящия трафик сочи към селекцията или локалния път; изходящ без съответстващ входящ сочи към партньора, неговото препращане или неговите отговори.
Завършен обмен на приложението е над всеки от броячите, затова тестът трябва да завършва при приложението, а не при индикатора на тунела.
Изберете корекцията след това
Едва след като този запис съществува, има корекция за избор: приети селектори, маршрут, филтриране, реализация на партньора или граница, която вече сте демонстрирали. Нулирането на партньора променя няколко състояния наведнъж и често възстановява трафика, без да обяснява кое е било грешно, затова прекъсването се връща. Дръжте дъмповете на състоянието на ядрото извън тикетите, защото те могат да съдържат ключове, а тясното обобщение е достатъчно за всеки, който трябва да помогне.
Когато записът противоречи на първата ви теория, вярвайте на записа и пренапишете теорията; този навик струва повече от всеки отделен ред в журнала, обсъден тук.