Вихідний проксі та каскадування: пояснення | Налаштуйте за допомогою GProxy

Вихідний проксі (upstream proxy) — це проксі-сервер, якому інший проксі-сервер пересилає запити клієнтів, утворюючи ланцюг, де перший проксі діє як клієнт для вихідного проксі.

Що таке вихідний проксі?

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

Основні цілі використання вихідного проксі включають:

Багаторівнева безпека: Додавання додаткового рівня безпеки та контролю доступу.
Спеціалізовані функції: Делегування конкретних завдань, таких як фільтрація контенту, антивірусне сканування або розширене кешування, виділеному проксі.
Сегментація мережі: З'єднання різних сегментів мережі або надання контрольованого доступу до зовнішніх мереж.
Анонімність та конфіденційність: Приховування IP-адреси клієнта-джерела через кілька переходів.
Обхід обмежень: Маршрутизація трафіку через різні географічні розташування або мережі для обходу географічних блокувань або мережевих обмежень.
Балансування навантаження: Розподіл запитів між кількома вихідними проксі або вихідними серверами.

Потік запиту з вихідним проксі виглядає так: Клієнт -> Проксі A -> Вихідний Проксі B -> Вихідний Сервер. У цьому сценарії Проксі A налаштований використовувати Проксі B як свій вихідний проксі.

Пояснення каскадних проксі

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

Переваги каскадних проксі

Покращена безпека: Кожен проксі може застосовувати власний набір політик безпеки, автентифікації та контролю доступу.
Модульна архітектура: Різні проксі можуть спеціалізуватися на різних функціях (наприклад, один для кешування, інший для WAF, ще один для контролю вихідного трафіку).
Складна маршрутизація: Дозволяє складну логіку маршрутизації, направляючи конкретні типи трафіку через різні ланцюжки або географічні розташування.
Підвищена анонімність: Більша кількість переходів ускладнює відстеження оригінального клієнта.
Надмірність обходу: Забезпечує альтернативні шляхи, якщо один проксі в ланцюжку виходить з ладу або блокується.

Недоліки каскадних проксі

Збільшена затримка: Кожен додатковий проксі-перехід вносить затримку обробки та мережеву затримку.
Складність: Конфігурація та управління стають більш заплутаними, особливо для налагодження та усунення несправностей.
Єдині точки відмови: Якщо не спроектовано з надмірністю, відмова будь-якого проксі в ланцюжку може порушити роботу служби.
Проблеми з налагодженням: Відстеження шляху запиту та виявлення проблем може бути складним на кількох серверах.
Управління заголовками: Правильна обробка заголовків, таких як X-Forwarded-For та Via, має вирішальне значення для ведення журналів та обізнаності вихідного сервера.

Налаштування вихідного проксі

Приклади конфігурації для поширених проксі-серверів, що демонструють, як налаштувати проксі для пересилання запитів до вихідного проксі.

Nginx (як зворотний проксі для вихідного проксі)

Nginx зазвичай діє як зворотний проксі. Щоб налаштувати екземпляр Nginx для пересилання запитів до вихідного проксі, ви визначаєте адресу вихідного проксі в директиві proxy_pass у блоці location.

# Конфігурація Nginx (наприклад, proxy.example.com)
# Цей екземпляр Nginx діє як Проксі A, пересилаючи запити до Вихідного Проксі B.

http {
    upstream upstream_proxy_b {
        # Адреса вашого вихідного проксі (Проксі B)
        server 192.168.1.100:3128; # Приклад: IP та порт Проксі B
        # Необов'язково: Додайте кілька серверів для балансування навантаження/відмовостійкості, якщо Проксі B має кілька екземплярів
        # server 192.168.1.101:3128;
    }

    server {
        listen 80;
        server_name proxy.example.com;

        location / {
            # Передаємо запити до визначеного upstream_proxy_b
            proxy_pass http://upstream_proxy_b;

            # Рекомендовані заголовки для ланцюжків проксі
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Via "1.1 $hostname"; # Додаємо поточний проксі до заголовка Via
        }
    }
}

Squid (як прямий проксі для вихідного проксі)

Squid зазвичай використовується як прямий проксі. Щоб налаштувати Squid для використання вихідного проксі, ви використовуєте директиву cache_peer.

