РЕШЕНО. Проблема в свиче, там были запрещающие ACL. Подправили и всё заработало как и должно было.
1 13-04-2010 11:50:46
Re: MPD+NAT некоторые пакеты не доходят (6 ответов, оставленных в Иные программы.)
2 24-03-2010 16:06:31
Re: MPD+NAT некоторые пакеты не доходят (6 ответов, оставленных в Иные программы.)
ankor пишет:
Когда "упешно"
google-public-dns-a.google.com.domain > 172.17.253.41.53240: 31808 NXDomain 0/1/0 (95)
а когда нет:
94.232.184.42.domain > 172.17.253.41.52234: 27503 1/13/12 A origin.bmw.com (444)
т.е. к разным DNS обращается?
Какой DNS прописан, для серой сетки?
В этом вся и загвоздка. С левых DNS пакеты успешно доходят до клиента, а со своих тоже белых - нет.
DNSы по умолчанию в MPD прописаны свои белые.
3 24-03-2010 14:43:27
Re: MPD+NAT некоторые пакеты не доходят (6 ответов, оставленных в Иные программы.)
Весь deny log просканирован и следов дропания не замечено совершенно.
4 24-03-2010 14:08:56
Re: IPFW forwarding на другой хост по 80 порту (9 ответов, оставленных в FreeBSD & BSD)
Итак.
Благодаря опыту ошибок трудных, решил добить эту тему, которую когда-то открыл.
Весь косяк в этой теме заключался в том что пакеты уходили на дефолтный шлюз, а не на тот который указывался в
правиле ipfw fwd, поскольку для успешного перенаправления пакетов нужно чтобы хост переправитель и хост получатель были в одном домене. Т.е. форвард заключается в том что в пакете который попадает под правило форвардинга модифицируется только мак адрес назначения. В данном случае система просто не находилась в одном широковещательном домене ни по одному из сетевых интерфейсов и пакет, за неимением мак адреса форвард-таргета (хоста получателя), отправлялся по дефолту.
5 24-03-2010 11:02:24
Тема: MPD+NAT некоторые пакеты не доходят (6 ответов, оставленных в Иные программы.)
[ pptp client ] ------ [ vpn mpd5 ] ---- [ nat gateway ] ---- [ WAN router ]
Не понимаю, почему запросы в нашу белую сеть из нашей серой сети через NAT "зависают в воздухе" или ещё черт знает где.
Все остальные, т.е. абсолютно любые запросы по любым сервисам на любые хосты, только не наши, прибегают в результате обратно к клиенту успешно.
Серая сеть назначается вторым пулом из радиуса.
В частности , вот что происходит с сервисом DNS
Когда на клиенте 172.17.253.41:
dig bmw.com @8.8.8.8
запрос DNS успешен
На NATе:
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 67: 172.17.253.41.59508 > google-public-dns-a.google.com.domain: 875+ A? bmw.com. (25)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 83: google-public-dns-a.google.com.domain > 172.17.253.41.59508: 875 1/0/0 A origin.bmw.com (41)
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 62: 172.17.253.41.53240 > google-public-dns-a.google.com.domain: 60589+ A? 94. (20)
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 62: 172.17.253.41.53240 > google-public-dns-a.google.com.domain: 31808+ AAAA? 94. (20)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 137: google-public-dns-a.google.com.domain > 172.17.253.41.53240: 60589 NXDomain 0/1/0 (95)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 137: google-public-dns-a.google.com.domain > 172.17.253.41.53240: 31808 NXDomain 0/1/0 (95)На MPD:
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 67: 172.17.253.41.59508 > google-public-dns-a.google.com.domain: 875+ A? bmw.com. (25)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 83: google-public-dns-a.google.com.domain > 172.17.253.41.59508: 875 1/0/0 A origin.bmw.com (41)
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 62: 172.17.253.41.53240 > google-public-dns-a.google.com.domain: 60589+ A? 94. (20)
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 62: 172.17.253.41.53240 > google-public-dns-a.google.com.domain: 31808+ AAAA? 94. (20)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 137: google-public-dns-a.google.com.domain > 172.17.253.41.53240: 60589 NXDomain 0/1/0 (95)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 137: google-public-dns-a.google.com.domain > 172.17.253.41.53240: 31808 NXDomain 0/1/0 (95)Когда на клиенте 172.17.253.41:
dig bmw.com @94.232.184.42
запрос DNS по таймауту неуспешен
На NATе:
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 67: 172.17.253.41.52234 > 94.232.184.42.domain: 27503+ A? bmw.com. (25)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 486: 94.232.184.42.domain > 172.17.253.41.52234: 27503 1/13/12 A origin.bmw.com (444)
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 67: 172.17.253.41.52234 > 94.232.184.42.domain: 27503+ A? bmw.com. (25)
00:0c:29:91:6b:5f (oui Unknown) > 00:15:17:a3:b1:bd (oui Unknown), ethertype IPv4 (0x0800), length 486: 94.232.184.42.domain > 172.17.253.41.52234: 27503 1/13/12 A origin.bmw.com (444)На MPD:
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 67: 172.17.253.41.52234 > 94.232.184.42.domain: 27503+ A? bmw.com. (25)
00:15:17:a3:b1:bd (oui Unknown) > 00:0c:29:91:6b:5f (oui Unknown), ethertype IPv4 (0x0800), length 67: 172.17.253.41.52234 > 94.232.184.42.domain: 27503+ A? bmw.com. (25)И это со всеми запросами к любым серверам в нашей белой сети, т.е. например http также подвисают в воздухе.
6 28-09-2009 09:56:43
Re: IPFW forwarding на другой хост по 80 порту (9 ответов, оставленных в FreeBSD & BSD)
Alexander пишет:
Вот выдернул из рабоего конфига
${fwcmd} add fwd 193.33.96.46,81 tcp from any to aucland.lt 80 keep-state ${fwcmd} add fwd 193.33.96.46,82 tcp from any to mirror.aucland.lt 80 keep-state
193.33.96.46 - это локальный IP? т.е. этой же тачки что и на которой IPFW работает?
7 25-09-2009 14:14:14
Тема: IPFW forwarding на другой хост по 80 порту (9 ответов, оставленных в FreeBSD & BSD)
Судя по строке в мане ipfw в которую
все тычат, forwarding не заменяет адрес назначения, а как он тогда соббственно будет перенаправлять без модификации
пакета?
Есть freebsd mpd сервер доступа, который раздаёт туннели ng*.
Делаю редирект средствами ipfw на самом сервере. Опция IP_FIREWALL_FORWARD скомпилирована.
ng_ipfw.ko загружен.
Нужно например клиента с туннелем
pptp - 95.87.6.22 ng1 при попытке зайти на http перенаправить его на отдельный WEB сервер
http - 95.87.5.1 чтобы тот прочитал про причины "отлупа" (вирусы, баланс)
allow tcp from any to 95.87.5.1 80 out
allow tcp from 95.87.5.1 80 to any in
allow udp from any to any 53
allow udp from any 53 to any
fwd 95.87.5.1:80 log tcp from any to any 80 via ng1
deny all from any to anyпроверяю с клиента:
telnet abc.ru 80
на сервере ловлю пакеты:
tcpdump -i ng1 port 80
IP 95.87.5.22.2595 > abc4.abc.ru.http: S 3510851316:3510851316(0) win 16384 <mss 1360,nop,nop,sackOK>ну и соответственно на WEB сервере в дампе TCP тишина.
При этом в ipfw show прибавляется счётчик по правилу форвардинга и в логе security тоже соответвующее уведомление
vpn2 kernel: ipfw: 216 Forward to 95.87.5.1:80 TCP 95.87.5.22:
3036 188.162.216.140:80 in via ng1Я так понимаю что при таком дампе пакет просто убегает туда куда он и хотел, т.е. никакого перенаправления не вышло.
Что же это такое, везде пишут что такое должно работать, а у меня не работает.