kirush Posted July 19, 2010 Posted July 19, 2010 (edited) Добрый день! OS: FreeBSD 7.3 Схема узла: Internet ----[ em0 -------router -----em1] ------switch------[em0 ------- nas ------- em1] ---------clients на НАСе: # tcptraceroute -i em0 -p 1024 -s 91.207.115.127 80.252.144.196 3333 Selected device em0, address 91.207.115.27, port 1024 for outgoing packets Tracing the path to 80.252.144.196 on TCP port 3333, 30 hops max 1 192.168.0.254 (192.168.0.254) 10.015 ms 10.052 ms 10.204 ms 2 PROTVINO-NET-gw.prime-line.ru (77.91.64.45) 10.118 ms 10.033 ms 10.088 ms 3 noname.prime-line.ru (77.91.65.71) 10.108 ms 10.159 ms 10.179 ms 4 m9-ix.flex.ru (193.232.244.222) 10.126 ms 9.961 ms 10.168 ms 5 80.252.141.235 (80.252.141.235) 10.171 ms 10.075 ms 10.158 ms Если любой порт < 1024 вижу такую картину: # tcptraceroute -i em0 -p 20 -s 91.207.115.127 80.252.144.196 3333 Selected device em0, address 91.207.115.127, port 20 for outgoing packets Tracing the path to 80.252.144.196 on TCP port 3333, 30 hops max 1 * * и т.д. tcpdumpом во втором случае на em1 routerа, пакетов не вижу, т.е. пакеты не уходят с NASа. ipfw не закрыто. Может где то в ядре по умолчанию закрыто или в sysctl? Как выйти из ситуации? Необходимо открыть 20/21 порты для работы клиента. На роутере стоит zebra. С НАСа делаю: tcptraceroute -i em0 -p 1000 -s 91.207.115.127 80.252.144.196 3333 трейс не идет, в дампе на этом же интерфейсе вижу: # tcpdump -i em0 -n -vv host 80.252.144.196 tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 12:58:54.002172 IP (tos 0x0, ttl 5, id 51060, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.1000 > 80.252.144.196.3333: S, cksum 0xede6 (correct), 0:0(0) win 0 12:58:57.049849 IP (tos 0x0, ttl 5, id 51342, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.1000 > 80.252.144.196.3333: S, cksum 0xede6 (correct), 0:0(0) win 0 12:59:00.095034 IP (tos 0x0, ttl 6, id 52649, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.1000 > 80.252.144.196.3333: S, cksum 0xede6 (correct), 0:0(0) win 0 ^C 3 packets captured Но на роутере на внешнем интерфейсе em0 не вижу этих пакетов. если делаю tcptraceroute -i em0 -p 2000 -s 91.207.115.127 80.252.144.196 3333 трейс идет, в дампе на этом же интерфейсе NAS'a вижу: # tcpdump -i em0 -n -vv host 80.252.144.196 tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 12:59:12.299283 IP (tos 0x0, ttl 2, id 20716, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 12:59:12.301204 IP (tos 0x0, ttl 3, id 55205, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 12:59:12.312012 IP (tos 0x0, ttl 3, id 62155, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 12:59:12.322114 IP (tos 0x0, ttl 3, id 17139, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 12:59:12.332350 IP (tos 0x0, ttl 4, id 62321, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 12:59:12.343368 IP (tos 0x0, ttl 4, id 33632, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 12:59:12.353393 IP (tos 0x0, ttl 4, id 13314, offset 0, flags [none], proto TCP (6), length 40) 91.207.115.127.2000 > 80.252.144.196.3333: S, cksum 0xe9fe (correct), 0:0(0) win 0 на роутере на внешнем интерфейсе em0 вижу эти пакеты. Edited July 20, 2010 by kirush Вставить ник Quote
Giga-Byte Posted July 19, 2010 Posted July 19, 2010 (edited) хост вообще достижим? я склоняюсь, у них там фаерволл. # nmap -p 3333 80.252.144.196 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-07-19 15:44 YEKST Interesting ports on 80.252.144.196: PORT STATE SERVICE 3333/tcp filtered dec-notes Edited July 20, 2010 by Giga-Byte Вставить ник Quote
kirush Posted July 19, 2010 Author Posted July 19, 2010 дык ясно, что проблема у меня, если в качестве source порта ставлю любой порт <1025 трейс идет, если >1024 то нет. Вставить ник Quote
YuryD Posted July 19, 2010 Posted July 19, 2010 С каких пор клиенты начали открывать соединение с портов ftp/ftp-data ? Или у клиента реальник и свой ftp ? Клиенты обычно открывают исходящие соединения с портов выше 1024... Вставить ник Quote
kirush Posted July 19, 2010 Author Posted July 19, 2010 (edited) У клиента реальник и он хочет active ftp как сервер так и клиент (91.207.115.127 именно его ИП). Edited July 20, 2010 by kirush Вставить ник Quote
YuryD Posted July 20, 2010 Posted July 20, 2010 У клиента реальник и он хочет active ftp как сервер так и клиент (91.207.114.127 именно его ИП). Ну затык у вас где-то 5 cat06.Moscow.gldn.net (194.186.157.130) 30.955 ms 52.989 ms 30.930 ms 6 mail.landactive.ru (194.154.71.38) 31.513 ms 31.483 ms 31.398 ms 7 PROTVINO-NET.prime-line.ru (77.91.64.46) 32.496 ms 32.673 ms 32.661 ms 8 * * * 9 * * * У вас там 192.168. в трейсе светится, нет ли ната, и случайно не натит ли он все ? Вставить ник Quote
kirush Posted July 20, 2010 Author Posted July 20, 2010 (edited) На роутере стоит NAT. router: 00040 allow ip from 91.207.115.112/28 to any 00040 allow ip from any to 91.207.115.112/28 а потом только идут правила НАТа. Т.е. эти реальники должны пропускаться без НАТа Edited July 20, 2010 by kirush Вставить ник Quote
YuryD Posted July 20, 2010 Posted July 20, 2010 На роутере стоит NAT.router: 00040 allow ip from 91.207.115.112/28 to any 00040 allow ip from any to 91.207.115.112/28 а потом только идут правила НАТа. Т.е. эти реальники должны пропускаться без НАТа Это в случае one.pass Если у вас natd то там есть хороший ключик -u. Ну просканьте клиента nmap-ом c роутера - будут ли у него порты 20/21 открыты ? Вставить ник Quote
kirush Posted July 21, 2010 Author Posted July 21, 2010 Не очень понимаю как может это мне помочь: -unregistered_only | -u Only alter outgoing packets with an unregistered source address. According to RFC 1918, unregistered source addresses are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. firewall ядренный. Вставить ник Quote
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.