Що екран iftop може і чого не може довести про VPN

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

Три умови визначають значення екрана

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

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

Умова перша: який інтерфейс показується

iftop приймає інтерфейс явно через -i, і його посібник описує поведінку, коли ви цього не робите: він вибирає один, і це може бути пристрій, що виглядає зовнішнім, а не тунель. Таке значення за замовчуванням розумне для інструмента пропускної здатності й погане для тесту витоку.

Завжди вказуйте інтерфейс і записуйте його поруч із результатом. Знімок екрана без назви інтерфейсу невідтворюваний.

Умова друга: що приховують фільтр та інструмент

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

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

Умова третя: що саме виконав тест

Один запит від одного застосунку до одного призначення в одній родині адрес доводить щось про цей запит. Він нічого не доводить про інший застосунок, інше призначення чи іншу родину адрес, і IPv6 — це родина, яку найчастіше забувають саме в такій перевірці.

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

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

Використання iftop як підтримного доказу

Лише тоді iftop додає цінність, і додає її як підтвердження. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" показує, чи з’являється очікуваний потік на очікуваному інтерфейсі, з підрахунками байтів, які роблять твердження про простій перевірним.

Порівняйте це з ss -tnp для вигляду на рівні сокета і ip route get для маршруту, який обрало б ядро, і ви матимете три спостереження одного запиту замість одного враження про машину. Посібник iftop документує вибір інтерфейсу, синтаксис фільтра й поведінку пошуку — саме ті три речі, від яких залежить тест витоку. Екран пропускної здатності локалізує активність; маршрут, винятки й поведінка в разі збою вирішують, чи відповідає ця активність вимозі.