Огляд VPN-інтерфейсу Linux за допомогою ip link, рівень за рівнем

Значок клієнта каже, що з’єднання встановлено, інтерфейс існує, а застосунок усе одно нікуди не дістається. Така комбінація трапляється часто, бо віртуальний інтерфейс може залишатися на місці, коли його віддалений вузол, адреси чи маршрути відсутні. ip link — правильний перший інструмент, і водночас той, який найлегше прочитати із зайвим. Прапорці та лічильники описують один рівень, а рівні над ними відмовляють незалежно. Це також інструмент, який цитують, коли хочуть довести, що тунель працює, а це саме те твердження, яке він сам по собі підтримати не може.

Прочитайте інтерфейс раніше за значок

ip -details link show dev tun0 — почніть із нього, як описано в посібнику ip-link, підставивши інтерфейс, яким насправді володіє ваш клієнт, замість звичного імені. Прапорці, тип, MTU та ідентичність інтерфейсу — корисні спостереження. Формулювання стану віртуального інтерфейсу не зобов’язане поводитися як індикатор несучої фізичного кабелю, тож сприймайте UP як твердження про інтерфейс, а не про тунель.

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

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

Додайте лічильники й запит, який має ними скористатися

Скористайтеся підтримуваним поданням статистики, ip -s link show dev tun0, і занотуйте кількість пакетів і байтів в обох напрямках. Потім згенеруйте нешкідливий запит, який має пройти через інтерфейс, і порівняйте відповідний напрямок. Запит, що пішов прямою маршрутизацією іншого застосунку, цих лічильників не зрушить, і саме в цьому сенс вправи.

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

Зніміть показники двічі, один раз до і один раз після, замість того щоб довіряти одному знімку.

Адреси й маршрути — окремі кроки

Зв’язок може існувати без префікса, без конфігурації розв’язувача імен або без маршруту, потрібного застосунку. Перевірте адресу через ip address show dev tun0, а потім подивіться, який маршрут вибере призначення, через ip route get для реальної цілі. Ці три спостереження відповідають на три різні питання, і лише останнє стосується пересилання.

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

Записуйте точну назву, простір імен і час разом із будь-яким виводом, який зберігаєте, бо однакова на вигляд назва в іншому контейнері чи у відновленому сеансі означає зовсім інший контекст.

Не видаляйте того, що не ідентифікували

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

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

Ця обережність стосується й ip link set down, яка виглядає зворотною, а часто нею не є.

Що має залишити вам огляд

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

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

Зберігайте вивід разом із заявкою, бо пізніше порівняння корисне лише тоді, коли ви бачите, що змінилося.

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