Як протестувати другий VPN-клієнт на Mac, не втративши перший

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

Симптом: робоча конфігурація перестає працювати після другого встановлення

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

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

Зафіксуйте вихідний стан перед тим, як щось встановлювати

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

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

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

Змінюйте по одному активному шляху

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

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

Порівнюйте DNS, маршрути й програму, а не лише швидкість

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

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

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

Відновіть, потім видаліть чисто

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

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