Ручной NAT на контрольной точке (перенаправить все http-запросы на локальный веб-сервер)
У нас есть прокси-сервер во внутренней сети, и я хочу перенаправить все интернет-http-запросы на веб-сервер в локальной сети. Это будет похоже на сетевой рекламный щит с надписью "Прямое соединение недоступно. Настройте прокси-сервер и т. Д." Например:
- Пользователь запускает компьютер
- Открывает браузер
- Пытается открыть www.google.com
- Должен видеть выход веб-сервера в локальной сети
- Пытается другой веб-сайт в Интернете
- Должен видеть выход веб-сервера в локальной сети
- Настраивает прокси
- Пытается подключиться к веб-сайту
- Веб-сайт должен быть загружен
Я добавил простое ручное правило 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 не включает в себя возвратные пакеты. Мне определенно нужна помощь.
3 ответа
Когда я сталкиваюсь с проблемами NAT, я всегда начинаю с пары SSH-сессий и выполняю tcpdumps на внутреннем и внешнем интерфейсах.
что-то вроде:
tcpdump -i eth0 proto ICMP
или же
tcpdump -i eth0 host A_GOOGLE_IP
и смотреть, чтобы увидеть, что IP-адрес Nat'd. Это должно, по крайней мере, дать вам возможность начать!
Если внутренний сервер находится в той же подсети, что и клиент, вам нужно выполнить SNAT, а также DNAT, потому что теперь вот как это работает.
iptables -t nat -A PREROUTING -i LAN_IFACE -d A_GOOGLE_IP -j DNAT --to-destination INT_WEB_SRV
- Клиентский ПК отправляет TCP SYN на A_GOOGLE_IP
- Маршрутизатор DNATs это к INT_WEB_SRV
- INT_WEB_SRV видит запрос, поступающий от IP-адреса локальной сети, и отвечает напрямую
- Клиент получает ответ от INT_WEB_SRV IP, а не A_GOOGLE_IP
Если вы 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
- Клиентский ПК отправляет TCP SYN на A_GOOGLE_IP
- Маршрутизатор DNAT передает его INT_WEB_SRV, заменяя исходный IP своим собственным IP
- INT_WEB_SRV видит запрос от маршрутизатора и отвечает на него.
- Маршрутизаторы DNAT отправляют пакет на клиентский ПК и заменяют исходный IP-адрес на A_GOOGLE_IP
- Клиент думает, что это связано с A_GOOGLE_IP
Однако, если все, что вам нужно, это принудительно использовать прокси-сервер для всех, просто DNAT всех исходящих HTTP-подключений к прокси-серверу (вы получите то, что называется прозрачным прокси-сервером), и клиентам не нужно будет менять настройки на своих компьютерах.,
Обратный трафик в контрольной точке должен быть натированным. Отображается ли трафик в журнале сервера на веб-сервере? Кроме того, стоит использовать fw monitor, чтобы убедиться, что контрольная точка корректно работает и пропускает трафик в обе стороны, с чем-то вроде
fw monitor -e 'accept (src=<host address> and dport=80) or (dst=<host address> and sport=80);'
Это должно показать 4 строки для каждого пакета, включая адреса до и после NAT.