# Конфігурація Squid (наприклад, proxy-a.conf)
# Цей екземпляр Squid діє як Проксі A, пересилаючи запити до Вихідного Проксі B.

# Визначаємо вихідний проксі (Проксі B)
# Синтаксис: cache_peer hostname type http_port icp_port [options]
# type: parent або sibling (parent частіше використовується для вихідного проксі)
# http_port: HTTP-порт вихідного проксі
# icp_port: ICP-порт (зазвичай 0, якщо не використовується або невідомий)
cache_peer 192.168.1.100 parent 3128 0 no-query default_parent

# Приклад для кількох вихідних проксі (Проксі B та Проксі C)
# cache_peer 192.168.1.101 parent 3128 0 no-query round-robin
# cache_peer 192.168.1.102 parent 3128 0 no-query

# Контроль доступу, щоб дозволити клієнтам використовувати цей проксі
acl localnet src 192.168.0.0/24 # Приклад: ваша клієнтська мережа
http_access allow localnet
http_access deny all

# Вказуємо порт, на якому Squid слухає запити клієнтів
http_port 3129 # Проксі A слухає на 3129

# Необов'язково: Додати заголовок Via
via off # Squid додає заголовки Via за замовчуванням; 'off' означає, що Squid не додаватиме свій власний заголовок 'Via',
        # але він пересилатиме існуючі. Щоб переконатися, що він *додає* свій власний, видаліть цей рядок або встановіть його на 'on'.
        # Для каскадування зазвичай віддається перевага 'via on' або поведінці за замовчуванням.

У цій конфігурації Squid, proxy-a слухає на порту 3129 і пересилає всі запити на 192.168.1.100:3128 (Проксі B) завдяки опції default_parent.

Налаштування каскадних проксі

Щоб налаштувати каскадні проксі, ви налаштовуєте кожен проксі в ланцюжку, щоб він вказував на наступний.

Сценарій: Клієнт -> Проксі A -> Проксі B -> Інтернет

Цей сценарій включає два проксі в ланцюжку.

Конфігурація Проксі A (фронт-енд проксі)

Проксі A є першою точкою контакту для клієнтів і пересилає запити до Проксі B.

