iptables. проблемы при перезапуске скрипта (Из-за правил iptables не работает FlashPlayer)

[TonnyBennet]

Здравствуйте. Имею в подчинении сервер под UbuntuServer. Сетевая в локалку eth0 и сетевая во внешку eth1 ну и ppp0 интерфейс к провайлеру.

Есть некоторый набор правил iptables, которые я собирал по крупицам с разных форумов и статей для выполнения поставленных мне задач. А именно: nat, port-forwarding; Иногда приходится перезапускать исполняемый файл с правилами. После перезапуска сетка в принципе работает стабильно, но вот есть сайты с активным содержимым: например http://www.alfabank.ru/ там есть кнопка Вход в интернет банк, которые не работают. Открывается окно, а контент не подгружается. Я так понимаю, что написаны они на флеше. Эта страничка использует шифрование SSL.

Решается проблема перезапуском сетевых интерфейсов sudo /etc/init.d/networking restart.

iptables

Spoiler

#!/bin/sh

# Включаем форвардинг пакетов
echo 1 > /proc/sys/net/ipv4/ip_forward

#Очищаем все таблицы
iptables -F
iptables -t nat -F
iptables -t mangle -F

# erase all chains that's not default in filter and nat table.

iptables -X
iptables -t nat -X
iptables -t mangle -X

# Разрешаем трафик на loopback-интерфейсе
iptables -A INPUT -i lo -j ACCEPT

# Разрешаем доступ из внутренней сети наружу
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT

# Включаем NAT
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/24 -j MASQUERADE

# Запрещаем доступ снаружи во внутреннюю сеть
iptables -A FORWARD -i ppp0 -o ppp0 -j REJECT

#Запрещаем broadcast пакеты на eth1
iptables -A OUTPUT -o eth1 --dst 255.255.255.255 -j DROP
iptables -A INPUT -i eth1 --src 255.255.255.255 -j DROP

#Блокирую любую сетевую активность с хоста (проверка активности вирусов)
#iptables -A FORWARD -i eth0 -s 192.168.0.33 -j REJECT
#iptables -A FORWARD -o eth0 -d 192.168.0.33 -j REJECT
#iptables -A INPUT -i eth0 -m mac --mac-source 00:24:21:22:17:C7 -j DROP


#Заворачиваем трафик VPN сервера на Win2003
#Модули iptables
modprobe ip_conntrack_ftp
modprobe ip_gre
modprobe ip_conntrack_pptp
modprobe ip_nat_pptp

#Организация проброса gre трафика во внуть сети.
iptables -A FORWARD -p gre -j ACCEPT

#Проброс портов
iptables -t nat -A PREROUTING --dst 193.105.37.90 -p tcp --dport 1723 -j DNAT --to-destination 192.168.0.100
iptables -t nat -A POSTROUTING --dst 192.168.0.100 -p tcp --dport 1723 -j SNAT --to-source 192.168.0.10
iptables -t nat -A OUTPUT --dst 193.105.37.90 -p tcp --dport 1723 -j DNAT --to-destination 192.168.0.100
iptables -I FORWARD 1 -i ppp0 -o eth0 -d 192.168.0.100 -p tcp -m tcp --dport 1723 -j ACCEPT

# Заворачиваем http на прокси
iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 192.168.0.10:3128

Думаю, что проблема кроется в iptables. Пожалуйста подскажите где копать?

[sash-kan]

проследите с помощью tshark-а, куда при этом происходят обращения и в каком виде они покидают ваш шлюз.

[TonnyBennet]

А что именно я там должен увидеть или не увидеть???

Начал искать в на просторах всемирной паутины про мою проблему. Все пишут, что типа SQID в прозрачном режиме не умеет работать с SSL. Хотя у меня при перезапуске сети всё нормально работает.

Косячить начинает только после ручного запуска скрипта iptables. Я думаю может в самом скрипте я как-то криво обнуляю и добавляю правила в таблицы и у меня трафик где-то останавливается.

[sash-kan]

разглядел, что вы используете принудительно прокси-сервер.
да, ничего полезного вы не увидите. из-за прокси-сервера.
проверьте без заворачивания трафика — сохранится ли та же проблема с этим сайтом.

[sash-kan]

iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 192.168.0.10:3128

насколько я понимаю, этим правилом вы убиваете трафик, шедший на порт 8080.
проверьте из своей локальной сети.
по этой ссылке должен загрузиться текстовый документ:
http://my.zyxel.ru:8080/KEENETIC/Test/V.1...._win_110213.txt
а по этой — приглашение авторизоваться:
http://my.zyxel.ru:80/KEENETIC/Test/V.1.00..._win_110213.txt

если в обоих случаях отобразится одно и то же — принимайте меры.

p.s. ссылка — вторая в запросе google://test 8080

[TonnyBennet]

По ссылкам загружается всё что положено!

правило
iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 192.168.0.10:3128
заворачивает весть трафик идущий на 80 и 8080 порты внутренней сетевой, на прокси сервер squid - это так называемый прозрачный прокси. Т.е. я в настройках на компах в браузерах не прописываю прокси-сервер. В этом правиле нет порта 443 = https т.е. фаервол обрабатывает трафик просто "натя" его. Пробовал дописать в правило 443 порт - появляется ошибка. (текст позднее выложу)

Понимаете, у меня всё отлично работает.... но предположим я захотел сменить правила iptables. Я открываю скриптик... дописываю или изменяю какие то строки... сохраняю... запускаю скрипт. Всё работает также, кроме сайтов с SSL шифрованием. Чтоб они заработали приходится перезапустить сетку. Где кроется проблема и как диагностировать я пока не додумался.

[sash-kan]

проверьте без заворачивания трафика — сохранится ли та же проблема с этим сайтом.

[KiWi]

По ссылкам загружается всё что положено!

правило
iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 192.168.0.10:3128
заворачивает весть трафик идущий на 80 и 8080 порты внутренней сетевой, на прокси сервер squid - это так называемый прозрачный прокси. Т.е. я в настройках на компах в браузерах не прописываю прокси-сервер. В этом правиле нет порта 443 = https т.е. фаервол обрабатывает трафик просто "натя" его. Пробовал дописать в правило 443 порт - появляется ошибка. (текст позднее выложу)

Понимаете, у меня всё отлично работает.... но предположим я захотел сменить правила iptables. Я открываю скриптик... дописываю или изменяю какие то строки... сохраняю... запускаю скрипт. Всё работает также, кроме сайтов с SSL шифрованием. Чтоб они заработали приходится перезапустить сетку. Где кроется проблема и как диагностировать я пока не додумался.

И, конечно же, 192.168.0.10 тоже попадает под это правило и начинает ходить сам в себя?

[TonnyBennet]

проверьте без заворачивания трафика — сохранится ли та же проблема с этим сайтом.

Выключил заворачивание трафика на прокси. Проблемы нет. Сайт работает.

P.S. Он также работает до ручного запуска скрипта.

Скрипт (/etc/network/nat ), обрабатывающий iptables, запускается после старта сетевых интерфейсов. В файле /etc/network/interfaces прописана строчка post-up /etc/network/nat

По ссылкам загружается всё что положено!

правило
iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 192.168.0.10:3128
заворачивает весть трафик идущий на 80 и 8080 порты внутренней сетевой, на прокси сервер squid - это так называемый прозрачный прокси. Т.е. я в настройках на компах в браузерах не прописываю прокси-сервер. В этом правиле нет порта 443 = https т.е. фаервол обрабатывает трафик просто "натя" его. Пробовал дописать в правило 443 порт - появляется ошибка. (текст позднее выложу)

Понимаете, у меня всё отлично работает.... но предположим я захотел сменить правила iptables. Я открываю скриптик... дописываю или изменяю какие то строки... сохраняю... запускаю скрипт. Всё работает также, кроме сайтов с SSL шифрованием. Чтоб они заработали приходится перезапустить сетку. Где кроется проблема и как диагностировать я пока не додумался.

И, конечно же, 192.168.0.10 тоже попадает под это правило и начинает ходить сам в себя?

Извините, не понял о чём речь.

[TonnyBennet]

Подумал и решил переформулировать вопрос всей темы: Почему при перезапуске скриптов iptables перестаёт корректно работать SSL шифрование?

[sash-kan]

Выключил заворачивание трафика на прокси. Проблемы нет. Сайт работает.

на всякий случай уточню. после отключения заворачивания вы перезапускали тот самый скрипт?
если да и перезапуск не вызывает описанной проблемы, то направление раскопок — ваш прокси-сервер.

Извините, не понял о чём речь.

это со стороны дяди KiWi был немножко стёб. но с проверкой. раз не поняли — печально.
правильный ответ на этот стёб должен был звучать так: 192.168.0.10 — это один из адресов машины, на которой это правило прописано, а локально сгенерированный трафик не попадает в цепочку PREROUTING таблицы nat.

[KiWi]

Извините, не понял о чём речь.

это со стороны дяди KiWi был немножко стёб. но с проверкой. раз не поняли — печально.
правильный ответ на этот стёб должен был звучать так: 192.168.0.10 — это один из адресов машины, на которой это правило прописано, а локально сгенерированный трафик не попадает в цепочку PREROUTING таблицы nat.

Я нигде не увидел, что 192.168.0.10 -- адрес машины, на которой прописываются правила для iptables.
Более того, я нигде не увидел строчки, о том, что трафик с 192.168.0.10 не проходит через машину, на которой настраивается iptables.

В итоге можем иметь:
- роутер с неизвестным адрес и iptables
- прокси-сервер 192.168.0.10, выходящий через этот роутер в интернет
Очевидно, что в таком случае трафик в интернет будет проходить через роутер и DNATом отправится сам на себя.

[TonnyBennet]

Согласен, недосказал...

192.168.0.10 - это адрес машины, являющейся и прокси-сервером и шлюзом для всей сети 192.168.0.0/24. На нём прописываются правила iptables

Более того, я нигде не увидел строчки, о том, что трафик с 192.168.0.10 не проходит через машину, на которой настраивается iptables.

В итоге можем иметь:
- роутер с неизвестным адрес и iptables
- прокси-сервер 192.168.0.10, выходящий через этот роутер в интернет
Очевидно, что в таком случае трафик в интернет будет проходить через роутер и DNATом отправится сам на себя.

Весь трафик из сети проходит через NAT, а трафик 80,8080 портов DNATом отправляется сам на себя. Его принимает прокси- сервер и отправляет в Интернет.

[KiWi]

Весь трафик из сети проходит через NAT, а трафик 80,8080 портов DNATом отправляется сам на себя. Его принимает прокси- сервер и отправляет в Интернет.

В таком случае, легче сделать -j REDIRECT.

[TonnyBennet]

Весь трафик из сети проходит через NAT, а трафик 80,8080 портов DNATом отправляется сам на себя. Его принимает прокси- сервер и отправляет в Интернет.

В таком случае, легче сделать -j REDIRECT.

Может и лучше. Но вот только проблема не в этом

[TonnyBennet]

Выключил заворачивание трафика на прокси. Проблемы нет. Сайт работает.

на всякий случай уточню. после отключения заворачивания вы перезапускали тот самый скрипт?
если да и перезапуск не вызывает описанной проблемы, то направление раскопок — ваш прокси-сервер.

Ещё раз проделал эту операцию. Выключил заворачивание трафика на прокси-сервер. Перезапустил сеть. Всё работает как прежде. Перезапустил скрипт. Через браузер в Интернет выходить перестал вообще. Пишет в строке статуса: ожидание ответа от сервера. Пробовал пинговать mail.ru c клиентской машины - пингуется.

Потом вспомнил про замечательное свойство iptables-save. Сохранил правила до запуска скрипта и после запуска скрипта. Нашёл отличия в 1 строку:

iptables -t mangle -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu

такая строка по-моему прописывается системой автоматически при создании PPPoE соединения или когда то ещё. Само собой когда я запускаю свой скрипт руками он очищает все таблицы и цепочки и это правило уже не добавляется. Описание этого правила нашёл в Интернете http://novikovmaxim.livejournal.com/96408.html

Прописал правило как указано в статье http://www.opennet.ru/base/net/pppoe_mtu.txt.html

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

в принципе всё заработало. Утром офис заполнится юзверями и думаю проверка будет более активной.

[KiWi]

Потом вспомнил про замечательное свойство iptables-save. Сохранил правила до запуска скрипта и после запуска скрипта. Нашёл отличия в 1 строку:

iptables -t mangle -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu

такая строка по-моему прописывается системой автоматически при создании PPPoE соединения или когда то ещё. Само собой когда я запускаю свой скрипт руками он очищает все таблицы и цепочки и это правило уже не добавляется. Описание этого правила нашёл в Интернете http://novikovmaxim.livejournal.com/96408.html

Прописал правило как указано в статье http://www.opennet.ru/base/net/pppoe_mtu.txt.html

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

в принципе всё заработало. Утром офис заполнится юзверями и думаю проверка будет более активной.

Правильней -- не резать ICMP и "магия" сделает всё сама без подобных костылей: Недоступны некоторые сайты. Вечное ожидание ответа.