У нас есть прокси-сервер в нашей внутренней сети, и я хочу перенаправить все интернет-запросы http на веб-сервер в локальной сети. Это будет похоже на сетевой щит с надписью «Прямое соединение недоступно. Настройте прокси-сервер и т. Д.» Например:
Я добавил простое ручное правило NAT для преобразования адресов в брандмауэре Checkpoint, но оно просто не работает. Вот мое правило трансляции адресов
Source Destination Service T.Source T.Destination T.Service
MY_PC A_GOOGLE_IP ALL ORIGINAL INT_WEB_SRV ORIGINAL
Затем, когда я пингую A_GOOGLE_IP
, ответы приходят от INT_WEB_SRV
, как я и предполагал. Однако, когда я пытаюсь подключиться A_GOOGLE_IP
из браузера (http: // A_GOOGLE_IP), от SYN_SENT не приходит никаких ответов, и время ожидания истекает. Когда я смотрю журнал брандмауэра INT_WEB_SRV
, Я вижу, что входящие запросы на соединение от MY_PC принимаются и НЕТ отклоняют. Между прочим, нет проблем увидеть INT_WEB_SRV
(http: // INT_WEB_SRV) из браузера.
Насколько я понимаю, мое правило NAT на контрольной точке NGX R60 не включает ответные пакеты. Мне определенно нужна помощь.
При возникновении проблем с NAT я всегда начинаю с открытия пары сеансов SSH и выполнения tcpdump как на внутреннем, так и на внешнем интерфейсах.
что-то вроде:
tcpdump -i eth0 proto ICMP
или
tcpdump -i eth0 host A_GOOGLE_IP
и посмотрите, какой у вас IP-адрес. Это должно дать вам хотя бы с чего начать!
Если внутренний сервер находится в той же подсети, что и клиент, вам необходимо выполнить SNAT, а также DNAT, потому что теперь вот как это работает.
iptables -t nat -A PREROUTING -i LAN_IFACE -d A_GOOGLE_IP -j DNAT --to-destination INT_WEB_SRV
Если у вас SNAT, то он работает так:
iptables -t nat -A PREROUTING -i LAN_IFACE -d A_GOOGLE_IP -j DNAT --to-destination INT_WEB_SRV
iptables -t nat -A POSTROUTING -s LAN_RANGE/mask -d INT_WEB_SRV -j SNAT --to-source ROUTER_IP
Однако, если все, что вы хотите сделать, это принудительно использовать прокси для всех, просто DNAT все исходящие HTTP-соединения с прокси-сервером (вы получите так называемый прозрачный прокси), и клиентам не нужно будет изменять настройки на своих компьютерах. .
Обратный трафик в КПП должен быть налажен. Отображается ли трафик в журнале сервера на веб-сервере? Кроме того, стоит использовать fw monitor, чтобы убедиться, что контрольная точка правильно настроена и передает трафик в обе стороны, с чем-то вроде
fw monitor -e 'accept (src=<host address> and dport=80) or (dst=<host address> and sport=80);'
Это должно показать 4 строки для каждого пакета, включая адреса до и после NAT.