Надішліть ping на 10.20.0.5 через тунель — і нічого не повертається, хоча таблиця маршрутизації наполягає, що ця підмережа доступна. Маршрутизація й IPsec відповідають на різні питання, і лише одне з них про доступність. Прямий пошук вибирає шлях, потім база даних політики безпеки вирішує, чи цей шлях треба захистити, залишити як є або відхилити. Коли ці двоє розходяться, пакет тихо помирає, тож читайте їх у такому порядку.

Почніть із пошуку, а не з таблиці

Запитайте ядро, що воно насправді зробить: ip route get 10.20.0.5 друкує вибраний маршрут, вихідний інтерфейс і адресу джерела, яку буде використано. Префікс, правило політики, мітка або бажане джерело можуть змінити цю відповідь, тому живий пошук кращий за читання таблиці на око.

Перевіряйте призначення в межах захищеного діапазону, а не адресу шлюзу. Досягнення шлюзу з того боку доводить лише те, що якийсь маршрут існує; воно нічого не каже про підмережу, яка вам справді потрібна. Потім переконайтеся, що інтерфейс, вибраний пошуком, — той, який ви очікуєте від тунелю.

Узгодьте селектори з обох боків

База даних політики має власні записи, і кожен називає напрямок, джерело, призначення та протокол, а потім указує, що робити з відповідними пакетами. Використовуйте ip xfrm policy, щоб їх перелічити; прапорці показують, чи дія — захист, обхід або блокування. Політика, чиї селектори ширші або вужчі за ваш тестовий потік, не збіжиться з ним, і пакет вийде незахищеним. Це та несправність, яку ви шукаєте, а не відсутній маршрут.

Порівняйте фактичні значення: джерело, призначення, протокол і порти. Якщо пошук визначив одну пару адрес, а запис політики покриває іншу, два подання описують різний трафік. Запустіть обидва знову з тим самим кортежем, перш ніж робити висновок, інакше ви зміните політику, якої ніколи не було на шляху.

Збіг із політикою — не встановлений стан

Відповідна політика лише каже, що пакет треба захистити; ядру все ще потрібна асоціація безпеки, щоб виконати захист. Перелічіть їх за допомогою ip xfrm state або swanctl --list-sas, коли переговори веде strongSwan, і прочитайте селектори та лічильники в кожному записі.

Коли політика збігається, а жодна асоціація не покриває ті самі селектори, пакет відкидається, а не надсилається відкритим текстом. Це те відкидання, яке треба шукати, коли тунель піднято, але одна підмережа не працює. Лічильники кажуть решту: асоціація, яка ніколи не зростає, ніколи не вибиралася, а та, що зростає й усе ж закінчується відкиданням, указує на віддалений бік. Виправлення селекторів і оновлення ключів — різні ремонти, тож вирішіть, який вам потрібен, перш ніж чіпати конфігурацію.

Що все ще вимагає тунель на основі маршруту

Інтерфейс XFRM робить тунель схожим на пристрій, у який можна маршрутизувати, і це справді корисно. Він не прибирає політику й стан, які вирішують, що станеться, коли пакет туди прибуде. Маршрут додає наступний крок і більше нічого.

Якщо пристрій існує і маршрут вказує в нього, але жодна асоціація не збігається з внутрішніми селекторами, пакет відкидається, і жодне редагування маршрутів не створює ключів або селекторів. Перевірте інтерфейс із тим самим джерелом і призначенням, які ви маршрутизували, а потім порівняйте це зі списком станів.

З'ясуйте власника, перш ніж щось правити

Міжмережевий екран хоста додає третє рішення, про яке не знає жодна з двох баз. Правильний маршрут плюс відповідна політика плюс установлена асоціація все ще можуть закінчитися відкинутим пакетом, а застосунок повідомляє лише про тайм-аут. Переконайтеся, що міжмережевий екран дозволяє захищений трафік, перш ніж звинувачувати IPsec. Перехоплення на пристрої тунелю й на фізичному інтерфейсі показує, з якого боку шифрування пакет зник.

Власник конфігурації вирішує, чи переживе ваше виправлення перезапуск. Один компонент може встановлювати стан, тоді як інший керує маршрутами, і ручна правка другого перезаписується наступного разу, коли тунель піднімається. Змініть конфігурацію власника, потім перечитайте обидва подання; RFC 4301 тримає дві бази даних окремо, коли вам треба пояснити цей поділ комусь іншому.

Схожі статті