Чому багато з'єднань програм ділять один сеанс OpenVPN

Уявіть браузер, що завантажує сторінку HTTPS, тоді як клієнт SSH досягає іншого сервера, а розв'язувач відповідає на запит, — усе через один сеанс OpenVPN. На фізичному інтерфейсі ви бачите одну розмову; усередині тунелю — три. Обидва погляди правильні, і знання чому — це різниця між корисним і заплутаним записом. Простежте один внутрішній потік від сокета до дроту, і багатошаровість перестає бути абстрактною.

Одна зовнішня розмова, багато внутрішніх потоків

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

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

Порт, що залишається незмінним

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

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

Що декапсуляція змінює на далекому кінці

У партнера зовнішній шар знімається, і залишається внутрішній пакет. Далі пересилання й політика доступу застосовуються до внутрішнього призначення та протоколу. Вебсервер досі отримує з'єднання HTTPS, демон SSH досі отримує SSH, а розв'язувач досі отримує запит.

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

Зовнішній TCP означає один потік, а не одне з'єднання

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

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

Опишіть власну конфігурацію точно

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

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