Подключение сервера Proxmox к самому себе

Вопрос или проблема

Проблема подключения к серверу Proxmox

Здравствуйте, у меня есть сервер Proxmox с 3 виртуальными машинами для упрощения:

  1. Обратный прокси nginx (www.exemple.com и dev.exemple.com)
  2. Apache 2 + php (www.exemple.com)
  3. Apache 2 + php (dev.exemple.com)

Сервер Proxmox настроен с NAT для маршрутизации подключений с портов 80 и 443 на обратный прокси.

Далее обратный прокси распределяет запросы на бекенды Apache.

У меня есть проблема с запросами между серверами. Я хотел бы использовать модуль миграции Prestashop Pro.

Но соединение не устанавливается между двумя сайтами.

После расследования оказалось, что виртуальная машина, а также сервер Proxmox не могут получить доступ к https://www.exemple.com/modules/migrationproserver/server.php и https://www.exemple.com/

Я проверил DNS, он соответствует IP-адресу сервера.

cURL с другого сервера работает:

C:\> curl -v https://www.exemple.com/modules/migrationproserver/server.php
* Узел www.exemple.com:443 разрешен.
* IPv6: (нет)
* IPv4: xxx.xxx.xxx.xxx
*   Попытка xxx.xxx.xxx.xxx:443...
* Соединено с www.exemple.com (xxx.xxx.xxx.xxx) порт 443
* schannel: автоматическое использование клиентского сертификата отключено
* ALPN: curl предлагает http/1.1
* ALPN: сервер принял http/1.1
* используется HTTP/1.x
> GET /modules/migrationproserver/server.php HTTP/1.1
> Host: www.exemple.com
> User-Agent: curl/8.9.1
> Accept: */*
>
* Запрос полностью отправлен
* schannel: удаленная сторона запрашивает повторнуюNegotiation
* schannel: повторная переговоры SSL/TLS соединения
* schannel: SSL/TLS соединение повторно согласовано
* schannel: удаленная сторона запрашивает повторнуюNegotiation
* schannel: повторная переговоры SSL/TLS соединения
* schannel: SSL/TLS соединение повторно согласовано
< HTTP/1.1 200 OK
< Сервер: nginx/1.22.1
< Дата: Чт, 21 Ноя 2024 12:33:20 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: 5a2c67b4928ffe5745bb882ad7942d17=XwDTzVCEzzMm3UA4vOLuv81xMCyKsabetDswldDY8yZL1JIpYMBkBPzSX%2Fq2BoRQHDovD6KycOnENbvlEbFRHxsE%2FVkDK36BNwxFdNgMhHw%3D000075; expires=Ср, 11-Дек-2024 12:33:20 GMT; Max-Age=1728000; path=/; Secure; HttpOnly; domain=www.exemple.com; httponly
< Vary: Accept-Encoding
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT
< Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT
< Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< Access-Control-Allow-Credentials: true
<
eyJzdGF0dXMiOiJlcnJvciIsIm1lc3NhZ2UiOiJUaGUgYnJpZGdlIGNvbm5lY3RvciBtb2R1bGUgZ2VuZXJhdGVkIGZvciBkZXYuc2VudGllci1uYXR1cmUuZnIhIFBsZWFzZSwgZG93bmxvYWQgYWdhaW4gYnJpZGdlIGNvbm5lY3RvciBtb2R1bGUgYW5kIGluc3RhbGwgdG8gdGhlIFNvdXJjZSBzaG9wIChvbGQgc2hvcCkgYW5kIHRyeSBjb25uZWN0aW9uIGFnYWluLiIsImNvbnRlbnQiOm51bGx9* Соединение #0 с хостом www.exemple.com осталось целым

но не с сервера Proxmox, например:

root@px1:~# curl -i -v https://www.exmple.com/modules/migrationproserver/server.php
*   Попытка xxx.xxx.xxx.xxx:443...
* не удалось подключиться к xxx.xxx.xxx.xxx порт 443: Соединение отклонено
* Не удалось подключиться к www.exemple.com порт 443 после 10 мс: не удалось подключиться к серверу
* Закрытие соединения 0
curl: (7) Не удалось подключиться к www.exemple.com порт 443 после 10 мс: не удалось подключиться к серверу

Работает, если проходить через частный адрес виртуальной машины, указывая доменное имя, чтобы nginx перенаправил на правильный бекенд:

root@px1:~# curl -v -k -H "Host: www.exemple.com" https://192.168.0.2/modules/migrationproserver/server.php
*   Попытка 192.168.0.2:443...
* Соединено с 192.168.0.2 (192.168.0.2) порт 443 (#0)
* ALPN: предлагает h2,http/1.1
* TLSv1.3 (OUT), TLS согласование, Приветствие клиента (1):
* TLSv1.3 (IN), TLS согласование, Приветствие сервера (2):
* TLSv1.3 (IN), TLS согласование, Шифрованные расширения (8):
* TLSv1.3 (IN), TLS согласование, Сертификат (11):
* TLSv1.3 (IN), TLS согласование, Проверка сертификата (15):
* TLSv1.3 (IN), TLS согласование, Завершено (20):
* TLSv1.3 (OUT), TLS изменение шифра, Изменение шифра спецификации (1):
* TLSv1.3 (OUT), TLS согласование, Завершено (20):
* SSL-соединение с использованием TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: сервер принял http/1.1
* Сертификат сервера:
*  субъект: CN=dev.exemple.com
*  дата начала: Ноя  2 13:11:32 2024 GMT
*  дата окончания: Янв 31 13:11:31 2025 GMT
*  издатель: C=US; O=Let's Encrypt; CN=E6
*  Результат проверки SSL-сертификата: не удалось получить сертификат местного издателя (20), продолжаем все равно.
* используется HTTP/1.1
> GET /modules/migrationproserver/server.php HTTP/1.1
> Host: www.exemple.com
> User-Agent: curl/7.88.1
> Accept: */*
>
* TLSv1.3 (IN), TLS согласование, Новый билет сеанса (4):
* TLSv1.3 (IN), TLS согласование, Новый билет сеанса (4):
* старый идентификатор SSL-сессии устарел, удаление
< HTTP/1.1 200 OK
< Сервер: nginx/1.22.1
< Дата: Чт, 21 Ноя 2024 13:30:28 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: 5a2c67b4928ffe5745bb882ad7942d17=XwDTzVCEzzMm3UA4vOLuv%2ByNk%2F9eC0XevBxQW1yr%2FDRL1JIpYMBkBPzSX%2Fq2BoRQHDovD6KycOnENbvlEbFRHxy4Q2cfWeX46zjsvWshXK4%3D000075; expires=Ср, 11-Дек-2024 13:30:28 GMT; Max-Age=1728000; path=/; Secure; HttpOnly; domain=www.exemple.com; httponly
< Vary: Accept-Encoding
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT
< Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT
< Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< Access-Control-Allow-Credentials: true
<
* Соединение #0 с хостом 192.168.0.2 осталось целым
eyJzdGF0dXMiOiJlcnJvciIsIm1lc3NhZ2UiOiJUaGUgYnJpZGdlIGNvbm5lY3RvciBtb2R1bGUgZ2VuZXJhdGVkIGZvciBkZXYuc2VudGllci1uYXR1cmUuZnIhIFBsZWFzZSwgZG93bmxvYWQgYWdhaW4gYnJpZGdlIGNvbm5lY3RvciBtb2R1bGUgYW5kIGluc3RhbGwgdG8gdGhlIFNvdXJjZSBzaG9wIChvbGQgc2hvcCkgYW5kIHRyeSBjb25uZWN0aW9uIGFnYWluLiIsImNvbnRlbnQiOm51bGx9root@px1:~#