Nginx як Проксі A:
(Дивіться приклад Nginx у розділі "Налаштування вихідного проксі" вище. Блок upstream_proxy_b та директива proxy_pass http://upstream_proxy_b; налаштовують Nginx на надсилання запитів до Проксі B.)

Squid як Проксі A:
(Дивіться приклад Squid у розділі "Налаштування вихідного проксі" вище. Директива cache_peer 192.168.1.100 parent 3128 0 no-query default_parent налаштовує Squid на надсилання запитів до Проксі B.)

Конфігурація Проксі B (проміжний/вихідний проксі)

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

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

# Конфігурація Nginx для Проксі B (192.168.1.100)
# Цей екземпляр Nginx отримує запити від Проксі A та пересилає їх до інтернету.

http {
    server {
        listen 3128; # Проксі B слухає на 3128 запити від Проксі A
        server_name proxy-b.example.com; # Або просто слухає на IP

        location / {
            # Тут Проксі B міг би пересилати безпосередньо до джерела на основі оригінального запиту клієнта
            # Або він міг би пересилати до *іншого* вихідного проксі, якщо ланцюжок продовжується.
            # Для простоти, припускаємо, що він пересилає до інтернету на основі оригінального запиту.
            # Nginx як прямий проксі є складнішим і зазвичай включає динамічне розв'язання.
            # Більш поширений сценарій - Nginx, що діє як зворотний проксі для відомого набору джерел,
            # або для одного "наступного переходу" проксі.

            # Приклад: Якщо Проксі B пересилає до конкретного відомого джерела
            # proxy_pass http://www.example.com;

            # Якщо Проксі B має діяти як загальний прямий проксі для довільних доменів (менш поширено для Nginx)
            # Це вимагає динамічного розв'язання і часто обробляється спеціалізованими прямими проксі, такими як Squid.
            # Щоб Nginx функціонував як загальний прямий проксі, це часто включає власні Lua-скрипти або модулі.
            # Простіший Nginx Проксі B може просто передавати до *іншого* фіксованого вихідного проксі.
            # Для справжнього "інтернет" пересилання зазвичай віддається перевага Squid.

            # Якщо Проксі B є лише точкою виходу і не знає кінцевого джерела (як Squid)
            # Тут можливості Nginx як *загального призначення* прямого проксі обмежені.
            # Якщо Проксі B є Nginx, він, швидше за все, буде зворотним проксі для конкретних служб
            # або наступним переходом у визначеному ланцюжку, де наступний перехід також фіксований.
            # Для цілей каскадування, якщо Nginx є Проксі B, він зазвичай буде налаштований
            # для передачі до *відомого* наступного переходу або відомого джерела.
            # Для "загального інтернет" виходу Squid є більш доречним.

            # Припустимо, що Проксі B пересилає до відомого *кінцевого* вихідного проксі, наприклад, анонімізуючого проксі
            # або конкретного шлюзу виходу.
            proxy_pass http://final_egress_proxy:8080; # Приклад: пересилання до кінцевого проксі виходу
            # Або, якщо це останній перехід перед джерелом, і Nginx налаштований для динамічного розв'язання вихідного проксі:
            # proxy_pass $scheme://$host$request_uri; # Вимагає спеціального налаштування для динамічного прямого проксі
            # Для простоти, припустимо, що Проксі B є проксі Squid для загального доступу до інтернету.

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Via "1.1 $hostname";
        }
    }
}

Squid як Проксі B:
Проксі B отримує запити від Проксі A і налаштований або отримувати безпосередньо з інтернету, або пересилати до подальшого вихідного проксі. Якщо це останній проксі перед інтернетом, йому не потрібна директива cache_peer, що вказує на інший проксі (якщо це не для конкретних доменів або відмовостійкості).

# Конфігурація Squid для Проксі B (192.168.1.100)
# Цей екземпляр Squid отримує запити від Проксі A та отримує дані з інтернету.

# Проксі B слухає на 3128 запити від Проксі A
http_port 3128

# Необов'язково: Якщо Проксі B також має свій власний вихідний проксі (наприклад, проксі провайдера або інший конкретний проксі)
# cache_peer upstream.isp.com parent 8080 0 no-query default_parent

# Контроль доступу, щоб дозволити Проксі A (та іншим авторизованим клієнтам) підключатися
acl proxy_a_network src 192.168.1.0/24 # Приклад: мережа, де знаходиться Проксі A
http_access allow proxy_a_network
http_access deny all

# Налаштуйте кешування, ведення журналів тощо, як потрібно для Проксі B

Розширене каскадування: Умовні вихідні проксі

Для більш складної маршрутизації ви можете надсилати запити для конкретних доменів або шляхів до різних вихідних проксі.

Умовні вихідні проксі Nginx:

http {
    # Група вихідних проксі для загального трафіку
    upstream general_upstream {
        server 192.168.1.100:3128; # Проксі B
    }

    # Група вихідних проксі для конкретного конфіденційного трафіку
    upstream secure_upstream {
        server 192.168.2.200:4444; # Захищений Проксі C
    }

    server {
        listen 80;
        server_name proxy.example.com;

        location /secure/ {
            # Запити до /secure/ йдуть до Захищеного Проксі C
            proxy_pass http://secure_upstream;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location / {
            # Всі інші запити йдуть до Проксі B
            proxy_pass http://general_upstream;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

Умовні вихідні проксі Squid:

# Визначаємо кілька cache_peers
cache_peer 192.168.1.100 parent 3128 0 no-query name=general_proxy
cache_peer 192.168.2.200 parent 4444 0 no-query name=secure_proxy

# ACL для ідентифікації конкретного трафіку
acl secure_domains dstdomain .secure.example.com
acl secure_urls url_regex ^https://secure\.

# Направлення запитів на основі ACL
cache_peer_access secure_proxy allow secure_domains
cache_peer_access secure_proxy allow secure_urls
cache_peer_access general_proxy allow all

# Переконайтеся, що трафік, який не відповідає явному правилу доступу до peer, йде безпосередньо або до default_parent
# якщо default_parent не встановлено, запити можуть завершитися невдачею або йти безпосередньо на основі 'never_direct'/'always_direct'
# Зазвичай краще мати default_parent або кінцевий 'cache_peer_access' для перехоплення всіх запитів.

Ключові міркування щодо каскадних проксі

Затримка та продуктивність

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

Безпека та автентифікація

Автентифікація між проксі: Впроваджуйте автентифікацію (наприклад, білі списки IP-адрес, спільні секрети, клієнтські сертифікати) між проксі для запобігання несанкціонованому доступу до проміжних проксі.
Завершення SSL/TLS: Вирішіть, де відбувається завершення SSL/TLS. Якщо проксі розшифровують трафік, забезпечте належне управління сертифікатами та повторне шифрування для наступних переходів.
Контроль доступу: Налаштуйте суворі списки контролю доступу (ACL) на кожному проксі, щоб дозволити трафік лише від авторизованих вихідних/низхідних проксі або клієнтів.

Налагодження та усунення несправностей

Відстеження запитів через кілька проксі може бути складним.
* Заголовок X-Forwarded-For: Цей заголовок відстежує оригінальну IP-адресу клієнта та наступні IP-адреси проксі в ланцюжку. Переконайтеся, що він правильно додається на кожному переході ($proxy_add_x_forwarded_for в Nginx).
* Заголовок Via: Заголовок Via вказує проміжні проксі, через які пройшов запит. Кожен проксі повинен додавати свій ідентифікатор до цього заголовка.
* Ведення журналів: Централізоване ведення журналів та ідентифікатори кореляції є важливими для відстеження запитів по всьому ланцюжку проксі.

Балансування навантаження та відмовостійкість

Для забезпечення високої доступності та розподілу трафіку налаштуйте балансування навантаження для вихідних проксі.
* Nginx: Використовуйте блок upstream з кількома директивами server та опціями, такими як least_conn, round_robin, backup, down.
nginx upstream proxy_b_cluster { server 192.168.1.100:3128 weight=5; # Основний Проксі B server 192.168.1.101:3128 backup; # Резервний Проксі B server 192.168.1.102:3128; # Ще один Основний Проксі B least_conn; # Використовуємо метод найменшої кількості з'єднань } # Потім proxy_pass http://proxy_b_cluster;
* Squid: Використовуйте кілька директив cache_peer з опціями, такими як round-robin, weighted-round-robin, failover та no-query.
squid cache_peer 192.168.1.100 parent 3128 0 no-query weight=10 cache_peer 192.168.1.101 parent 3128 0 no-query weight=5 cache_peer 192.168.1.102 parent 3128 0 no-query round-robin

Управління заголовками

Ретельне управління HTTP-заголовками є критично важливим. Окрім X-Forwarded-For та Via, розгляньте Proxy-Authorization для автентифікації з вихідними проксі та забезпечення пересилання або видалення інших відповідних заголовків відповідно до політики.

Порівняння: Один вихідний проксі проти каскадних вихідних проксі

Функція / Аспект	Один вихідний проксі	Каскадні вихідні проксі
Складність	Низька; простіша конфігурація та управління.	Висока; складна конфігурація, управління та налагодження на кількох серверах.
Затримка	Мінімальні накладні витрати; один додатковий мережевий перехід.	Збільшені накладні витрати; кілька мережевих переходів та затримки обробки на кожен проксі.
Гнучкість	Обмежена можливостями одного проксі.	Висока; дозволяє спеціалізовані функції на кожному етапі та складну маршрутизацію.
Рівні безпеки	Один рівень безпеки та контролю доступу.	Багаторівнева безпека; кожен проксі може застосовувати різні політики.
Анонімність	Забезпечує базову анонімність від джерела.	Покращена анонімність; складніше відстежити оригінального клієнта через кілька переходів.
Налагодження	Відносно просте.	Складне; вимагає ретельного управління заголовками (`X-Forwarded-For`, `Via`) та ведення журналів.
Вплив відмови	Відмова одного вихідного проксі зупиняє весь трафік.	Відмова будь-якого проксі в ланцюжку може порушити роботу служби, якщо не налаштовано відмовостійкість.
Варіанти використання	Базова фільтрація контенту, кешування, простий контроль доступу.	Розширена безпека, відповідність вимогам, гео-маршрутизація, спеціалізовані послуги, потреби у високій анонімності.

Аналіз і перевірка

Безпека і мережа

Генератори

9 інструментів

Вихідний проксі

Наші проксі