HTTP-проксі, SSH-тунель або VPN: виберіть правильний рівень

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

Вирішуйте за двома фактами: які протоколи мають пройти і хто може розв'язати задіяні імена. Усе інше — уподобання.

Проксі переносить лише те, що розуміє

Вебпроксі розбирає протокол, для якого його створено. Клієнт передає йому запит, а він передає запит далі, тож застосунок без налаштування проксі взагалі не бере участі. Для HTTPS клієнтові потрібен непрозорий канал, який проксі надає через CONNECT, а не читанням запиту.

Динамічне перенаправлення SSH відкриває локальний порт, що говорить SOCKS, і цей порт передає потік TCP до будь-якого місця, яке назве клієнт. Протоколи поверх TCP зазвичай працюють через нього. UDP — ні, якщо інструмент не додав підтримку явно. Локальне перенаправлення ще вужче: один локальний порт зіставлено з одним фіксованим хостом і портом, що обслуговує одну відому службу і нічого більше.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN переміщує пакети. Усе, що клієнт спрямовує в тунель, проходить через нього, включно з UDP та ICMP, тому він пасує до мережевої вимоги, а не до одного з'єднання.

Хтось має розв'язати ім'я

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

curl ясно показує поділ: один прапорець передає ім'я хоста проксі, інший спершу розв'язує його локально. За локального розв'язання внутрішнє ім'я відмовляє ще до того, як тунель буде зачеплено, і помилка звинувачує проксі в тому, що насправді було рішенням DNS.

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

Коли мережа дозволяє лише один вихід

Багато корпоративних мереж дозволяють вихідні з'єднання лише через проксі з автентифікацією. OpenVPN і SSH можна змусити працювати там: перший — тунелюючи власний транспорт через проксі, другий — через команду проксі, що запускає невеликий помічник CONNECT.

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

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

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

Підроблена адреса — не один із варіантів

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

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

Вирішуйте за протоколами та іменами

Обирайте проксі, коли одному вебклієнтові потрібна одна вебслужба і в нього є налаштування проксі. Обирайте SSH-тунель, коли достатньо кількох відомих TCP-служб і доступ через SSH уже є. Обирайте VPN, коли кілька застосунків, не-TCP трафік, приватний DNS або багаторазовий шлях входять до вимоги.

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