Русский
English
Українська
Deutsch
Español
Тунельний проксі встановлює наскрізне з'єднання між клієнтом і сервером призначення, інкапсулюючи весь трафік у захищеному каналі через проксі-сервер, зазвичай без перевірки вмісту проксі.
Розуміння тунелювання трафіку
Тунелювання трафіку через проксі передбачає, що проксі-сервер діє як ретранслятор для необроблених потоків даних, а не як посередник на прикладному рівні. На відміну від традиційних прямих проксі, які завершують клієнтські з'єднання, аналізують HTTP-запити, а потім ініціюють нові з'єднання з вихідними серверами, тунельний проксі забезпечує прямий, побайтовий канал між клієнтом і кінцевим призначенням. Цей механізм переважно використовується для протоколів, які вимагають зашифрованого або не-HTTP-орієнтованого з'єднання, таких як HTTPS, SSH або VPN-трафік.
Метод CONNECT
Найпоширенішим методом встановлення тунелю через HTTP-проксі є HTTP-метод CONNECT. Коли клієнту потрібно підключитися до не-HTTP-сервісу або зашифрованого HTTP-сервісу (HTTPS) через проксі, він надсилає CONNECT-запит до проксі.
Приклад запиту клієнта:
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive
Отримавши цей запит, проксі-сервер намагається встановити TCP-з'єднання з вказаним хостом і портом (наприклад, www.example.com на порті 443).
Приклад відповіді проксі:
HTTP/1.1 200 Connection established
Proxy-Agent: Squid/5.8
Якщо проксі успішно встановлює з'єднання з призначенням, він відповідає статусом 200 Connection established. З цього моменту проксі припиняє інтерпретувати дані, що проходять через нього. Замість цього він діє як простий TCP-ретранслятор, пересилаючи всі наступні байти від клієнта до сервера призначення і навпаки. Потім клієнт і призначення можуть встановити власний протокол (наприклад, TLS-рукостискання для HTTPS) через цей тунель.
Варіанти використання тунельних проксі
Тунельні проксі є невід'ємною частиною різних мережевих операцій та заходів безпеки.
- HTTPS (SSL/TLS) трафік: Основний варіант використання. Браузери використовують
CONNECTдля тунелювання HTTPS-трафіку, дозволяючи зберегти наскрізне шифрування між клієнтом і веб-сервером, оскільки проксі не розшифровує вміст. - Зашифровані протоколи: Будь-який TCP-орієнтований зашифрований протокол, такий як SSH (Secure Shell), SFTP або VPN-тунелі (наприклад, OpenVPN, WireGuard), може бути маршрутизований через тунельний проксі.
- Не-HTTP протоколи: Протоколи, такі як FTP, SMTP, IMAP або спеціальні прикладні протоколи, також можуть бути тунельовані, якщо вони налаштовані на використання проксі, що підтримує метод
CONNECTабо SOCKS-проксі. - Обхід мережевих обмежень: У деяких середовищах базові брандмауери можуть блокувати прямі з'єднання до певних портів або служб. Тунельний проксі може маршрутизувати цей трафік через дозволений порт (наприклад, порт 80 або 443 для самого проксі), ефективно обходячи обмеження на основі портів.
- Підтримка конфіденційності: Оскільки проксі не перевіряє тунельований вміст, конфіденційність зв'язку між клієнтом і сервером призначення зберігається з точки зору проксі.
Тунельний проксі проти інших типів проксі
Розуміння відмінностей між тунельними проксі та іншими типами проксі має вирішальне значення для правильного розгортання та безпеки.
| Характеристика | Тунельний проксі (наприклад, HTTP CONNECT) |
Прямий проксі (не-тунелюючий HTTP) | SOCKS-проксі | Зворотний проксі |
|---|---|---|---|---|
| Рівень протоколу | Сесійний/Транспортний рівень (TCP) | Прикладний рівень (HTTP/HTTPS) | Сесійний рівень (TCP/UDP) | Прикладний рівень (HTTP/HTTPS) |
| Аналіз вмісту | Немає (дані непрозорі) | Повний (аналізує HTTP-заголовки/тіло) | Немає (дані непрозорі) | Повний (аналізує HTTP-заголовки/тіло) |
| Основне використання | HTTPS, SSH, VPN, не-HTTP TCP-з'єднання | Кешування, фільтрація, логування, контроль доступу для HTTP | Загальне TCP/UDP тунелювання, обхід брандмауерів | Балансування навантаження, завершення SSL, безпека для серверів |
| Шифрування | Зберігає наскрізне шифрування між клієнтом/призначенням | Може розшифровувати та повторно шифрувати (man-in-the-middle) для HTTPS | Зберігає наскрізне шифрування | Може завершувати SSL/TLS від клієнта, повторно шифрувати до бекенду |
| Метод запиту | CONNECT |
GET, POST, PUT тощо. |
CONNECT (SOCKS5) |
Клієнт безпосередньо запитує бекенд-сервіси |
Переваги тунельних проксі
- Безпека: Не розшифровуючи та не перевіряючи тунельований трафік, тунельні проксі підтримують цілісність протоколів наскрізного шифрування, таких як TLS, забезпечуючи конфіденційність конфіденційних даних між клієнтом і кінцевим сервером.
- Агностичний до протоколу: Після встановлення тунелю проксі байдужий до використовуваного протоколу прикладного рівня. Це дозволяє тунелювати практично будь-яку TCP-орієнтовану службу.
- Зменшене навантаження на проксі: Оскільки проксі не виконує глибокої перевірки пакетів або обробки на прикладному рівні для тунельованого трафіку, його обчислювальне навантаження нижче порівняно з проксі, що перевіряють вміст. Проксі переважно керує станами TCP-з'єднань.
- Гнучкість: Надає механізм для маршрутизації трафіку, який інакше міг би бути заблокований обмежувальними мережевими політиками, покращуючи підключення клієнтів до різноманітних служб.
Обмеження та міркування
- Відсутність перевірки вмісту: Неможливість перевіряти тунельований трафік означає, що проксі не може застосовувати політики безпеки на основі вмісту, виконувати сканування на віруси, запобігання втраті даних (DLP) або впроваджувати гранульовані засоби контролю доступу на основі даних прикладного рівня. Це може бути вразливістю безпеки, якщо не керувати належним чином.
- Ухилення від засобів контролю безпеки: Зловмисники можуть використовувати тунельні проксі для обходу мережевих пристроїв безпеки, які покладаються на перевірку вмісту (наприклад, системи виявлення/запобігання вторгнень, брандмауери веб-додатків), інкапсулюючи свій незаконний трафік у зашифрований тунель.
- Споживання ресурсів: Хоча вміст не перевіряється, підтримка великої кількості одночасних TCP-тунелів все ще споживає системні ресурси (пам'ять для станів з'єднань, відкриті файлові дескриптори, пропускна здатність мережі).
- Прозорість: Стандартні тунельні проксі є явними; клієнти повинні бути налаштовані на їх використання. Прозорі проксі зазвичай не підтримують
CONNECTбезпосередньо, але можуть перехоплювати та перенаправляти трафік таким чином, що імітує тунелювання для певних протоколів. - Застосування політики: Організації, що розгортають тунельні проксі, повинні враховувати їх наслідки для мережевої безпеки та відповідності. Політики повинні диктувати, які клієнти можуть встановлювати тунелі та до яких призначень.
Приклад конфігурації (Squid Proxy)
Налаштування проксі-сервера, такого як Squid, для дозволу тунелювання за допомогою методу CONNECT є простим. Наступний фрагмент конфігурації дозволяє CONNECT-запити до будь-якого порту на стандартному порту HTTPS (443) та порту SSH (22), а також до певного користувацького порту (8443).
# Дозволити CONNECT до стандартних портів SSL/TLS та SSH
acl SSL_ports port 443
acl SSL_ports port 22
acl SSL_ports port 8443 # Приклад для користувацького захищеного порту
# Блокувати CONNECT до інших портів
http_access deny CONNECT !SSL_ports
# Дозволити CONNECT для всього іншого трафіку
# Це правило повинно йти після конкретних правил заборони, якщо такі є
http_access allow CONNECT
Ця конфігурація гарантує, що хоча тунелювання дозволено, воно обмежене загальновживаними захищеними портами або явно дозволеними користувацькими портами, що зменшує деякі ризики, пов'язані з необмеженим тунелюванням. Для виробничих середовищ зазвичай впроваджуються більш гранульовані списки контролю доступу (ACL) для обмеження доступу клієнтів та адрес призначення.