[anp/hsw] Posted December 7, 2005 Posted December 7, 2005 возникла такая проблема: есть linux 2.4.31, iptables v1.3.3, есть NAT: $IPTABLES -t mangle -A PREROUTING -j MARK -s $SVPN_NN --set-mark $SVPN_MARK $IPTABLES -t nat -A POSTROUTING -j SNAT -s $SVPN_NN --to-source $STK_IP -o $STK_PPP $IPTABLES -t filter -A FORWARD -j ACCEPT -s $SVPN_NN -o $STK_PPP $IPTABLES -t filter -A FORWARD -j DROP -s $SVPN_NN (такой себе самый обычный NAT) $STK_IP - внешний ип, то-есть NAT не двойной.... а теперь проблема: ICQ99 и подобное старье, а также linux клиенты (licq, centericq) - прекрасно ходят, а новые поделия как то icq2002 - ICQ5 - зависают на стадии "авторизация" в чем может быть проблема? лог tcpdump привести не могу (похерился где-то) но происходит примерно так: 1. запрос на icq.login.com:5190 (TCP) 2. ответ от icq.login.com (TCP) 3. клиент висит. но если в клиенте прописать прокси (squid стоит на той же машинке) аська начинает работать... никто не сталкивался с подобной проблемой? Вставить ник Quote
Guest Posted December 7, 2005 Posted December 7, 2005 банально -t nat -A POSTROUTING -p tcp --dport 5190 -j SNAT --to-source $STK_IP не пробывал? Вставить ник Quote
[anp/hsw] Posted December 7, 2005 Author Posted December 7, 2005 банально. попробовал. результат аналогичный, может, не надо обьяснять, что: -t nat -A POSTROUTING -p tcp --dport 5190 -j SNAT --to-source $STK_IP входит в правило: -t nat -A POSTROUTING -j SNAT -s $SVPN_NN --to-source $STK_IP -o $STK_PPP только первое правило NATит 5190/TCP, а второе - NATит все :) Вставить ник Quote
Nallien Posted December 7, 2005 Posted December 7, 2005 $IPTABLES -t mangle -A PREROUTING -j MARK -s $SVPN_NN --set-mark $SVPN_MARK $SVPN_NN - это что ? $IPTABLES -t nat -A POSTROUTING -j SNAT -s $SVPN_NN --to-source $STK_IP -o $STK_PPP это я так понимаю внутренний траф посылается на внешний айпи... и - что-то мне синтаксис не совсем понятен... вроде как -s долно быть до -j... так-то тоже работает, но не нарушается ли жтим логика команды ? $IPTABLES -t filter -A FORWARD -j ACCEPT -s $SVPN_NN -o $STK_PPP опять не понял.... маскарадингом не проще бы дело было ? $IPTABLES -t filter -A FORWARD -j DROP -s $SVPN_NN тоесть пропускаем все что идет наружу через $SVPN_NN, и выбрасываем все, что для наружи не предназначает ???? я окончательно запутался... имхо - правила через одно место :( Вставить ник Quote
[anp/hsw] Posted December 8, 2005 Author Posted December 8, 2005 $SVPN_NN - это что ? сетка VPN-клиентов, кроме как в интернет они никуда ходить не должны... вроде как -s долно быть до -j... так-то тоже работает, но не нарушается ли жтим логика команды ? не нарушается, порядок параметров фиолетов. опять не понял.... маскарадингом не проще бы дело было ? ну, и маскарадингом пробовал, вот в данном конкретном примере у меня один IP-адрес, но скоро будет 2, и тада для распределения нагрузки при SNAT надо будет сделать --to-source IP1-IP2, как это сделать при маскарадинге? (к тому же маскарадинг - это для динамических IP-адресов, у меня же статический) тоесть пропускаем все что идет наружу через $SVPN_NN, и выбрасываем все, что для наружи не предназначает ???? логично бы было, а то будут юзать локальный FTP через тунель (у кого маршруты через одно место прописаны), к кому потом претензии приводить? к тебе? :) я окончательно запутался... имхо - правила через одно место :( по-моему все более-менее логично, предложи свой вариант... :) Вставить ник Quote
Nallien Posted December 8, 2005 Posted December 8, 2005 а при маскарадинге - в чем проблема с ДНАТом или СНАТом... а вообще -я флейм розвожу... проблему тут явно не в этом :( извини. быть может какая-то другая служба заняла порты необходимые еське для авторизации ??? ведь если старые версии работают и сейчас - то нжно проследить в чем отличие между ними и новыми. снифером например... ну а там - уж посмотреть что и к чему... снифером так же проследить чтобы в заголовках пакета адрес и исходник были правильными, и сделать это ДО шлюза и ЗА ним.. ну или на нем. Вставить ник Quote
[anp/hsw] Posted December 11, 2005 Author Posted December 11, 2005 вот tcpdump коннекта аськи: http://213.228.93.25/icq-log.txt на нем отчетливо видно, что она не может достучаться до первого сервера, выбирает следующий, и потом заходит (на cb.icq.com) вопрос: почему не может достучаться? (прозрачный squid я на время убирал - результат аналогичный) Вставить ник Quote
Nallien Posted December 11, 2005 Posted December 11, 2005 хэ.... в мой сниф на импортит... труднова-то читать. ну вобщем - на второй-то оно конектится? так в чем проблема? а почему не идет на первый... хм... как насчет МТУ ?... или же соединения какого-то типа у Вас на шлюзе порезаны.... а так - я даж затрудняюсь... нету ли в файрволе настроек ограничивающих соединения (даже syn запросы)? попробуйте их на время отключить... или вообще - маскарадинг на асю. если есть возможность с чистыми таблицами. чтобы уж наверняка откинуть проблемы в файрволе... ну и как радикальный способ - миранда. Вставить ник Quote
[anp/hsw] Posted December 11, 2005 Author Posted December 11, 2005 хэ.... в мой сниф на импортит... труднова-то читать. самый обычный лог tcpdump'a, я думал, что его читают просто так, никуда не импортируя :) ну вобщем - на второй-то оно конектится? так в чем проблема? ко второй коннектится, проблема в том, что аська висит от 1 до 5 минут, а потом коннектится, клиентам это естественно не нравится.... а почему не идет на первый... хм... как насчет МТУ ?... или же соединения какого-то типа у Вас на шлюзе порезаны.... а так - я даж затрудняюсь... нету ли в файрволе настроек ограничивающих соединения (даже syn запросы)? мту? а что с ним? :) соединения такого типа у меня на шлюзе не порезаны - у клиента полностью NAT. вот что-то а SYN то уже вообще не ограничивал.... $IPTABLES -t filter -A FORWARD -j TCPMSS -p tcp --tcp-flags SYN,RST SYN --clamp-mss-to-pmtu $IPTABLES -t filter -A INPUT -j ACCEPT -m state --state RELATED,ESTABLISHED этого достаточно? или я что-то неправильно понял? :) попробуйте их на время отключить... или вообще - маскарадинг на асю. если есть возможность с чистыми таблицами. чтобы уж наверняка откинуть проблемы в файрволе... маскарадинг дает тот же эффект, что и SNAT, проблема явно не в нем.... с чистыми таблицами возможности нету. ну и как радикальный способ - миранда. заставить около 400 человек пользоваться мирандой - действительно, способ радикальный :) Вставить ник Quote
Nallien Posted December 11, 2005 Posted December 11, 2005 хэ-хэ, насчте снифа- говорю же УДОБНЕЙ читать. это для невнимательных. плюс расшифрововаьт заголовки Вы тоже прямо сходу будете ? завидую, завидую... я увы - и обычные логи читаю плохенько. 1-5 минут висит ? плохо значит Вы батюшка читаете самый обычный лог дампера. а о Миранде - раньше надо было думать. трафик бы сэкономило (если конечно Вы не коммерческая сеть ;) тогда вопрос снят. ограничивающих - не совсем точно выражение. скажем так - изменяющих. создать правило от меня прямо на аську - чтобы с этой машины был приоритет в таблицах. и проверить. что-то явно обрезается. и еще - более старые аси вешаются на основной серв ? или все-таки тоже лезут к другому, но не ожидая пяти минут ? Вставить ник Quote
Guest Posted December 11, 2005 Posted December 11, 2005 сходу будете ? завидую, завидую... я увы - и обычные логи читаю плохенько. уважаемый, не надо мне завидовать, хоть логи читаю хорошо, зато девушки не вешаются на шею :) 1-5 минут висит ? плохо значит Вы батюшка читаете самый обычный лог дампера. ну, я хорошо читаю, и даты понимаю :) в этот раз висело 1 минуту, только потом, когда начало до cb.icq.com стучаться, тогда и можно считать "развисло", до этого времени подвижек у клиента не было.... иногда и до 5 минут доходит - сервера выбираются случайным образом видимо.... более старые аси почему то подключаются к основному серверу без проблем.... Вставить ник Quote
sire Posted February 9, 2007 Posted February 9, 2007 Скажите, пожалуйста, Вы решили проблему? У меня возникла аналогичная проблема. ОС - Debian etch, kernel 2.6.18, iptables 1.3.6. Правила IPTables: $IPT -t nat -A POSTROUTING -s ! $IP_EXT/$MASK_EXT -o $IF_EXT -j SNAT --to-source $IP_EXT $IPT -A FORWARD -j ACCEPT Единственное,что до моего NAT'a пакеты пользователей локалки проходят еще через цепочку маршрутизаторов, среди которых есть и FreeBSD, и еще неизвестно что. Трафик помимо ICQ ходит без проблем, включая пассивный и активный FTP, а то я было на contrack и проч. грешил. Вставить ник Quote
GateKeeper Posted February 10, 2007 Posted February 10, 2007 Может, проблема, как всегда, на стороне icq.com? Месяца не проходит без подобных этому тредов тут или "там"... Вставить ник Quote
nuclearcat Posted February 11, 2007 Posted February 11, 2007 Попробуйте iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 Если поможет - скажите. Обьясню что делать. А можете и сами найти в нете :-) Вставить ник Quote
sire Posted February 13, 2007 Posted February 13, 2007 Спасибо всем откликнувшимся. Всё само как-то восстановилось. На всякий случай установил MSS. Если будут новые подробности - отпишу сюда. Вставить ник Quote
sire Posted February 13, 2007 Posted February 13, 2007 (edited) Попробуйте iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 Если поможет - скажите. Обьясню что делать. А можете и сами найти в нете :-) Про установку MSS погуглил. Как я понял это используется для обхода проблемы, возникающей из-за кривой реализации TCP в клиентах Micro$oft и блокировки сообщений ICMP на маршрутизаторах. Однако, народ пишет не про ICQ конкретно, а про большие пакеты вообще. То есть ssh работает, а scp - нет, и т.п. К стати, ICQ разве использует большие пакеты; у меня ICQ не может даже залогиниться. Поправьте меня, пожалуйста, если не прав, или дайте хорошую ссылочку по теме. Я думаю не мне одному пригодится. Edited February 13, 2007 by sire Вставить ник Quote
user_anonymous Posted February 14, 2007 Posted February 14, 2007 Автор, сделай плиз iptables-save и покажи полный листинг правил. ИП можно не показывать. И листинг вывода lsmod Вставить ник Quote
sire Posted February 14, 2007 Posted February 14, 2007 Автор, сделай плиз iptables-save и покажи полный листинг правил. ИП можно не показывать. И листинг вывода lsmodАффтар делает, то что просили: :-) # Generated by iptables-save v1.3.6 on Wed Feb 14 13:01:56 2007 *mangle :PREROUTING ACCEPT [456736502:261054362178] :INPUT ACCEPT [2168307:148985451] :FORWARD ACCEPT [454554016:260904258772] :OUTPUT ACCEPT [2131159:135629235] :POSTROUTING ACCEPT [456684932:261039757207] -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 COMMIT # Completed on Wed Feb 14 13:01:56 2007 # Generated by iptables-save v1.3.6 on Wed Feb 14 13:01:56 2007 *nat :PREROUTING ACCEPT [57404434:3544850605] :POSTROUTING ACCEPT [9555:817994] :OUTPUT ACCEPT [4160:313109] -A POSTROUTING -s ! $IP_EXT/$MASK_EXT -o $IF_EXT -j SNAT --to-source $IP_EXT COMMIT # Completed on Wed Feb 14 13:01:56 2007 # Generated by iptables-save v1.3.6 on Wed Feb 14 13:01:56 2007 *filter :INPUT DROP [2:84] :FORWARD DROP [48:2982] :OUTPUT DROP [1:40] -A INPUT -j ACCEPT -A FORWARD -j LOG --log-prefix "[FORWARD] " --log-level 7 -A FORWARD -j ACCEPT -A OUTPUT -j ACCEPT COMMIT # Completed on Wed Feb 14 13:01:56 2007 Module Size Used by ipt_TCPMSS 4096 1 xt_tcpudp 3136 1 iptable_mangle 2880 1 iptable_nat 7044 1 ip_nat_tftp 1920 0 ip_conntrack_tftp 4344 1 ip_nat_tftp ip_nat_irc 2720 0 ip_conntrack_irc 6800 1 ip_nat_irc ip_nat_ftp 3328 0 ip_nat 16876 4 iptable_nat,ip_nat_tftp,ip_nat_irc,ip_nat_ftp ip_conntrack_ftp 7760 1 ip_nat_ftp ip_conntrack 49088 8 iptable_nat,ip_nat_tftp,ip_conntrack_tftp,ip_nat_irc,ip_conntrack_irc,ip_nat_ftp ,ip_nat,ip_conntrack_ftp ipv6 226016 16 ipt_LOG 6112 1 iptable_filter 3104 1 ip_tables 12964 3 iptable_mangle,iptable_nat,iptable_filter x_tables 13316 5 ipt_TCPMSS,xt_tcpudp,iptable_nat,ipt_LOG,ip_tables nfnetlink 6680 2 ip_nat,ip_conntrack button 6672 0 ac 5188 0 battery 9636 0 nls_iso8859_1 4256 0 isofs 32540 0 dm_snapshot 15520 0 dm_mirror 19152 0 dm_mod 50232 2 dm_snapshot,dm_mirror loop 15048 0 serio_raw 6660 0 i2c_i801 7404 0 floppy 53156 0 shpchp 33024 0 i2c_core 19680 1 i2c_i801 rtc 12372 0 psmouse 35016 0 pcspkr 3072 0 pci_hotplug 28704 1 shpchp evdev 9088 0 ext3 119208 3 jbd 52456 1 ext3 mbcache 8356 1 ext3 ide_cd 36064 0 cdrom 32544 1 ide_cd sd_mod 19040 5 ahci 17636 0 ata_piix 13576 4 libata 89332 2 ahci,ata_piix scsi_mod 124168 3 sd_mod,ahci,libata piix 9444 0 [permanent] ehci_hcd 28136 0 generic 5028 0 [permanent] ide_core 110504 3 ide_cd,piix,generic e1000 108512 0 uhci_hcd 21032 0 usbcore 112676 3 ehci_hcd,uhci_hcd thermal 13608 0 processor 28840 1 thermal fan 4804 0 Вставить ник Quote
user_anonymous Posted February 14, 2007 Posted February 14, 2007 Попробуйте добавить правила для отслеживания состояния соединений # Убъем кривые пакеты -A FORWARD -m state --state INVALID -j DROP # Будем пропускать пакеты от установившихся соединений. Это сильно увеличивает быстродействие и устраняет кучу проблем -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # Убъем левые пакеты -A FORWARD -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset -A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP # фильтрация. У себя я выделил фильтрацию в три отдельные цепочки по протоколам tcp, udp, icmp # делать так не обязательно. Но я посчитал, что это увеличит быстродействие, так как в среднем будет проходить по # меньшему количеству правил # -A FORWARD -p tcp -j forward_tcp_filter # -A FORWARD -p udp -j forward_udp_filter # -A FORWARD -p icmp -j icmp_filter # Пример фильтрации. -A FORWARD -p tcp -m tcp --dport 5190 -j ACCEPT -A FORWARD -p tcp -m tcp --dport 25 -j ACCEPT -A FORWARD -p tcp -m tcp --dport 110 -j ACCEPT # NAT *nat -A POSTROUTING -s СЕТЬ/МАСКА -o eth0 -j SNAT --to-source <ВАШ ВНЕШНИЙ IP> Вставить ник Quote
sire Posted February 14, 2007 Posted February 14, 2007 Попробуйте добавить правила для отслеживания состояния соединений # Убъем кривые пакеты -A FORWARD -m state --state INVALID -j DROP Согласен, сделаю. # Будем пропускать пакеты от установившихся соединений. Это сильно увеличивает быстродействие и устраняет кучу проблем-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT Планируется предоставлять доступ некоторым пользователям с реальными адресами, поэтому обрубать входящие соединения (--state NEW), по-моему, не следует. # Убъем левые пакеты-A FORWARD -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset -A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP Здесь, можно ещё много чего отфильтровать, в том числе попытки сканирования портов типа XMAS, NULL и т.п. Это, конечно, тоже следует сделать. # фильтрация. У себя я выделил фильтрацию в три отдельные цепочки по протоколам tcp, udp, icmp# делать так не обязательно. Но я посчитал, что это увеличит быстродействие, так как в среднем будет проходить по # меньшему количеству правил # -A FORWARD -p tcp -j forward_tcp_filter # -A FORWARD -p udp -j forward_udp_filter # -A FORWARD -p icmp -j icmp_filter Фильтрацию делать не буду, пусть юзеры делают, что хотят. Иначе "продвинутые" начнут жаловаться, что, мол, то не работает, это не фурычит. Спасибо за советы. Только, вот, имеют ли они отношение к проблемам с ICQ? Если да, то как? Другие службы-то работают! Вставить ник Quote
user_anonymous Posted February 14, 2007 Posted February 14, 2007 # Будем пропускать пакеты от установившихся соединений. Это сильно увеличивает быстродействие и устраняет кучу проблем -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT Планируется предоставлять доступ некоторым пользователям с реальными адресами, поэтому обрубать входящие соединения (--state NEW), по-моему, не следует. А новые соединения и не обрубаются. Обрубаются левые пакеты - посмотрите внимательно на флаги. До стадии фильтрации доходят только новые пакеты с установленным SYN-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP Обратите внимание на восклицательный знак. Это отрицание. Правило говорит: если обнаружен новый пакет с иной комбинацией флагов, чем должна быть для установки соединения - убить. Фильтрацию делать не буду, пусть юзеры делают, что хотят. Иначе "продвинутые" начнут жаловаться, что, мол, то не работает, это не фурычит.Сделайте это платной услугой :) Спасибо за советы. Только, вот, имеют ли они отношение к проблемам с ICQ? Если да, то как? Другие службы-то работают!Включение connection tracking ИМХО имеет к этому самое непосредственное отношение. У вас еще и с ФТП проблемы по идее должны возникать при таком конфиге. Вставить ник Quote
sire Posted February 14, 2007 Posted February 14, 2007 (edited) А новые соединения и не обрубаются. Обрубаются левые пакеты - посмотрите внимательно на флаги. До стадии фильтрации доходят только новые пакеты с установленным SYN-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP Обратите внимание на восклицательный знак. Это отрицание. Правило говорит: если обнаружен новый пакет с иной комбинацией флагов, чем должна быть для установки соединения - убить. Согласен, я ошибся, спасибо. Спасибо за советы. Только, вот, имеют ли они отношение к проблемам с ICQ? Если да, то как? Другие службы-то работают!Включение connection tracking ИМХО имеет к этому самое непосредственное отношение. У вас еще и с ФТП проблемы по идее должны возникать при таком конфиге. Проблем с ФТП нет, проверял, писал об этом выше. Поэтому проблему с ICQ считаю "странной", необычной. Edited February 14, 2007 by sire Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
![[anp/hsw]](http://cdn.nag.ru/forum.public.files/uploads/set_resources_11/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.