LINUX.ORG.RU
решено Форум — Admin  

Проброс портов

 ,


0

1

Раньше работал проброс портов настроенный через iptables С роутера были проброшены порты, например 80 роутера на 80 компа и т.п. На компе тогда стояла opensuse, после установки debian wheezy начались проблемы, в 90% случаев соединение установить не удается на проброшенный порт. Это проявляется в том что сайт не хочет открываться или ssh на проброшенный порт не происходит. Т.е. можно написать что-то вроде ssh -P 8022 login@host и ждать, а в соседней вкладке зайти сначала на роутер, затем на комп с него без проблем. Потом все может начать работать внезапно, затем опять прекращается. Я думал может что-то случилось с iptables и поднял на роутере lighty вебсервер, на нем настроил модуль прокси и отключил правило редикекта в iptables. Ничего не изменилось, так же работает через раз. Такое впечатление что комп перестает принимать соединения с роутера, как будто ограничивает их, потом начинает принимать снова. Не понимаю что погуглить?



Последнее исправление: Sepuka (всего исправлений: 2)
← Перенаправление ссылки apache/nginx
squid. Доступ не авторизированным пользователям и выкидывание окна авторизации →

запусти tcpdump на интерфейсе смотрящем в локальную сеть и посмотри что происходит при попытке редиректа.

Если все совсем непонятно, то использовать "-j TRACE".

vel ★★★★★
()
Ответ на: комментарий от vel

Я пытался смотреть tcpdump, но мне это ничего не дало, я просто вижу что на роутере появляются новые строки, причем не http-протокола, а какие-то низкоуровневые, а на компе не появляются. Собственно через некоторое время, когда все работает нормально, я начинаю видеть и там и там нормальный http-обмен.

Sepuka
() автор топика
Ответ на: комментарий от pianolender 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  597 30392 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 
  31M   31G ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
28921 3580K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
  52M   36G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
 787K   48M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW 
6376K 1694M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW 
 1341 42912 ACCEPT     2    --  *      *       0.0.0.0/0            224.0.0.0/4         
   61  9953 ACCEPT     udp  --  *      *       0.0.0.0/0            224.0.0.0/4         udp dpt:!1900 
  55M 3120M SECURITY   all  --  vlan1  *       0.0.0.0/0            0.0.0.0/0           state NEW 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.0.1         tcp dpt:80 
  33M 1907M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 19M packets, 1435M bytes)
 pkts bytes target     prot opt in     out     source               destination         
15794 6371K ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
99501   16M ACCEPT     udp  --  *      *       0.0.0.0/0            224.0.0.0/4         
1280M 1153G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 DROP       all  --  !br0   vlan1   0.0.0.0/0            0.0.0.0/0           
 308K   18M SECURITY   all  --  !br0   *       0.0.0.0/0            0.0.0.0/0           state NEW 
57123 3184K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      br0     0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 96M packets, 72G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain MACS (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain SECURITY (2 references)
 pkts bytes target     prot opt in     out     source               destination         
7401K  386M RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x16/0x02 limit: avg 1/sec burst 5 
71434 2857K RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x17/0x04 limit: avg 1/sec burst 5 
  25M 1521M RETURN     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 
 1602 72548 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/sec burst 5 
  23M 1227M DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW LOG flags 7 level 4 prefix `ACCEPT ' 
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logdrop (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW LOG flags 7 level 4 prefix `DROP ' 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
[/Bash]
Правила iptables только на роутере.
Хочу уточнить что 80 порт я пустил через прокси вебсервера lighttpd и ничего не изменилось, т.е. как будто проблема на стороне компа. Плюс, мне показалось, что проблема началась когда вместо suse я поставил deiban.
Sepuka
() автор топика
Ответ на: комментарий от Sepuka

проблема началась когда вместо suse я поставил deiban

Вот с такими выводами спешить не надо.

Лишние цепочки кто в файрвол вставил? Какой дебиан-то?

pianolender ★★★
()
Ответ на: комментарий от pianolender

Роутер dlink прошитый «прошивкой от Олега» лет 5 назад еще. Теперь он как бы wl500gp. Утром добавил правило проброса еще одного порта, на другую машину в сети (убунта 14.04) и оставил ее включенной, сейчас с работы зашел мгновенно на нее, а на ту, проблемную, не смог. Снова с 10го раза только получается. Очевидно что проблема на стороне этой машины.

Sepuka
() автор топика
Ответ на: комментарий от Sepuka

С десятого раза по ssh или по http?

Там ssh иногда долго думает, это связано с какими-то проверками, которые оно пытается провести, но не может, например, если отключить UseDNS и GSSAPIAuthentication в /etc/ssh/sshd_config, подключение обычно устанавливается гораздо быстрее.

pianolender ★★★
()
Ответ на: комментарий от Sepuka

я просто вижу что на роутере появляются новые строки, ..., а на компе не появляются.

Вывод можем сделать? Дебиан тут не причем. Крутите свой роутер.

sdio ★★★★★
()
Ответ на: комментарий от pianolender

Не, машина домашняя, коридорная: крутится сайт, торренты... Не очень хочется создавать новых пользователей, если есть еще какие-то мысли, то буду признателен.

Sepuka
() автор топика
Ответ на: комментарий от sdio

Видимо вы правы: для эксперимента только что еще раз попробовал зайти на проблемную машину и затем на ту что включил только сегодня для проверки, на обе не смог. А на роутер быстро зашел. Просто когда утром пробовал видимо попал в «окно» которое появляется изредка, собственно то о чем я писал. А с роутера на машины захожу без проблем, ни разу еще не было чтобы не смог.

Sepuka
() автор топика
Ответ на: комментарий от sdio

Да, можно упростить топологию: воткнуть вместо роутера кабель извне прямо в комп. Мак поменять, если надо (ifconfig eth0 hw ether ...), айпи поставить внешний, проверить, что получается. Если все получается - видимо, дебиан не виноват.

pianolender ★★★
()
Ответ на: комментарий от Sepuka

Это у тебя тоже раньше было или Дебиан :-) это установил? Думаю тут собака порылась (режут тебя лимиты из-за роботов "досящих" тебя)

