Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - idgi3

Pages: [1]
1
Как вариант - настрой WDS, чтоб мак-адреса не менялись.
https://ru.wikipedia.org/wiki/WDS

Разве с wds скорость не падает, за счет использования канала передачи для соединения точки и репитеров ? С wifi мостом убикьюти не получается wds.
Да и вообще, это все "костыль " напоминает.

2
Can anyone explain how the IP packet can return from this chain of iptables,

i see if MAC addres for host 192.168.0.52 not 8C:3A:E3:4C:46:F4 then idrop, but than all 192.168.0.0/24 idrop - how can it be?

Chain inospoof (1 references)
target     prot opt source               destination
inospoofmodules  all  --  anywhere             anywhere
idrop      all  --  192.168.0.52         anywhere             MAC ! 8C:3A:E3:4C:46:F4
idrop      all  --  192.168.0.0/24       anywhere


after all i do the host go to Internet without my squid, but in iptables -t nat i have:
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
premodules  all  --  anywhere             anywhere
DNAT       tcp  --  anywhere             8.16.32.64          tcp dpt:https to:192.168.0.2
DNAT       udp  --  anywhere             8.16.32.64          udp dpt:https to:192.168.0.2
DNAT       tcp  --  anywhere             8.16.32.64          tcp dpt:http to:192.168.0.2
DNAT       udp  --  anywhere             8.16.32.64          udp dpt:http to:192.168.0.2
DNAT       tcp  --  anywhere             8.16.32.64          tcp dpt:50500 to:192.168.0.2
DNAT       udp  --  anywhere             8.16.32.64          udp dpt:50500 to:192.168.0.2
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
postmodules  all  --  anywhere             anywhere
MASQUERADE  all  --  anywhere             anywhere
Chain postmodules (1 references)
target     prot opt source               destination
Chain premodules (1 references)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere            !server.qwert.yui    tcp dpt:http redir ports 3128

3
Да я бы это сделал, только вот эти клиенты, у которых маршрут прохода iptables вручную был изменён, теперь мимо прокси в инет ходят - а это для меня достаточно критично.

Пытаюсь разобраться в iptables - т.к. в NAT вроде для всех REDIRECT прописан судя по этому:
iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
premodules  all  --  anywhere             anywhere

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
postmodules  all  --  anywhere             anywhere
MASQUERADE  all  --  anywhere             anywhere

Chain postmodules (1 references)
target     prot opt source               destination

Chain premodules (1 references)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere            !server.домен.домен    tcp dpt:http redir ports 3128

Решу вопрос - нарисую FAQ

4
Всё оказалось просто.

вместо /etc/zentyal/hooks/templates.postservice внёс нужные изменения в /etc/zentyal/hooks/firewall.postservice и теперь правила появляются в iptables после перезагрузки, антиспуфинга теперь нет и проблем с WiFi-ем тоже нет... пришлось выбрать.

5
yeah...

cp /etc/zentyal/hooks/template.postservice /etc/zentyal/hooks/firewall.postservice

and now i have no nospoof defence, but i dont have any problems with my Repeater WiFi antennas.

thanks jbahillo.

6
Суть проблемы найдена. Тут https://forum.zentyal.org/index.php/topic,23958.msg91956.html#msg91956 на конкретное место в iptables указали ))

Как и указывал bubnov-pi это защита от spoofинга
правила прописываются в цепочках fnospoofmodules и inospoofmodules.

добавление:
/sbin/iptables -t filter -A fnospoofmodules -s 192.168.0.52/32 -j faccept
/sbin/iptables -t filter -A inospoofmodules -s 192.168.0.52/32 -j iaccept

решило проблему, только не понятно как быть с массивом IP адресов, а не с одним - по одному после каждой перезагрузки вбивать в iptables...

Не пойму как использовать hooks - /etc/zentyal/hooks/template.postservice
1.
/sbin/iptables -t filter -A fnospoofmodules -s 192.168.0.52/32 -j faccept
/sbin/iptables -t filter -A inospoofmodules -s 192.168.0.52/32 -j iaccept
exit 0
2. sudo chmod +x /etc/zentyal/hooks/template.postservice
3. sudo service firewall restart

и правила в iptables не появились - или не должны они там были появится, вообщем:

Спасибо bubnov-pi. Дальше я уж докопаю.

7
So. The problem probably solved... here is the tips http://www.vionblog.com/zentyal-3-2-pptp-server/

when i manually add
/sbin/iptables -t filter -A fnospoofmodules -s 192.168.0.52/32 -j faccept
/sbin/iptables -t filter -A inospoofmodules -s 192.168.0.52/32 -j iaccept

the problem has gone, and i have no drops from firewall.

