Етапи рукостискання VPN: що відбувається до початку передавання трафіку

Натискання «Підключитися» запускає чотири окремі завдання, які успішно або неуспішно завершуються незалежно. Клієнт має дістатися слухача, узгодити, хто є партнером, вивести ключі й потім передати робочий тунель решті системи. Більшість невдалих з’єднань діагностують не в тому завданні. Тому перша помилка важливіша за третю спробу.

Спершу дістаньтеся слухача

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

Тайм-аут, відмова сертифіката й відхилений обліковий запис — три різні несправності з трьома різними перевірками. Саме їхнє первинне розділення не дозволяє шукати мережеву проблему як проблему облікових даних.

Доведіть партнера, потім виведіть ключі

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

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

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

Три протоколи, три розмови

У розгортанні OpenVPN на базі TLS керівний канал узгоджує параметри безпеки, а канал даних несе трафік тунелю, тому опція каналу даних і проблема сертифіката перебувають у різних місцях. IKEv2 автентифікує обидві сторони, а потім встановлює асоціації безпеки IPsec зі своїми строками життя. WireGuard виводить ключі через свій обмін на основі Noise і навмисно тримає машину станів маленькою. Знання того, який із трьох ви запускаєте, визначає, який журнал варто читати.

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

Чого рукостискання не робить

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

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

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

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal