В качестве шлюза используется FreeBSD и PF. В какой-то момент сервер под win начал странно себя вести и дропать пакеты (не все и не всегда) с внешки (все возможные файрволлы отключены, хотя поведение весьма похоже), однако внутри сети все хорошо. Нужный сервис проброшен обычным правилом rdr, который, не меняет адрес источника. Цель на текущий момент: сделать обратный nat средствами pf. Прошу подсказать, как это возможно реализовать.
PS: Понимаю, что проблему можно решить подняв vpn, но на текущий момент это, к сожалению, не возможно. На всевозможные зловреды система тоже была просканена, ничего интересного не нашлось.
man pf.conf, Luke! И ваши волосы станут мягкими и шелковистыми. Особенно в части команды, которая называется (сюрприз-сюрприз!) rdr ;-)
Цитирую:
Various types of translation are possible with pf:
binat blah-blah-blah
nat blah-blah-blah
rdr The packet is redirected to another destination and possibly a
different port. rdr rules can optionally specify port ranges
instead of single ports. rdr ... port 2000:2999 -> ... port 4000
redirects ports 2000 to 2999 (inclusive) to port 4000. rdr ...
port 2000:2999 -> ... port 4000:* redirects port 2000 to 4000, 2001
to 4001, ..., 2999 to 4999.
Перечитал man, но так и не нашел как реализовать обратный нат. Вот правило
rdr on $external_interface proto tcp from any to $external_ip port 80 -> 192.168.1.2
Теперь смотрим tcpdump на внутреннем интерфейсе:
19:45:47.199477 IP 100.2.3.4.54109 > 192.168.1.2.http: Flags [.], ack 81342, win 16317, length 0
В адресе источника остается внешний адрес и внутренний сервер его за каким-то чертом фильтрует. Под обратным натом я все же понимаю операцию обратную "прямому" нату, с подменой адреса источника на локальный.
Хотя я даже не могу придумать, зачем нужно скрывать адрес источника при подключении к внутреннему серверу. А если потребуется фильтрация на основании IP-адреса источника? Например, доступ к страницам сайта ограничивать? Или выяснять, кто и когда качал такую-то информацию?
slun: в общем, мой ответ должен сделать то, что вы хотите, но я бы посоветовал поколдовать лучше с настройками firewall на windows, ибо это он так хулиганит. Потому что при использовании NAT все клиенты будут выглядеть для web-сервера как зашедшие с одного адреса. Со всеми вытекающими.
athacker, Saenara: Да, я понимаю, что нат - костыль, и как следствие даже анализ логов хттп становится весьма нетривиальной задачей, но в данном случае это вынужденная мера. Надеюсь, временная.
Вся проблема как раз в том, что стандартный файрвол виндов отключен полностью, ничего другого не стоит, в ивент логах ни слова о том, что что-то где-то было заблокировано. Но tcpdump не может врать. Хотя, конечно, стоит попробовать еще на самом виндовом сервере посмотреть, что там с пакетами происходит.
slun: возможно это в настройках самой программы (IIS или как оно там теперь называется?) либо сайта так сделано, чтобы принимать соединения только с локальных адресов/со своей сети.
Успехов :-) Надеюсь, что "временное" решение будет именно временным вопреки известной поговорке ;-)
П.С. Ну и не забывайте отмечать ответ решением, если действительно помогло ;-)
Средний