But i cant understand how to use /etc/zentyal/hooks/template.postservice
1.
/sbin/iptables -t filter -A fnospoofmodules -s 192.168.0.52/32 -j faccept
/sbin/iptables -t filter -A inospoofmodules -s 192.168.0.52/32 -j iaccept
exit 0
2. sudo chmod +x /etc/zentyal/hooks/template.postservice
3. sudo service firewall restart

and i dont have those rules in inospoofmodules and fnospoofmodules...

8
Thanx. I will try to change fnospoof and inospoof chains in iptables.

But I did not add any rules in iptable. After reboot GRE rules was deleted.

I think that chains "inospoof" and "fnospoof" were generated by Zentyal firewall after reserving IPs in DHCP.
So if i change this manually i will have same problem next time after reserving another IPs, didnt i ?

How can i switch off "nospoof" chains in Firewall?

9
Hello everyone!

I have server zentyal CE 4.0. eth0 watching local network, eth1 watching to internet via pppoe.
DHCP pool is 192.168.0.150 - 192.168.0.240.
I`m creating some groups of computers in Network objects, and than in DHCP service choose Static IP to that groups.
IP`s from 192.168.0.10 to 192.168.0.149.

In the local network i have 2 wifi antennas, one Access Point, other - Repeater.

Problem is: When i`m trying to use internet WiFi which Access Point - there is no problems, but when i use Repeater Firewall drops any IP packets to server.
If i dont use static IP adresses in DHCP - there is no problems.

When i see to syslog (attach)  i cant understand difference between the packets that ACCEPT or DROP.

I tought if my situation is GRE IP packets, so
modprobe ip_gre
iptables -A INPUT -p gre -j ACCEPT
iptables -A OUTPUT -p gre -j ACCEPT
- problems still here

Then i`ve tried to understand why firewall choose DROP or ACCEPT in some situations:
 sudo tcpdump -n -nn -ttt host 192.168.0.52 -w tcpdump.txt, so i have the message from tcpdump that 0 packets was dropped by kernel - how could this be?

Here firewall LOGs part
2014-11-25 16:14:28 eth0 ppp0 192.168.0.52 195.210.46.29 TCP 58125 80 DROP
2014-11-25 16:14:25 eth0 ppp0 192.168.0.52 198.41.215.184 TCP 57764 80 DROP
2014-11-25 16:14:07 eth0 192.168.0.52 192.168.0.52 UDP 67 68 DROP
2014-11-25 16:13:59 eth0 192.168.0.52 192.168.0.1 UDP 23979 53 DROP
2014-11-25 16:13:58 eth0 192.168.0.52 192.168.0.1 UDP 21866 53 DROP
2014-11-25 16:13:57 eth0 192.168.0.52 192.168.0.1 UDP 11131 53 DROP

when i use WiFi Access point Antenna, not repeater - i dont have any problem, also firewall workin fine if i dont choose static IP for my device.

What is the difference betwen UDP packet from local host (with static IPaddress) via WiFi Access Point and the UDP packet from same local host via WiFi Repeater?

Sorry for my English.

I would appreciate any help!

10
Quote
Проект мутирует из "всё в одном" в "замена MS Exchange"

купился на LDAP - надо, jabber - надо, proxy + dansguardian - надо, в итоге отдельный файлсервер не смог вытащить данные из ЛДАП - не ясно почему, а прокси и фильтр не актуальны из-за невозможности выделить известных пользователей в группы по MAC адресам, т.к. файерволл занимается какой-то ерундой, вместо того, чтобы защищать сетку извне.

