Чи споживає неактивний VPN трафік? Читайте правильний лічильник

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

Чому неактивний тунель усе одно рухає байти

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

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

Неактивний застосунок не є неактивним пристроєм

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

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

Виберіть один лічильник і скажіть, що він рахує

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

ip -s link show wg0
ip -s link show eth0

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

Проведіть коротке вимірювання під наглядом

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

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

Не купуйте чистіший нуль із гіршим тунелем

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

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