Завернуть трафик? Как?

Eugene

Народ доброго дня. Я вот что хотел спросить. В своё время я на Ubuntu server заворачивал трафик с 80-443 порта на порт 3128, вопрос кто нить заморачивался как здесь это сделано?
У меня возникла идея через PAT, или же есть возможность штатно сменить?

А что, собственно, нужно сделать? выглядит как простой port-forwarding.

MSubbotin

@zar0ku1:

поставь сквид прозрачный и посмотри правила pf
увидишь как это сделано

Капитан очевидность. Если не знаешь ответа просьба не писать. Я этих сквидов понаставил в своё время. Есть более осмысленный ответ на мой вопрос. В приниципе можно было бы реализовать через правила ipfw руками, но проблема в генерации их налеты при входе в webGUI.

zar0ku1

@MSubbotin:

Капитан очевидность. Если не знаешь ответа просьба не писать. Я этих сквидов понаставил в своё время. Есть более осмысленный ответ на мой вопрос. В приниципе можно было бы реализовать через правила ipfw руками, но проблема в генерации их налеты при входе в webGUI.

да, конечно есть, извини, http://www.openbsd.org/faq/pf/rdr.html

Зачем ipfw если уже есть pf?

А зачем постоянно генерировать правила при входе в webGUI?

MSubbotin

Насчёт правил, дело в том PF устроен таким образом, чтобы ты не писал в ipfw или где либо ещё как только ты в webGUI зашёл или сохранил автоматом записываются его настройки. Столкнулся с этим когда vpn делал. По умолчанию почему то к ключу добавляется невидимый в ГУИ сивмол ^M.

zar0ku1

@MSubbotin:

Насчёт правил, дело в том PF устроен таким образом, чтобы ты не писал в ipfw или где либо ещё как только ты в webGUI зашёл или сохранил автоматом записываются его настройки. Столкнулся с этим когда vpn делал. По умолчанию почему то к ключу добавляется невидимый в ГУИ сивмол ^M.

потому что из под винды правишь

MSubbotin

хм…странно, я решил проблему раками прописав ключи. Но всё же кто нить может подсказать как завернуть трафик с ЛАН портов сети на проксю?

dvserg

rdr on $iface proto tcp from any to !($iface) port 80 -> $proxybindiface port $proxyport
rdr on $iface proto tcp from any to !($iface) port 443 -> $proxybindiface port $proxyport

$iface = имя интерфейса (rl0 xl1 ..)
$proxybindiface = имя интерфейса прокси сервера (rl0 xl0 ..)
$proxyport = порт прокси сервера

Eugene

@MSubbotin:

хм…странно, я решил проблему раками прописав ключи. Но всё же кто нить может подсказать как завернуть трафик с ЛАН портов сети на проксю?

А чем Firewall->NAT->Port Froward не устраивает?

dvserg

@Eugene:

@MSubbotin:

хм…странно, я решил проблему раками прописав ключи. Но всё же кто нить может подсказать как завернуть трафик с ЛАН портов сети на проксю?

А чем Firewall->NAT->Port Froward не устраивает?

Портфорвард переадресует только то, что предназначено интерфейсу.

Eugene

@dvserg:

@Eugene:

@MSubbotin:

хм…странно, я решил проблему раками прописав ключи. Но всё же кто нить может подсказать как завернуть трафик с ЛАН портов сети на проксю?

А чем Firewall->NAT->Port Froward не устраивает?

Портфорвард переадресует только то, что предназначено интерфейсу.

Как это? А вот это что:
rdr on bge0 inet proto tcp from any to any port = cvc_hostd -> 1.1.1.3 port 443
получено через гуй.

dvserg

