ARP-проксирование.

День добрый.
Пытаюсь настроить ARP-проксирование на FreeBSD 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789, не получается.

Ситуация следующая.
Сервер смотрит одним интерфейсом в локальную сеть (192.168.0.0/22), другим - непосредственно на один компьютер (192.168.1.210/22). Адреса у сервера 1.222 и 1.223 соответственно.
Наглядно выглядит так
http://cs617622.vk.me/v617622138/20bdf/LdNAroJ670M.jpg

Вот вывод arp -a

? (192.168.1.223) at 9c:8e:99:19:64:7b on igb1 permanent [ethernet]
? (192.168.1.210) at 00:0d:61:82:cf:d8 on igb1 expires in 1158 seconds [ethernet]
? (192.168.1.222) at 9c:8e:99:19:64:7a on igb0 permanent [ethernet]
? (192.168.1.210) at 9c:8e:99:19:64:7a on igb0 permanent published [ethernet]
? (192.168.1.117) at 9c:8e:99:19:64:7a on igb0 permanent published [ethernet]

Проксирование включал
sysctl -w net.link.ether.inet.proxyall=1

После включения net.link.ether.inet.proxyall=1 компьютер начинает пинговать оба интерфеса сервера, но ни одного адреса из локалки он по прежнему не видит. Что я делаю не так?

Заранее спасибо.

На схеме криво настроенно eth0.

"Kettler" написал:

На схеме криво настроенно eth0.

А чем вам стандартный нат с маршрутизацией не удовлетворили? Или захотелось экзотики? :)
Какие вообще глобальные задачи?

beliy написал:

А чем вам стандартный нат с маршрутизацией не удовлетворили? Или захотелось экзотики? :)
Какие вообще глобальные задачи?

Глобальная задача следующая:
Необходимо пустить комп в сеть и прозрачно резать посредством Squid некоторые сайты.
Впустить в сеть получилось путем создания псевдо-бриджа. Графически теперь выглядит так:
http://cs622430.vk.me/v622430138/29f5/pedlXgNDsO0.jpg
Правилами IPFW гоню трафик на порт Squid:

00132   1804    160070 fwd 127.0.0.1,3128 tcp from 192.168.0.126 to any dst-port 80,8080-8088 via igb1

Но в итоге Squid ничего не режет ((
И на lo0 трафик не идет:

root@serv1:~ # tcpdump -i lo0 -n -nn -ttt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes
capability mode sandbox enabled

Обрисуйте более точно ситуацию. Не совсем понятен конечный алгоритм.

Клиент находится удаленно и ему нужно подключаться к локальной сети?
Фряшный сервер является шлюзом для локальной сети и к нему цепляется клиент через впн?
Локальная сеть живет своей жизню и ей нужно зарезать сайты на некоторые сайты?

Или может клиент находится локально но подключен к с общей сети? Если да то что мешает включить в сеть?
Тогда не проще ли поднять сквид на фряшном сервере чтоб резать сайты для локальной сети?

"beliy" написал:

Или может клиент находится локально но подключен к с общей сети? Если да то что мешает включить в сеть?

Да. Наиболее верное описание. Клиент находится локально, но подключен к общей сети. Точнее, в разрыв подключения должен быть включен сервер с freeBSD и Squid на борту.
В сеть напрямую включать его нельзя (требование такое). Он должен находиться именно за сервером с FreeBSD и Squid'ом. Чтобы Squid прозрачно пропускал трафик через себя, и направлял бы дальше, на следующий прокси.
Грубо говоря, надо выяснить, как сделать, чтобы последующие прокси смогли увидеть IP клиента, прозрачно проходящего через Squid. Ну или хотя бы возможно ли это в принципе.
Для этого я пытаюсь воссоздать все возможные варианты.
Сейчас почему-то трафик идет в обход Squid. Вот пытаюсь направить его в Squid непосредственно.
В целом - соглашусь с Вашим более ранним высказыванием. Захотелось экзотики ))

"Tiarasu" написал:

Захотелось экзотики ))

Разве что так, по другому, то 2 squid избыточен. Но как по мне продакшн - не лучшее место для экзотики :)
По ARP-proxy c ходу не подскажу, но смысл решения подобных задач всегда сводится к чтению доков, анализе логов, аудите трафика и исправлении найденных несоответствий...

"beliy" написал:

продакшн - не лучшее место для экзотики

