Один порт OpenVPN, три служби: чому важливі внутрішні порти

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

Що несе зовнішній потік і що він приховує

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

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

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Документація TUN/TAP описує передачу, під час якої маршрутизований пристрій TUN передає IP-пакети між ядром і процесом у просторі користувача. Саме ця передача робить внутрішній заголовок видимим для коду маршрутизації та брандмауера шлюзу. Вона також пояснює, чому зовнішній порт нічого не каже про те, які служби дозволені.

Переадресація NAT належить слухачу, а не застосункам

Самостійно розміщений шлюз за NAT IPv4 потребує одного вхідного перетворення: публічна адреса й порт зіставляються зі слухачем VPN. Жодне правило не потрібне для SSH, HTTPS чи DNS лише тому, що користувачі тунелю до них доходять. Публікація цих портів відкрила б служби, які тунель уже захищає. Правило переадресації описує доступність слухача, а не дозвіл для чогось усередині.

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

Внутрішня політика — це місце, де доступ насправді вирішується

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

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

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard проводить ту саму межу

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

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

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