но, тем не менее, он говорит о сертификате для dev, а не www.

Я немного запутался, возможно, это проблема NAT, поскольку это работает снаружи сервера Proxmox…

Вот конфигурация NAT:

root@px1:~# iptables -L -t nat
Цепь PREROUTING (политика ACCEPT)
цель     протокол опции источник               назначение
DNAT       tcp  --  везде             везде             tcp dpt:http to:192.168.0.2:80
DNAT       tcp  --  везде             везде             tcp dpt:https to:192.168.0.2:443

Цепь INPUT (политика ACCEPT)
цель     протокол опции источник               назначение

Цепь OUTPUT (политика ACCEPT)
цель     протокол опции источник               назначение

Цепь POSTROUTING (политика ACCEPT)
цель     протокол опции источник               назначение
MASQUERADE  все  --  192.168.0.0/24       везде

Спасибо заранее за ваши идеи!

Ответ или решение

Ошибка подключения сервера Proxmox к себе

Здравствуйте!

Ваше описание проблемы с подключением к Proxmox серверу и виртуальным машинам (ВМ) дает важные подсказки о том, где могут быть корни проблемы. Давайте глубже проанализируем ситуацию и обсудим возможные решения.

Описание проблемы

Вы установили Proxmox сервер, который управляет тремя ВМ, где:

  1. Reverse Proxy Nginx (обрабатывает www.exemple.com и dev.exemple.com)
  2. Apache 2 + PHP (для www.exemple.com)
  3. Apache 2 + PHP (для dev.exemple.com)