Пока что это не продакшн.
Читаем доки, анализируем логи, но все же просим добрых советов.
Пока что уперся в то, что трафик топает мимо прозрачного Squid'a. Косяк. Как починить - пока не знаю.

"Tiarasu" написал:

Пока что уперся в то, что трафик топает мимо прозрачного Squid'a. Косяк. Как починить - пока не знаю.

Ковыряйте IPFW, раз пакеты не доходят. Используемые порты открыты? Покажите правила которыми открываете их.

И что такое igb1?

"beliy" написал:

Ковыряйте IPFW, раз пакеты не доходят. Используемые порты открыты? Покажите правила которыми открываете их.

igb0, igb1 - сетевые интерфейсы на FreeBSD. igb0 смотрит в сеть, igb1 на клиента.
Правила следующие:

ipfw show
00100      0        0 allow ip from any to any via lo0
00200      0        0 allow tcp from me to any out via igb0 uid squid keep-state
00300      0        0 allow tcp from me to any out via igb1 uid squid keep-state
00400   9818  1704424 fwd 127.0.0.1,3128 tcp from 192.168.0.126 to any via igb1
02000      0        0 deny ip from any to 127.0.0.0/8
03000      0        0 deny ip from 127.0.0.0/8 to any
03100    280    20768 allow ipv6-icmp from :: to ff02::/16
03200   8808   637120 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
65000 446894 70829458 allow ip from any to any
65535      0        0 allow ip from any to any

То есть порт идет, и, если верить ipfw, на Squid что-то бросается. Но squid это никак не обрабатывает.

02000 0 0 deny ip from any to 127.0.0.0/8
03000 0 0 deny ip from 127.0.0.0/8 to any

Уверенны что эти правила не режут проброс на 127.0.0.1:3128?

beliy написал:

02000 0 0 deny ip from any to 127.0.0.0/8
03000 0 0 deny ip from 127.0.0.0/8 to any

Уверенны что эти правила не режут проброс на 127.0.0.1:3128?

На 90%. Нулевые показатели же. Хотя, с другой стороны, нам ведь ничего не мешает убрать лишние правила. Момент...

Да нет, та же тема.
Показатель правила перенаправления меняется, access.log и cache.log девственно чисты.

tcpdump для порта 3128 что показывает?

Покажите вывод c фряхи:

tcpdump -nap | grep 3128

beliy написал:

tcpdump для порта 3128 что показывает?

Покажите вывод c фряхи:

text

tcpdump -nap | grep 3128

Невероятно интересно. А они куда то ломятся.

root@serv1:~ # tcpdump -nap | grep 3128
tcpdump: WARNING: igb0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 65535 bytes
capability mode sandbox enabled
16:25:01.231288 ARP, Request who-has 192.168.0.193 tell 192.168.0.74, length 46
16:25:30.312822 IP 172.16.44.115.137 > 172.16.44.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:26:57.931280 ARP, Request who-has 192.168.1.152 tell 192.168.1.157, length 46
16:28:28.131288 IP 172.16.7.124.56744 > 224.0.0.252.5355: UDP, length 32

Правда, по ощущениям, я что-то успел накрутить с правилами. Счас попробую вернуть их на исходную...

"beliy" написал:

Покажите вывод c фряхи:

tcpdump -nap | grep 3128

Извините имел ввиду

netstat -nap

tcpdump так:

tcpdump -vvv port 3128 -i any

"beliy" написал:

tcpdump так:
tcpdump -vvv port 3128 -i any

Что-то ему не понравилось, пытаюсь понять - что именно.

root@serv1:~ # tcpdump -vvv port 3128 -i any
tcpdump: WARNING: igb0: no IPv4 address assigned
tcpdump: syntax error

"Tiarasu" написал:

tcpdump: WARNING: igb0: no IPv4 address assigned

У вас на igb0 указан IPv4?

beliy написал:

[quote="Tiarasu"]tcpdump: WARNING: igb0: no IPv4 address assigned

У вас на igb0 указан IPv4?[/quote]
Нет, они у меня в бридже

cloned_interfaces="bridge0"
ifconfig_bridge0="inet 192.168.1.222 netmask 255.255.252.0 addm igb0 addm igb1 up"
ifconfig_igb0="up"
ifconfig_igb1="up"

Может, такая картина из-за бриджа? Хотя вряд ли, не должно бы... минуточку... эмм...