Нові деталі, додані в кінці цього питання; можливо, я занурююсь у справу.
У мене налаштований VPN на базі UDP OpenVPN tap(мені це потрібно, tapтому що мені потрібен VPN для передачі пакетів багатоадресної передачі, що, здається, неможливо в tunмережах) з кількома клієнтами через Інтернет. У мене часто спостерігається завісання TCP-з'єднання через VPN. Тобто я встановлю TCP-з'єднання (наприклад, з'єднання SSH, але інші протоколи мають подібні проблеми), і в якийсь момент під час сеансу здається, що трафік перестане передаватися через цей сеанс TCP.
Це, здається, пов'язане з пунктами, в яких відбувається велика передача даних, наприклад, якщо я виконую lsкоманду в сеансі SSH, або якщо я catдовгий файл журналу. Деякі пошукові запити Google виявляють ряд відповідей, як цей попередній на серверній помилці , вказуючи на те, що ймовірним винуватцем є проблема MTU: що в періоди великого трафіку VPN намагається надсилати пакети, які потрапляють кудись у труби між Кінцеві точки VPN Згадана вище відповідь пропонує використовувати наступні параметри конфігурації OpenVPN для зменшення проблеми:
fragment 1400
mssfix
Це повинно обмежити MTU, що використовується у VPN, до 1400 байт і встановити максимальний розмір сегмента TCP, щоб запобігти генерації будь-яких пакетів, більших за це. Це, здається, трохи пом’якшує проблему, але я все ще часто бачу заморозки. Я спробував декілька розмірів як аргументів fragmentдирективі: 1200, 1000, 576, всі з подібними результатами. Я не можу придумати жодної дивної топології мережі між двома кінцями, яка могла б викликати таку проблему: сервер VPN працює на машині pfSense, підключеній безпосередньо до Інтернету, а мій клієнт також підключений безпосередньо до Інтернету в іншому місці.
Ще один дивний фрагмент головоломки: якщо я запускаю tracepathутиліту, то це, здається, допомагає вирішити проблему. Приклад запуску виглядає так:
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms reached
1: 192.168.100.91 19.846ms reached
Resume: pmtu 1500 hops 1 back 64
Вищеописаний пробіг знаходиться між двома клієнтами VPN: я ініціював трасування від 192.168.100.90місця призначення 192.168.100.91. Обидва клієнта були налаштовані fragment 1200; mssfix;на спробу обмежити MTU, використовуваний у посиланні. Наведені вище результати, мабуть, підказують, що tracepathвдалося виявити шлях MTU в 1500 байт між двома клієнтами. Я б припустив, що він буде дещо меншим через налаштування фрагментації, визначені в конфігурації OpenVPN. Я вважав цей результат дещо дивним.
Однак навіть незнайоме місце: якщо у мене з'єднання TCP у стані (наприклад, сеанс SSH із зазначенням каталогу, який застиг у середині), то виконання tracepathкоманди, показаної вище, змушує запустити з'єднання знову ! Я не можу знайти жодного розумного пояснення, чому це було б так, але я вважаю, що це може вказувати на рішення, щоб остаточно усунути проблему.
Хтось має рекомендації щодо інших спробу?
Редагувати: Я повернувся і поглянув на це трохи далі, і знайшов лише більшу заплутану інформацію:
Я встановив з'єднання OpenVPN на фрагмент у 1400 байт, як показано вище. Потім я підключився до VPN з Інтернету та використав Wireshark для перегляду пакетів UDP, які були надіслані на сервер VPN, поки відбувся застій. Жоден з них не перевищував вказане число 1400 байт, тому фрагментація, здається, працює належним чином.
Щоб переконатися, що навіть 1400-байт MTU буде достатньо, я пінговував VPN-сервер за допомогою наступної команди (Linux):
ping <host> -s 1450 -M doЦе (я вважаю) надсилає 1450-байтовий пакет із відключеною фрагментацією (я принаймні переконався, що він не працює, якщо встановив його на явно занадто велике значення, як 1600 байт). Вони, здається, працюють чудово; Я отримую відповіді від ведучого без жодних питань.
Тож, можливо, це зовсім не проблема MTU. Я просто розгублений, що ще може бути!
Редагування 2: Кроляча нора просто все глибша: я тепер трохи більше виділив проблему. Здається, це пов’язано з точною ОС, якою користується VPN-клієнт. Я успішно продублював проблему щонайменше на трьох машинах Ubuntu (версії 12.04 по 13.04). Я можу надійно дублювати заморожування з'єднання SSH протягом хвилини або близько того, просто catвставши великий файл журналу.
Однак , якщо я роблю той самий тест, використовуючи машину CentOS 6 в якості клієнта, я не бачу проблеми! Я тестував, використовуючи ту саму версію клієнта OpenVPN, яку я використовував на машинах Ubuntu. Я можу catзаписувати файли годинами, не бачачи, як з'єднання замерзне. Це, здається, дає деяке уявлення про остаточну причину, але я просто не впевнений, що таке розуміння.
Я вивчив трафік через VPN за допомогою Wireshark. Я не експерт по TCP, тому я не впевнений, що робити з деталей горі, але суть полягає в тому, що в якийсь момент пакет UDP потрапляє через обмежену пропускну здатність Інтернет-зв’язку, викликаючи повторну передачу TCP всередині тунель VPN. На клієнті CentOS ці повторні передачі відбуваються належним чином і все відбувається щасливо. Однак у певний момент із клієнтами Ubuntu віддалений кінець починає повторно передавати той самий сегмент TCP знову і знову (зі збільшенням затримки передачі між кожною повторною передачею). Клієнт надсилає те, що схоже на дійсний TCP ACK, до кожної повторної передачі, але віддалений кінець все ще продовжує періодично передавати той самий сегмент TCP. Це розширює рекламний безмежжя та місця з’єднання. Моє питання тут буде:
- Хтось має рекомендації щодо усунення несправностей та / або визначення першопричини проблеми TCP? Це так, ніби віддалений кінець не приймає повідомлення ACK, надіслані клієнтом VPN.
Однією загальною відмінністю між вузлом CentOS та різними випусками Ubuntu є те, що Ubuntu має набагато новішу версію ядра Linux (від 3,2 в Ubuntu 12,04 до 3,8 в 13,04). Вказівник на якусь нову помилку ядра, можливо? Я припускаю, що якби це було так, то я не був би єдиним, хто відчував проблему; Я не думаю, що це здається особливо екзотичним.
tunмережі повинна бути можливою за допомогою запуску демонів маршрутизації для багатоадресної передачі (наприклад, pimd ) та за допомогою сервера OpenVPN використовувати--topologyпараметри, встановлені на "підмережу" - див . Посібник