Чому ім'я VPN-адаптера може приховувати інший протокол
Мітка біля адаптера описує програмне забезпечення, яке його створило, а не пакети в мережі. Перевірте клієнт, профіль і партнера, перш ніж вибирати рішення.
Мітка біля VPN-адаптера описує програмне забезпечення, яке створило інтерфейс, а це на один рівень вище за пакети, які справді проходять через мережу. Плагін може показати адаптер, ім'я якого відображає власну класифікацію плагіна, а не інкапсуляцію в мережі. Читання клієнта, профілю та партнера відповідає на те, на що ім'я відповісти не може. Два підключення, які в меню налаштувань виглядають однаково, можуть поводитися зовсім по-різному в записі.
Ім'я походить від постачальника, а не з мережі
Windows визначає короткий список типів підключень для своїх вбудованих VPN-клієнтів, а сторонні продукти встановлюють поруч власний стек. Адаптер, що з'являється в списку мереж, створює той драйвер, якому належить підключення, тому його ім'я є свідченням про драйвер, а не гарантією про зовнішній протокол. Саме тому видалення одного клієнта може залишити ім'я адаптера.
Документація Microsoft про типи VPN-підключень прямо зазначає, що тип описує конфігурацію клієнта для цього підключення. Коли задіяний плагін, показаний тип слідує тому, що реєструє плагін, а фактична інкапсуляція може бути чимось зовсім іншим.
Та сама шаруватість трапляється і в інших місцях. Віртуальний адаптер на хості Linux, пристрій TAP або розширення мобільного VPN-сервісу — усе це інтерфейси, створені програмним забезпеченням, і ім'я інтерфейсу вибирає це програмне забезпечення, а не узгоджує з сервером.
Що порти й адреси можуть і чого не можуть вам сказати
Кожен шар залишає різні свідчення. Читайте їх окремо, і мітка перестає бути вироком:
| Evidence | What it establishes | Where it misleads |
|---|---|---|
| Adapter name | Which driver bound the interface | Plugins choose their own labels |
| Profile file | Which client consumes the configuration | Abstraction layers hide the transport |
| Outer port | Which port the peer accepts | 443 carries several protocols plus HTTPS |
| Tunnel address | The inner interface's network | Says nothing about encapsulation |
TCP 443 — найясніший приклад. Він може нести SSTP, тунель OpenVPN TCP, сеанс SoftEther SSL-VPN або звичайний веб-трафік, і сам номер порту не може їх розрізнити. Тому правило брандмауера, яке дозволяє 443, не є доказом того, який клієнт використовується. Запис на зовнішньому інтерфейсі вирішує це і вирішує за секунди.
Прочитайте формат профілю та партнера
Файл конфігурації — сильніша підказка, ніж адаптер. Профіль OpenVPN містить директиви на кшталт remote, proto і ca; конфігурація WireGuard містить розділ [Interface] з приватним ключем і розділи [Peer] з дозволеними IP; запис у телефонній книзі Windows зберігає тип підключення у власному форматі. Кожен синтаксис належить одній реалізації.
Потім подивіться на документацію та журнали партнера. Сервер знає, який обробник протоколу прийняв сеанс, і його журнал називає завершений етап. Це свідчення сильніше за будь-яку мітку на робочому столі, бо воно фіксується там, де пакети справді інтерпретувалися.
Вибирайте посібник за протоколом, а не за міткою
Директива OpenVPN належить OpenVPN, ключі та дозволені IP WireGuard належать WireGuard, а профіль SSTP не є ні тим, ні іншим. Вставити параметр одного клієнта в інший, бо ім'я адаптера звучало сумісно, — так і ламають робочу конфігурацію.
Після визначення протоколу виберіть відповідний шлях усунення несправностей: власний журнал клієнта, журнал сервера, специфічний для протоколу, і запис, що показує зовнішній обмін. Відтоді збій має ім'я, а не мітку.