так-то мне функционал Zentyal очень подходит, только заставить бы его работать. Чую, вместо того, чтобы изучать и выбирать эти все пакеты: "Всё в одном" эффективнее самому с iptables, bind, ldap попробовать разобраться ((( - хотел сэкономить время.

по теме: должна же быть причина по которой firewall принимает решения DROP и ACCEPT для пакетов с одинаковыми характеристиками, значит я не все характеристики вижу - есть диагностические проги, которые полностью позволят пакет разобрать, чтобы понять какое свойство вызывает отторжение?

а на англоязычном поживее? - может туда попробовать?

11
И тишина...

Проблема не решена, пакеты так и дропаются.
Попробовал проанализировать syslog на предмет отброшенных и принятых пакетов - и не нашёл между ними принципиальной разницы, видимо не все характеристики пакета в syslog попадают (во вложение положил)

Попробовал понять почему пакеты дропаются, используя tcpdump
 sudo tcpdump -n -nn -ttt host 192.168.0.52 -w tcpdump.txt - после выполнения этой команды получил сводную информацию о том, что много пакетов захвачено, а пакетов отброшенных ядром нет. (дамп во вложении)

а в логах файерволла, при этом (некоторая часть):
2014-11-25 16:14:28 eth0 ppp0 192.168.0.52 195.210.46.29 TCP 58125 80 DROP
2014-11-25 16:14:25 eth0 ppp0 192.168.0.52 198.41.215.184 TCP 57764 80 DROP
2014-11-25 16:14:07 eth0 192.168.0.52 192.168.0.52 UDP 67 68 DROP
2014-11-25 16:13:59 eth0 192.168.0.52 192.168.0.1 UDP 23979 53 DROP
2014-11-25 16:13:58 eth0 192.168.0.52 192.168.0.1 UDP 21866 53 DROP
2014-11-25 16:13:57 eth0 192.168.0.52 192.168.0.1 UDP 11131 53 DROP

Предположил, что сложности файерволла и GRE пакетов - это про мой случай, выполнил как тут http://forum.ubuntu.ru/index.php?topic=14041.1035
modprobe ip_gre
iptables -A INPUT -p gre -j ACCEPT
iptables -A OUTPUT -p gre -j ACCEPT
- не помогло

Могли дропнутые пакеты до tcpdump не добраться? - как такое возможно?

Ну хоть подсказки какие!!!

з.ы. решил удалить в баню Firewall модуль из сборки своей, веб интерфейс предложил вместе с файерволлом удалить и большинство остальных модулей.

з.з.ы. следующий шаг, похоже, переустановка системы без файерволла и настройка iptables вручную...

12
Ну ок... есть же, наверное, те, кто разбирается, как эти iptables работают....

Вот фрагмент iptables -L (остальное в приложении)
Насколько я понимаю если в цепочке INPUT есть правило ACCEPT     all  --  anywhere             anywhere, то остальные правила в этой цепочке смысла не имеют, то же самое с OUTPUT. И, как я понимаю, эти правила там оказались из-за того, что я в файрвол в разделы:
Правила фильтрации из внутренних сетей на Zentyal
Правила фильтрации для трафика исходящего из Zentyal это самое правило записал.

Почему-то в цепочке FORWARD того-же правила нет, может проходя через REPEATER пакет как раз и направляется в FORWARD?

а отсутствие net.ipv4.ip_forward=1 влияет на указанные пакеты? может в этом дело? а где в вебморде ZENTYAL данный параметр конфигурируется? - или только через консоль работать?

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere           
preinput   all  --  anywhere             anywhere           
idrop      all  --  anywhere             anywhere             state INVALID
iaccept    all  --  anywhere             anywhere             state RELATED,ESTABLISHED
inospoof   all  --  anywhere             anywhere           
iexternalmodules  all  --  anywhere             anywhere           
iexternal  all  --  anywhere             anywhere           
inoexternal  all  --  anywhere             anywhere           
imodules   all  --  anywhere             anywhere           
iglobal    all  --  anywhere             anywhere           
iaccept    icmp !f  anywhere             anywhere             icmp echo-request state NEW
iaccept    icmp !f  anywhere             anywhere             icmp echo-reply state NEW
iaccept    icmp !f  anywhere             anywhere             icmp destination-unreachable state NEW
iaccept    icmp !f  anywhere             anywhere             icmp source-quench state NEW
iaccept    icmp !f  anywhere             anywhere             icmp time-exceeded state NEW
iaccept    icmp !f  anywhere             anywhere             icmp parameter-problem state NEW
idrop      all  --  anywhere             anywhere           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
preforward  all  --  anywhere             anywhere           
fdrop      all  --  anywhere             anywhere             state INVALID
faccept    all  --  anywhere             anywhere             state RELATED,ESTABLISHED
fnospoof   all  --  anywhere             anywhere           
fredirects  all  --  anywhere             anywhere           
fmodules   all  --  anywhere             anywhere           
ffwdrules  all  --  anywhere             anywhere           
fnoexternal  all  --  anywhere             anywhere           
fdns       all  --  anywhere             anywhere           
fglobal    all  --  anywhere             anywhere           
faccept    icmp !f  anywhere             anywhere             icmp echo-request state NEW
faccept    icmp !f  anywhere             anywhere             icmp echo-reply state NEW
faccept    icmp !f  anywhere             anywhere             icmp destination-unreachable state NEW
faccept    icmp !f  anywhere             anywhere             icmp source-quench state NEW
faccept    icmp !f  anywhere             anywhere             icmp time-exceeded state NEW
faccept    icmp !f  anywhere             anywhere             icmp parameter-problem state NEW
fdrop      all  --  anywhere             anywhere           

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere           
preoutput  all  --  anywhere             anywhere           
odrop      all  --  anywhere             anywhere             state INVALID
oaccept    all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ointernal  all  --  anywhere             anywhere           
omodules   all  --  anywhere             anywhere           
oglobal    all  --  anywhere             anywhere           
oaccept    icmp !f  anywhere             anywhere             icmp echo-request state NEW
oaccept    icmp !f  anywhere             anywhere             icmp echo-reply state NEW
oaccept    icmp !f  anywhere             anywhere             icmp destination-unreachable state NEW
oaccept    icmp !f  anywhere             anywhere             icmp source-quench state NEW
oaccept    icmp !f  anywhere             anywhere             icmp time-exceeded state NEW
oaccept    icmp !f  anywhere             anywhere             icmp parameter-problem state NEW
odrop      all  --  anywhere             anywhere           

13
Проблема немного прояснилась.

В той же самой сети имеются 2 wifi антенны. Одна в режиме AccessPoint, вторая в режиме Репитера.
Ловлю ноутбуком антенну, являющуюся AccessPoint - firewall счастливо пишет всё в логи и нормально пропускает везде и всюду, дохожу до антенны, являющейся Репитером, ноут переподключается к ней и firewall начинает свою "деятельность" - то есть DROP 137 порта, 83 порта, а если пытаться по айпишникам в инет лезть, порт 3128 сбрасывается.

Очевидно, что мне не хватает теоретической подкованности :-) чтобы понять, каким образом wifi антенна в режиме репитера меняет пакеты, что firewall перестаёт считать их, посланными из локальной сети...

Что удивило: добавление в файрволл, в раздел Фильтр пакетов ❱ Из внешних сетей на Zentyal, да и во все остальные правила ACCEPT    Любой    Любой - не помогло (DROP продолжается), хотя, при этом, как я понимаю, сервер вобще должен становиться абсолютно доступным.

14
Так так... уже что-то - Спасибо.
Только вот как понять с какого MAC-а в итоге пакет добрался до iptables? - могу я через консоль посмотреть на логи?

Я задаю в Объектах сети список, а в этот список добавляю клиентов - примерно такая табличка.
Иные:
Библиотека    192.168.0.155/32    48:5b:39:50:24:fe
Затем в конфигурации DHCP в Фиксированных адресах добавляю этот список "Иные" в данном случае.

Путь пакета, видимо, такой:
Библиотека    192.168.0.59/32    48:5b:39:50:24:fe
Nanobeam2    192.168.0.4/32    04:18:d6:54:ca:72 - тот самый wifi мост
NanoBeam1    192.168.0.3/32    04:18:d6:54:c8:fa
HP V1910 Switch    192.168.0.5/32    b8:af:67:14:79:c1
Server 192.168.0.1

- это в случае когда файрвол дропать пакеты начинает,
а вот в такой ситуации (по витой паре):
Secretar    192.168.0.19/32    00:22:15:98:f1:31
HP V1910 Switch    192.168.0.5/32    b8:af:67:14:79:c1
Server 192.168.0.1

- всё нормально, все пакеты в логах файрволла можно увидеть, при этом пакет в итоге всё равно через HP V1910 Switch на Сервер приходит. В обоих случаях все IP адреса фиксированные.

Как вариант в каждую таблицу iptables добавить правило LOG и посмотреть из какой цепочки и из какой таблицы пакет дропается?


15
Здравствуйте!

Сервер zentyal 4.0 с двумя сетевыми (одна в инет, другая в локалку)
Клиенты windows 7 (настроены на dhcp)
Диапазон адресов DHCP 192.168.0.150 - 192.168.0.240. Сервер 192.168.0.1. Маска 255.255.255.0.
Пытаюсь для известных клиентов сети зафиксировать IP адреса.

Возникла следующая проблема:
После того, как в DHCP у клиентов одного из сегментов сети фиксирую IP адрес, Zentyal firewall DROPает все запросы этих клиентов к портам 53 и 137.

Сегмент отличается от всей остальной сети тем, что соединён с основным switchом WI-FI мостом Ubiquiti nanobeam m5 (две антенны, для которых также зарезервированы два ip-адреса).

Однако не понятен следующий момент: если не резервировать IP адрес, то клиенты спокойно получают все настройки от DHCP сервера и ходят в инет и по локалке, а если зафиксировать для одного из клиентов IP - то начинается DROP пакетов (от этого клиента).

выводы ipconfig /all и route print идентичные для обеих ситуаций (с зарезервированным IP и с IP из разрешённого диапазона). Tracert не понятно как в локалке использовать... да и понятно, что до сервера пакеты доходят, раз они там дропаются.

Как понять из какой таблицы iptables был дропнут пакет?
Каким образом вести лог подключений от конкретного клиента, чтобы все действия со всеми пакетами от него в логах фиксировались?
Где можно найти логи firewall zentyal, кроме как в вебморде смотреть? - в /var/log что-то не нашёл...
Сделал в вебморде файрвола правило LOG всех пакетов с конкретного клиента - что толку на эти DROPы смотреть там?

Буду признателен за любые подсказки.


Pages: [1]