Обратный прокси Squid, DMZ, как переслать любой не-http запрос

1022
Kaël

Я на самом деле сталкиваюсь с проблемой с некоторой проблемой, связанной с сетевым протоколом.

У меня есть свой собственный домен, собственная DMZ и внешние пользователи. В моей DMZ у меня есть обратный прокси, который очень хорошо обрабатывает HTTP-соединение. Мой внешний пользователь может поразить мой внутренний веб-сервер.

Однако я хотел бы знать, возможно ли, чтобы мой Squid делал то же самое с запросом MSSQL / PGSQL (или, более того, с любым типом соединения).

Как и мой внешний клиент, подключив мой обратный прокси-сервер, который будет просто cache_peer на моем реальном сервере?

С уважением.

0
Я не могу представить веб-прокси, обрабатывающий запрос к серверу sql. Если, например, у вас есть запросы sql на порт 80 (что странно), то, возможно, вам нужен какой-то сервер, который проверяет тип запроса и пересылает на правильный сервер. barlop 8 лет назад 0
Да, это было очень странное решение, но у меня был плохой выбор ... тогда netfilter был моим единственным решением на данный момент. :) Kaël 7 лет назад 0
ты тогда использовал iptables? Вы можете ответить на свой собственный вопрос, указав, какие правила iptables вы использовали, это было бы полезно для людей, и вы можете принять свой собственный ответ. Вы делали глубокую проверку пакетов? звучит интересно barlop 7 лет назад 0
К сожалению, это была только предварительная пересылка на нужный сервер. Единственная безопасность, которую я имел, была источником / назначением. С точки зрения аппликативного, только сервер, принимающий пакеты, мог проверить целостность. Kaël 7 лет назад 0

1 ответ на вопрос

1
Kaël

Из-за окружения, мой единственный выбор был сделать пересылку в формате raw, используя iptables.

Поскольку у нас не было DPI, все было вперед в зависимости от 3 фильтров:

  • Источник
  • Место назначения
  • порт

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


# My SQL try to contact the dest. SQL (who is in fact, my proxy) so I changed the destination to the real one iptables -t nat -A PREROUTING -i eth0 -s [YOUR_INTERNAL_SERVER] -p tcp --dport 15432 -j DNAT --to-destination [YOUR_DESTINATION_SERVER]  # Little restriction iptables -t filter -A FORWARD -p tcp --dport 15432 -m state --state NEW -j ACCEPT iptables -t filter -A FORWARD -p tcp --dport 15432 -m state --state ESTABLISHED -j ACCEPT iptables -t filter -A FORWARD -p tcp --sport 15432 -m state --state ESTABLISHED -j ACCEPT  # If they contact my SQL, I set the source as my relay so my server could reply back. iptables -t nat -A POSTROUTING -o eth0 -d [YOUR_INTERNAL_SERVER] -p tcp --dport 15432 -j SNAT --to-source [YOUR_PROXY]