NetWorker: AUTHC-з'єднання не виходять з ладу через HTTP 400 або 403 Помилка
Summary: Підключення до сервісу автентифікації NetWorker (AUTHC) не працюють. Помилки, про які повідомляються, — це HTTP 400 (поганий запит) або HTTP 403 (заборонено).
Symptoms
Мережевий працівник nsrlogin команда не працює з HTTP 400 або 403:
nsrlogin -u administrator
130136:nsrlogin: Please enter password:
117849:nsrlogin: Authentication library error: CONNECT tunnel failed, response 403
Server Message : Make sure that server is running
Або:
nsrlogin -u Administrator
130136:nsrlogin: Please enter password:
117849:nsrlogin: Authentication library error: CONNECT tunnel failed, response 400
Server Message : Make sure that server is running
Автентифікація NetWorker та інші спроби підключитися до сервісу автентифікації зазнають подібних помилок.
nsrauthtrust -H NETWORKER_SERVER_NAME -P 9090
125927:nsrauthtrust: Failed to retrieve certificate: CONNECT tunnel failed, response 403
Оновлення NetWorker Management Console (NMC) та NetWorker Web User Interface (NWUI) (Windows) та післямодернізації скриптів (Linux) повідомляють про збої з'єднання на AUTHC-порті.
Cause
Ця проблема виникає поза межами NetWorker. Мережевий працівник nsrlogin команда також повідомляла про "Connect Tunnel Failed", оскільки в середовищі налаштовано HTTPS-проксі. Це можна перевірити за допомогою curl КОМАНДУВАННЯ:
curl https://NETWORKER_SERVER_ADDRESS:9090
curl -v https://NETWORKER_SERVER_ADDRESS:9090 * Rebuilt URL to: https://NETWORKER_SERVER_ADDRESS:9090/ * Uses proxy env variable no_proxy == 'HTTP_PROXY_HOSTNAME' * Uses proxy env variable https_proxy == 'http://HTTP_PROXY_HOSTNAME:8080' * Trying HTTP_PROXY_IP... * TCP_NODELAY set * Connected to HTTP_PROXY_HOSTNAME (HTTP_PROXY_IP) port 8080 (#0) * allocate connect buffer! * Establish HTTP proxy tunnel to NETWORKER_SERVER_ADDRESS:9090 > CONNECT NETWORKER_SERVER_ADDRESS:9090 HTTP/1.1 > Host: NETWORKER_SERVER_ADDRESS:9090 > User-Agent: curl/7.61.1 > Proxy-Connection: Keep-Alive < HTTP/1.1 403 Forbidden < Server: squid/3.5.20 < Mime-Version: 1.0 < Date: Thu, 03 Jul 2025 15:36:25 GMT < Content-Type: text/html;charset=utf-8 < Content-Length: 3548 < X-Squid-Error: ERR_ACCESS_DENIED 0 < Vary: Accept-Language < X-Cache: MISS from HTTP_PROXY_HOSTNAME < X-Cache-Lookup: NONE from HTTP_PROXY_HOSTNAME:8080 < Via: 1.1 HTTP_PROXY_HOSTNAME (squid/3.5.20) < Proxy-Connection: Keep-Alive * Received HTTP code 403 from proxy after CONNECT * Closing connection 0 * Curl: (56) Received HTTP code 403 from proxy after CONNECT
Або:
curl -v https://NETWORKER_SERVER_ADDRESS:9090 * Uses proxy env variable https_proxy == 'http://HTTP_PROXY_HOSTNAME:443' * Trying HTTP_PROXY_IP:443... * Connected to HTTP_PROXY_HOSTNAME (HTTP_PROXY_IP) port 443 (#0) * allocate connect buffer! * Establish HTTP proxy tunnel to NETWORKER_SERVER_ADDRESS:9090 > CONNECT NETWORKER_SERVER_ADDRESS:9090 HTTP/1.1 > Host: NETWORKER_SERVER_ADDRESS:9090 > User-Agent: curl/7.76.1 > Proxy-Connection: Keep-Alive > < HTTP/1.1 400 Bad Request < Server: openresty < Date: Thu, 03 Jul 2025 14:11:12 GMT < Content-Type: text/html < Content-Length: 154 < Connection: close < * Received HTTP code 400 from proxy after CONNECT * CONNECT phase completed! * Closing connection 0
Конкретна помилка, що повертається, може змінюватися залежно від конкретного постачальника проксі та конфігурації. Спільним є те, що ви бачите, як зв'язок із портом автентифікації NetWorker (AUTHC) (за замовчуванням 9090) перенаправляється через HTTPS-проксі-хост. Повернена помилка є помилкою HTTP 4xx; або 400 (поганий запит), або 403 (заборонено).
Resolution
Використання HTTPS-проксі, спеціально для автентифікаційного трафіку на порті 9090, явно не документується і не тестується як підтримувана конфігурація. Компоненти NetWorker зазвичай очікують прямого зв'язку між сервісами, особливо для автентифікації.
Видаліть конфігурацію проксі HTTP/HTTPS на сервері NetWorker. Це також має бути видалене з будь-якого NetWorker-хоста, що спілкується з портом 9090 на сервері NetWorker. Див. також: Процеси та порти NetWorker
На сервері NetWorker виконано:
unset https_proxy unset http_proxy
curl вихід з'єднання. Якщо змінні не вдається ідентифікувати, зверніться до системного адміністратора або до документації постачальника проксі. Додаткові зміни можуть знадобитися для вимкнення HTTPS-проксі-запитів. Ці конфігурації є зовнішніми для програмного забезпечення або конфігурацій NetWorker.
Коли змінні не встановлені, спробуйте nsrlogin знову. Якщо вдасться — біжіть nsrlogout.
[admin@lnx-srvr01 root]$ nsrlogin -u Administrator 130136:nsrlogin: Please enter password: Authentication succeeded [admin@lnx-srvr01 root]$ nsrlogout
Це свідчить про функціональність комунікації з сервісом AUTHC NetWorker. Очікується, що інші процеси, пов'язані з автентифікацією NetWorker або комунікацією через порт 9090, будуть успішними.
Additional Information
The unset Command знімає змінну лише для поточної сесії shell. Якщо встановити як системні або профільні змінні, вони автоматично завантажуються при відкритті терміналу, перезавантаженні системи або запуску нової shell-сесії. Необхідно виконати наступні дії, щоб запобігти завантаженню змінних на наступній сесії або перезавантаженні.
Windows: перевірте змінні SYSTEM або USER і видаліть будь-які змінні, які використовуються для визначення проксі-хоста HTTP/HTTPS.
Linux: Перевірте наступні файли на наявність налаштувань змінних HTTP/HTTPS і видаліть їх:
- ~/.bashrc
- ~/.bash_profile
- ~/.профілю
- /тощо/середовище
- /etc/profile
- /etc/profile.d/*.sh