Тунель стоїть, маршрут зник: розділяємо дві несправності VPN

Один хост стає недоступним, хоча інтерфейс тунелю досі повідомляє, що його встановлено, і ці два спостереження не суперечать одне одному. Щось прибрало шлях, яким користувався трафік: сусід відкликав свій префікс, відстежуваний статичний маршрут було знято, або інший маршрут став кращим. Асоціація безпеки може залишатися цілком здоровою в усіх трьох випадках. Розділити події означає запитати, який рівень змінився першим, а не чи впав VPN.

Три етапи, що виглядають як одна подія

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

Тому перше питання — який етап зламався, а не який протокол винен. Відповідь визначає, кому належить інцидент і який інструмент використає наступна перевірка.

Спершу прочитайте встановлений маршрут

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

Потім подивіться на власний погляд протоколу

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Зведення повідомляє, чи встановлено сесію, подання за префіксом — чи прийнято префікс, а пошук у ядрі — чи його встановлено. Читання їх у такому порядку не дає сплутати тремтіння сесії з відкликанням, а відкликання — з відмовою за політикою.

Коли годинники розходяться

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

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

Відновлення без петлі

Після відкликання два шляхи можуть бути придатними: той, що вибирає протокол, і той, що ви закріплюєте вручну. Лише перший — це рішення, яке мережа продовжує ухвалювати за вас, тому ручний маршрут — це тимчасовий засіб, а не план відновлення. Альтернативне оголошення також не зберігає стан міжмережевого екрана або NAT для вже встановленої сесії, тож нові потоки можуть працювати, поки початковий залишається зламаним. Підтвердьте, який резерв має стати активним і чи прийме віддалений майданчик зворотний шлях через нього.

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