Вихідний 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-сервера“ зводить чотири різні несправності в одне речення, якого захоплення ніколи не виправдовувало.
Тримайте захоплення вузькими, а сирий стан ядра не додавайте до тікетів, оскільки воно може нести ключовий матеріал, якому не слід залишати хост. Різниці лічильників і часові позначки — це ті частини, які варто передати наступній людині.