Як обробити зашифровані та незашифровані http-з'єднання через один порт

Будь ласка, подивіться на наступну схему.

Як це має працювати?

• Коли віддалений запит http: // myhost.com:8080/*, запит повинен бути пересланий на http-сервер, який прослуховує на порту 8008 інтерфейсу петлі. Це легка частина.

• Коли віддалений користувач запитує http: // myhost.com:8080/specialurl ...

  • Програма, що діє як шлюз рівня програми, повинна мати можливість оновити з'єднання до зашифрованого сеансу ( без зміни портів )

  • Після встановлення зашифрованого сеансу за допомогою віддаленого браузера він повинен переслати запит програмі C, яка прослуховує на порту 8000 інтерфейс зворотного зв'язку.

Мої запитання :

1. Ви коли-небудь розгортали таке рішення у виробничому середовищі? Якщо у вас є...
2. Який продукт ви використовували, щоб діяти як шлюз додатків?
3. Чи можете ви надати приклад конфігурації?

Жорсткі обмеження :

• У мене немає контролю над брандмауером , і єдиний порт, через який я можу отримати зовнішній трафік на внутрішній сервер, - 8080. Номер порту не має значення, річ у тому, що на рівні брандмауера відкритий лише один порт, який пересилає вхід трафік до внутрішнього сервера.
• Внутрішній сервер повинен працювати під управлінням Linux (зараз він працює під управлінням Debian Lenny)
• Віддаленим користувачам для доступу до цього сервера не потрібно нічого, крім поточного веб-браузера та підключення до Інтернету. Це означає, що зворотне пересилання портів через SSH тут не є варіантом.
• Мені потрібен продукт, який був перевірений у виробництві і який можна легко розгорнути. Я не хочу розробити власний шлюз додатків (якби це було так, я думаю, я б задав це запитання у Stack Overflow замість того, щоб задавати це на сервер Fault).

М'які обмеження :

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

Продукти, які пробувались як шлюзи додатків (без успіху)

• nginx
• lighttpd
• фунт

Відповідні RFC

• RFC2817 (... пояснює, як використовувати механізм оновлення в HTTP / 1.1 для ініціювання безпеки транспортного рівня (TLS) через існуюче TCP-з'єднання. Це дозволяє незахищеному та захищеному HTTP-трафіку ділити той самий відомий порт ...)
• RFC2818 (... описує, як використовувати TLS для захисту HTTP-з’єднань через Інтернет. Сучасна практика полягає в тому, щоб перекривати HTTP через SSL (попередник TLS), відрізняючи захищений трафік від небезпечного трафіку за допомогою іншого порту сервера ... )

Один порт, щоб керувати ними всіма, показує, що хтось принаймні реалізував це у світі Java.

Ви коли-небудь розгортали таке рішення у виробничих умовах?

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

Тут Apache не допоможе вам. Він може слухати лише з'єднання HTTP або HTTPS (не обидва) на будь-якому даному порту.

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