Як публічний проксі потрапляє до приватного джерела через VPN

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

Дві моделі, які на схемі виглядають однаково

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

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

Де зупиняється TLS і що вона насправді доводить

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

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

Довіряйте переданим заголовкам лише від проксі

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

Тримайте джерело доступним рівно з одного місця

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

ss -ltnp | grep -E ':(80|443)'

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