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

Який етап зламався, те й визначає, яке порівняння важливе

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

Знімайте трафік під час повторної спроби, а не після. На клієнті tcpdump -ni any udp port 1194 показує, чи взагалі повертається якась відповідь. Повторіть на WAN-інтерфейсі сервера, який ви контролюєте, — це покаже, чи доходять ці пакети до дальнього кінця.

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

Фільтрація UDP проти закритого порту

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

Профіль TCP на порту 443 — звичайний обхідний шлях, бо він схожий на звичайний потік HTTPS і проходить крізь більшість captive-порталів і вихідних фільтрів. Мають виконуватися дві умови. Сервер повинен слухати з proto tcp-server, клієнт має збігатися з proto tcp-client, а оператор має опублікувати цю альтернативну точку. Переписати робочий UDP-профіль під TCP 443 марно, якщо на іншому кінці ніхто не слухає.

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

Старіші протоколи програють за цією віссю. PPTP потребує TCP 1723 плюс GRE, а GRE — це IP-протокол 47, а не порт, тож звичайне перенаправлення порту його не виражає.

Коли пакети відкидає комутатор

Керований комутатор може навмисно відкидати тунель. Деякі моделі HPE і Aruba пропонують елемент керування захистом від UDP-flood, іноді позначений Prevent UDP Blat Attack, у розділі розширеної безпеки. Щойно цей елемент активний, сервер за комутатором ні на що не відповідає, і кожен клієнт завершується за тайм-аутом однаково. Вимкнути його й зберегти поточну конфігурацію — це весь ремонт, але лише після того, як ви переконалися, що комутатор справді на шляху.

Контрдокази — це те, що відрізняє відкидання комутатором від блокування провайдером. Прочитайте лічильники інтерфейсу й журнал захисту від flood, перш ніж відкривати заявку в ISP. Споживчі маршрутизатори із захистом від DoS чи flood збоять так само, як і будь-який проміжний вузол із коротким тайм-аутом простою UDP. Рукостискання, яке ніколи не завершується, вказує на відкидання, а тунель, що вмирає через кілька хвилин тиші, вказує на тайм-аут.

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

Перекриття адрес, схоже на збій DNS

Мережа доступу, пронумерована всередині 10.0.0.0/8, може перекриватися з пулом тунелю, і резолвер зазвичай живе в цьому пулі. Коли ноутбук отримує адресу на кшталт 10.184.178.50 з маскою /8 у Wi-Fi, кожне призначення 10.x за визначенням є локальним. Пакети до 10.4.0.1 тоді йдуть у LAN, тунель лишається піднятим, а розв'язання імен не працює.

ip addr показує перекриття з першого погляду, а ip route get 10.4.0.1 показує, куди пакет був би насправді доставлений. Оскільки видимий симптом — збій резолвера, це часто переживає кілька раундів змін DNS.

Перенумеруйте пул або тримайте цю мережу доступу поза областю. Жодне налаштування на боці клієнта не рятує від перекриття.

Вибір між резервним TCP і виправленням шляху

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

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

Схожі статті