Chain SECURITY (2 references) pkts bytes target prot opt in out source destination
7401K 386M RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 limit: avg 1/sec burst 5 
71434 2857K RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 1/sec burst 5 
25M 1521M RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5 
1602 72548 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5
23M 1227M DROP all -- * * 0.0.0.0/0 0.0.0.0/0
sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 2)
Ответ на: комментарий от pianolender 
iptables-save 
# Generated by iptables-save v1.4.10 on Tue Nov 18 13:14:30 2014
*nat
:PREROUTING ACCEPT [967344:62195937]
:POSTROUTING ACCEPT [5550:333701]
:OUTPUT ACCEPT [5712:387669]
:VSERVER - [0:0]
-A PREROUTING -d 92.53.71.143/32 -j VSERVER 
Can't find library for target `autofw'
-A PREROUTING -i br0 -p tcp -m tcp --dport 5152 -j autofw
Sepuka
() автор топика
Ответ на: комментарий от pianolender

Надеюсь что не тупой, т.к. мне нужна помощь =) Проброс порта на этом роутере реализован через скрипты выполняющиеся по определенным событиям, вот ман http://ru.wikibooks.org/wiki/Настройка_роутера_WL500g_Premium ключевое слово post-firewall

А вот конкретно мои 

iptables -t nat -A PREROUTING -p tcp -d 92.53.71.143 --dport 8022 -j DNAT --to-destination 192.168.0.100:22
iptables -t nat -A PREROUTING --dst 92.53.71.143 -p tcp --dport 8023 -j DNAT --to-destination 192.168.0.2:22
iptables -t nat -A PREROUTING --dst 92.53.71.143 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.100:80

*100 это та машина которая старая и хромая, *2 это современная которую сегодня включил

Sepuka
() автор топика
Ответ на: комментарий от sdio

Вижу, среднее значение 5 в секунду. Откуда оно берется? Кто его установил? И как с этим жить?

Sepuka
() автор топика
Ответ на: комментарий от sdio

Скорее всего, оно там стояло с самого начала, а флуд возник недавно.

А как вообще этот механизм работает? Он блокирует сорс-айпи тех пакетов, которые попали под этот фильтр, или только коннекты с них на порт, на который они пришли?

Так или иначе, это должно мешать ТС только в том случае, если флуд идет из его рабочей сети (из-за той же нат-машины, за которой он сидит). Или я чего-то не понимаю?

pianolender ★★★
()
Ответ на: комментарий от pianolender

308K 18M SECURITY all — !br0 * 0.0.0.0/0 0.0.0.0/0 state NEW

Если br0 это внутренняя сеть, а vlan1 внешняя, то это защита от флуда снаружи.

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от pianolender

Так оно всю цепочку SECURITY тормозит при превышении лимита?

Все что выходит за рамки первых 4-х правил (RETURN)

sdio ★★★★★
()
Ответ на: комментарий от Sepuka

можно посмотреть логи апача и /var/log/auth (у меня в debian 7 логи попыток авторизации по ssh туда попадают)

pianolender ★★★
()
Ответ на: комментарий от pianolender

Чтобы уменьшить кол-во проверяемых правил (получается небольшой список с ответвлениями)

если не сработает
SECURITY all  — !br0 * 0.0.0.0/0 0.0.0.0/0 state NEW

то эти 5 (SECURITY) правил вообще не будут рассмотрены

sdio ★★★★★
()
Ответ на: комментарий от sdio

Ясно.. Несмотря на то, что работаю с iptables относительно давно, знаком с функционалом поверхностно, практически не пользовался юзерскими цепочками. Спасибо, очень интересно.

pianolender ★★★
()
Ответ на: комментарий от sdio

Спасибо за помощь, сейчас я запустил tcpdump чтобы узнать кто ходит на 22 порт, увидел адрес 122.225.109.213, забанил его и вроде стало лучше

Sepuka
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Перенаправление ссылки apache/nginx
Admin
squid. Доступ не авторизированным пользователям и выкидывание окна авторизации →