BSDPORTAL.RU

Есть сервер с адресами 192.168.0.1 и 192.168.1.1 на одной сетевухе. Есть комп с адресом 192.168.1.2(есс-но, в одной сети с сервером). Мне нужно написать правило переадресации: если идешь на адрес 192.168.0.2, попадаешь на этот комп с адресом 192.168.1.2. Не могу сообразить, как это сделать..

Можно через binat, если файервол pf.

Ну, а вот если я делаю прозрачный прокси? Т.е. шлюз у меня 1.1.1.1, а прозрачный прокси стоит на 1.1.1.2 и слушает порт 3128 - в этом случае как делать перенаправление? Писать вот такое на шлюзе?
rdr pass log on $int_if proto tcp from any to $ext_ip port {80,443} -> 1.1.1.2 port 3128

да.

Сделал:
rdr pass log on $int_if proto tcp from 192.168.6.178 to any port 80 -> 192.168.6.177 port 666
rdr pass log on $int_if proto tcp from 192.168.6.178 to any port 443 -> 192.168.6.177 port 666
(192.168.6.178 - тестовый комп, 192.168.6.177- сквидовский сервер.
На сквидовском сервере вижу, что приходят переадресованные пакеты и сквидовский сервер отвечает:
IP 192.168.6.177.666 > 192.168.6.178.54756: Flags [R.], seq 0, ack 386302113, win 0, length 0
IP 192.168.6.178.54757 > 192.168.6.177.666: Flags [S], seq 2723515846, win 8192, options [mss 1460,nop,nop,sackOK], length 0
В конфиге сквида строки:
http_port 666 intercept
http_port 3129
Но комп в инет не выходит- "Невозможно отобразить.." и в логах сквида пусто, как будто запросы до сквида не доходят.
Если в браузере прописать порт 3129- то нормально.

Скорее всего у вас ситуация, когда пакеты от вас уходят на сервер, оттуда на прокси, а прокси пересылает напрямую вам, а не обратно по цепочке. Что логично, так как пакеты уходят согласно маршрутизации. Тут можно посоветовать только костыль в виде NAT'a, что бы прокси "видел" вас как шлюз.

А на чем прописывать Нат? Попробовал прописать на шлюзе
nat pass on $int_if proto tcp from 192.168.6.178 to 192.168.6.177 ->192.168.6.20 - все-равно не работет(192.168.6.20- шлюз)

Да, на шлюзе.
Запускайте tcpdump и смотрите, куда и какие пакеты приходят.

Так..мне кажется- тут ошибка. Комп 6.178 стучится в инет- через Шлюз 6.20. Тот перенаправляет запрос на Сквид 6.177, который, в свою очередь запрашивает страницу через Шлюз, обрабатывает и отсылает обратно Компу- минуя Шлюз(потому что они находятся в одной сети). Если мы пропишем нат так, что Комп "притворится" Шлюзом, то получится, что Сквид получает запрос от Шлюза, потом через него же запрашивает страницу и ему же отдает ответ. Т.е. запись nat pass on $int_if proto tcp from 192.168.6.178 to any -> 192.168.6.20 не должна работать, как мне кажется(иначе фигня какая-от получается).
А запись nat pass on $int_if proto tcp from 192.168.6.178 to 192.168.6.177 ->192.168.6.20 - вообще никогда не будет работать, потому что пакеты с 6.178 на 6.177 идут напрямую- мимо шлюза.
И еще: интересно, почему Squid не обрабатывает перенаправленные пакеты? Т.е. пакеты приходят на его порт, а в его логах- пусто. Может быть, нужно на нем что-то включить, чтобы он обрабатывал такие пакеты?

Возможно.
В изначальном посте были одни IP, сейчас уже другие, поэтому за правильностью составлением правил не слежу. Почему так происходит - я изложил ранее, в посте viewtopic.php?f=13&t=29195#p179355 .
Если хотите разобраться, составьте правильную схему с указанием правильных (актуальных) IP и будем смотреть.

Я лучше на словах. Итак:
Комп 192.168.6.178
Сервер со сквидом 192.168.6.177
Шлюз 192.168.6.20
Нужно сделать прозрачный прокси. На шлюзе пишу:

rdr pass log on $int_if proto tcp from 192.168.6.178 to any port 80 -> 192.168.6.177 port 666
rdr pass log on $int_if proto tcp from 192.168.6.178 to any port 443 -> 192.168.6.177 port 666

Вижу, что на сервер сквида приходят пакеты от компа и сервер посылает ответные пакеты, но при этом в логах сквида- пусто.

При таких условиях через firewall не выйдет, потому как вам надо сразу выполнять и redirect и nat, а в одном правиле этого не сделать. Тут на помощь должны придти сторонние утилиты (есть в портах) типа redir, rinetd которые при перенаправлении пакета подменяют src addr, что как раз в вашем случае и нужно.

Почитал про них. В этом случае это не очень удобно, потому что потом в логах сквида не будет видно, от кого пришли пакеты. А вот в случаях, когда это неважно- это да- самое то.

Ну тогда либо поднимать прокси на шлюзе, либо использовать непрозрачный прокси.

Нужен как раз прозрачный не на шлюзе. Я еще читал, что можно попробовать разместить проксю и компы в разных сетях. Т.е. так:
Комп 192.168.0.34, шлюз 192.168.0.20
Сервер со сквидом 192.168.6.177, шлюз 192.168.6.20
Сервер со шлюзом: 192.168.6.20 и 192.168.0.20
На шлюзе:
rdr pass log on $int_if proto tcp from 192.168.0.34 to {!192.168.0.0/24, !192.168.6.0/24} port 80 -> 192.168.6.177 port 3131
rdr pass log on $int_if proto tcp from 192.168.0.34 to {!192.168.0.0/24, !192.168.6.0/24} port 443 -> 192.168.6.177 port 3131
Переадресация отрабатывает: rdr in on re0: 192.168.0.34.58392 > 192.168.6.177.3131
В access.log в сквиде пишет:
1623761233.682 22 192.168.6.177 TCP_MISS/403 4853 GET http://multi-up.com/1272600 - HIER_NONE/- text/html
1623761233.714 77 192.168.0.34 TCP_MISS/403 4983 GET http://multi-up.com/1272600 - ORIGINAL_DST/192.168.6.177 text/html
1623761243.437 23 192.168.6.177 TCP_MISS/403 4794 GET http://multi-up.com/favicon.ico - HIER_NONE/- text/html
1623761243.469 78 192.168.0.34 TCP_MISS/403 4924 GET http://multi-up.com/favicon.ico - ORIGINAL_DST/192.168.6.177 text/htm
а в браузере:
Система контроля доступа не позволяет выполнить ваш запрос сейчас. Обратитесь к вашему администратору.
Хотя у меня там тестовый конфиг, в котором всем все разрешено.

Разобрался. Смотрим squid -v
и видим интересную штуку: '--enable-ipfw-transparent' и '--disable-pf-transparent'.
Т.е. сквид в этом виде не поддерживает переадресацию через PF, а вот через IPFW- да.
Т.к. это- рабочий сервер, переустанавливать сквид с поддержкой PF я не стал, а вместо этого:
в rc.conf добавил
firewall_enable="YES"
firewall_type="open"
firewall_script="/etc/ipfw.rules"

В /etc/ipfw.rules добавил:
ipfw add 51 fwd 127.0.0.1,3131 all from 192.168.6.18 to any 80
ipfw add 52 fwd 127.0.0.1,3132 all from 192.168.6.18 to any 443
ipfw add 65000 allow ip from any to any

Последняя строка- обязательна, иначе пропадет доступ к серверу.
Для обновления настроек IPFW лучше всего сделать исполняемый файл такого содержания:
ipfw flash
service ipfw restart
ipfw add 65000 allow ip from any to any
Тогда в случае ошибок в конфиге сервер не отрубится от сети.
Если прозрачный прокси у вас не на шлюзе, то:
на проксевом сервере прописываем:

ipfw add 51 fwd 127.0.0.1,3131 all from 192.168.6.18 to any 80
ipfw add 52 fwd 127.0.0.1,3132 all from 192.168.6.18 to any 443
ipfw add 65000 allow ip from any to any

а на шлюзе:
ipfw add 51 fwd Адрес_прокси,3131 all from 192.168.6.18 to any 80
ipfw add 52 fwd Адрес_прокси,3132 all from 192.168.6.18 to any 443
ipfw add 65000 allow ip from any to any

И все работает- я проверял.
Т.к. у меня сквид работает по http и https- поэтому тут две строчки- для 80 и 443 портов.
Сквид работает одновременно в прозрачном и обычном режимах. В обычном режиме есть авторизация,
плюс https-ный трафик расшифровывается и есть возможность резать скорость, но нужно устанавливать
на каждом компе сертификат сквида.
В непрозрачном- не расшифровывается, поэтому сертификат устанавливать не надо,скорость не режется, тем не менее в логе видно,
куда с какого айпишника ходили и сколько скачали- т.е. можно смотреть статистику тем же SARG-ом.
192.168.6.18 - это тот, кого нужно перенаправить на прозрачный прокси. Можно добавить строки для каждого IP,
можно прописать сразу всю сеть, можно- список из файла(яндексим "ipfw table").

В общем, выяснилось, что при такой схеме не грузятся файлы в ВК и Ватсап. В access.log вижу такие строки:
1626446543.718 285942 192.168.6.18 TCP_TUNNEL_ABORTED/200 5368 CONNECT 87.240.137.139:443 - ORIGINAL_DST/87.240.137.139 -
87.240.137.139 - это один серверов ВК. Ощущение, что ipfw запускает переадресацию на мой прокси, а потом ее разрывает.