Сервер настроен с использованием NAT для маршрутизации соединений на порты 80 и 443 к обратному прокси, который, в свою очередь, направляет запросы к бэкендам Apache.

Возникающая проблема заключается в том, что запросы между вашими серверами, в частности модули, такие как PrestaShop Migration Pro, не выполняются должным образом, и две ВМ не могут напрямую обращаться к домену www.exemple.com.

Анализ проблемы

Вы проверили DNS, и он соответствует IP адресу сервера. Успешный curl с внешнего сервера показывает, что домены доступны и корректно функционируют. Интересно, что запросы не проходят с самого Proxmox сервера, где вы получаете ошибку:

* connect to xxx.xxx.xxx.xxx port 443 failed: Connexion refusée

Получение ответа через внутренний IP вашего бэкенда указывает на то, что обращение с внутренней сети работает, однако внешние запросы не проходят.

Возможные причины

  1. Проблемы с NAT: Поскольку вы используете NAT, важно удостовериться, что запросы, исходящие из самого Proxmox сервера, правильно направляются через NAT. Это может быть связано с настройками iptables.

  2. Настройки iptables: Ваши правила NAT настроены, но важно оценить правила на системном уровне, чтобы убедиться, что пакеты, идущие от Proxmox к внешнему IP, не блокируются.

  3. Проблемы с SSL-сертификатом: Поскольку у вас есть два разных поддомена, существует вероятность конфликта с сертификатами, если один из них не настроен должным образом.

Рекомендованные действия

  1. Проверка NAT:

    • Убедитесь, что правила iptables позволяют возвращающиеся пакеты, настроив соответствующие цепочки.
    • Для отладки используйте tcpdump на интерфейсе, чтобы отслеживать трафик.
  2. Проверка конфигурации Nginx:

    • Убедитесь, что в конфигурации Nginx правильно настроены server_name и проксирование для обоих доменов. Удостоверьтесь, что он слушает как на IPv4, так и на IPv6 (если включен).
  3. Отладка SSL:

    • Проверьте, что сохранить и правильно настроить SSL-сертификаты как для www.exemple.com, так и для dev.exemple.com. Возможно, стоит установить сертификаты от Let’s Encrypt для обоих доменов.
  4. Использование curl с флагами:

    • Попробуйте запустить curl с указанием флага -H "Host: www.exemple.com" для имитации запроса через Nginx, как вы делали ранее. Анализируйте, каким образом Nginx обрабатывает эти запросы.
  5. Логи и мониторинг:

    • Просматривайте журналы как на стороне Nginx, так и на стороне Apache, чтобы выявить возможные ошибки или проблемы с соединениями.
  6. Использование локального DNS:

    • Возможно, стоит рассмотреть настройку локального DNS (например, с помощью dnsmasq) для разработки, чтобы упростить тестирование запросов внутри сети.

Заключение

Решение вашей проблемы требует всесторонней диагностики как на уровне сети, так и на уровне приложений. Поскольку у вас уже налажена работа через IP адреса, вам нужно сфокусироваться на конфигурациях NAT, сетевых правилах и SSL-сертификатах.

При следовании рекомендациям по отладке и дополнительным тестированием, вы сможете выявить коренные причины и исправить проблему. Если у вас возникнут дополнительные вопросы или понадобятся дальнейшие разъяснения по конкретным шагам, не стесняйтесь обращаться. Успехов в устранении проблемы!

Оцените материал
Добавить комментарий

Капча загружается...