Какая версия (2.0 ?) и как выглядит правило в гуе? Меня в свое время бесило, когда делал хавп, что через гуй нельзя получить такое правило >:( Пришлось лезть через задний ход.

Eugene

@dvserg:

Какая версия (2.0 ?) и как выглядит правило в гуе? Меня в свое время бесило, когда делал хавп, что через гуй нельзя получить такое правило >:(

FreeBSD 1.2.3-left.local 7.2-RELEASE-p5 FreeBSD 7.2-RELEASE-p5 #0: Sun Dec 6 23:20:31 EST 2009
Вот такое правило```
rdr on bge0 inet proto tcp from any to any port = 8081 -> 1.1.1.3 port 443

Имеем для такой картинки:

![untitled.JPG](/public/_imported_attachments_/1/untitled.JPG)
![untitled.JPG_thumb](/public/_imported_attachments_/1/untitled.JPG_thumb)

dvserg

Вот блин. У меня это же в рабочем серваке настроено и работает! ППЦ!
Сори, ступил.

Поднял записи: то, что у меня вызывает(ло) проблему было с бриджем.
На нем прозрачный редирект не срабатывает. ???
Не пересекался с этим ?

Eugene

Нет. Почему-то где-то на подсознательном уровне не люблю бриджи и нигде не использую.

dvserg

@Eugene:

Нет. Почему-то где-то на подсознательном уровне не люблю бриджи и нигде не использую.

;D Причем полис-роутинг работает, вот как бы это скрестить с форвардиингом ???

Eugene

@dvserg:

@Eugene:

Нет. Почему-то где-то на подсознательном уровне не люблю бриджи и нигде не использую.

;D Причем полис-роутинг работает, вот как бы это скрестить с форвардиингом ???

Возможно off-topic, но всё же интересно - а где ты реально используешь бриджи, в каких сценариях?

dvserg

Вот одна схема такая

Офис > [pfsense bridge] > [cisco] > –--- >[GK головная компания]

Структуру сети менять нельзя, циской и каналами рулят из головы, но при этом контроля доступа в инет никакого, за исключением фильтрации (порно/развлекухи). На pfSense стоит сквид/гард + некоторые правила для контроля любителей пошариться на чужих компах. По сути из ГК не видно как трафик идет, + при падении pfSense простой перетык кабеля восстанавливает сеть в секунд, не считая отключения инета.

Michael Sh.

@Eugene:

Возможно off-topic, но всё же интересно - а где ты реально используешь бриджи, в каких сценариях?

Позволь я скажу. У меня и многих моих знакомых pfsense чаще всего используется дома, а на работе в основном Кошки - с ними спать спокойнее. ;D Люди, которым понадобился pfsense дома по определению не просто юзеры - им мало того, что дают "коробки", и у них не один комп дома, включая буки.
В этой ситуации бридж между LAN и WiFi очевиден, т.к. возня с двумя локальными подсетями в данной ситуации бессмысленна, имхо.
На данный момент в pfsense+сквид+хавп эта проблема до конца не решена. Извращениями можно кое-чего добиться, но не всего.

Eugene

@Michael:

@Eugene:

Возможно off-topic, но всё же интересно - а где ты реально используешь бриджи, в каких сценариях?

Позволь я скажу. У меня и многих моих знакомых pfsense чаще всего используется дома, а на работе в основном Кошки - с ними спать спокойнее. ;D Люди, которым понадобился pfsense дома по определению не просто юзеры - им мало того, что дают "коробки", и у них не один комп дома, включая буки.
В этой ситуации бридж между LAN и WiFi очевиден, т.к. возня с двумя локальными подсетями в данной ситуации бессмысленна, имхо.
На данный момент в pfsense+сквид+хавп эта проблема до конца не решена. Извращениями можно кое-чего добиться, но не всего.

Не будем трогать тему на счёт спокойного сна с кошками, но вот про "бридж между LAN и WiFi" - как это у тебя на железном уровне реализовано? Например, приходит ко мне провайдер кабелем CAT5…. продолжи пожалуйста.

Michael Sh.

@Eugene:

Не будем трогать тему на счёт спокойного сна с кошками, но вот про "бридж между LAN и WiFi" - как это у тебя на железном уровне реализовано? Например, приходит ко мне провайдер кабелем CAT5…. продолжи пожалуйста.

Пришёл и вторкнулся в eth порт роутера, в нашем случае пфсенса (WAN). Ещё один CAT5 вышел из роутера (назовём LAN) и попал в свитч, там размножился, часть попала на малоподвижные компы, телефонные базы и т.п., а один на WiFi access point. К нему цепляются всякие буки, наладонники, иногда телевизоры. Всё живёт в одной подсети, проблем с внутренней маршрутизацией и раздачей DHCP роутером, а так же широковещанием нет.
Учитывая, что пфсенс лёгким движением руки превращается в WiFi AP, возникает законное желание убрать железный AP, сохранив топологию.
Я прекрасно понимаю, что всё прекрасно можно настроить и без бриджа между wifi картой и LAN, но в данном случае мы ничего не выигрываем, а скорее наоборот. Способа логически объединить 2 и более eth под Фрёй, кроме как бридж я не знаю.