глюки с передачей данных через mpd. переполнение буферов etc
ipfw. ng_nat. у кого -нибудь работало?У меня
т.е. я хочу, чтобы все пакеты сначала занатились, потом разнатились. Если я правильно понимаю, то всё должно работать, как будто этих правил нет, но ничего не работает, например рвётся соединение с инетом.Этого не произойдёт в любом случае, потом что "заначивании" меняется source IP address, а при "разначивании" меняется destination IP address. Поэтому эти операции обе не могут быть произведены с одним и тем же пакетом. Бред.
Кроме того, действие netgraph в правилах ipfw означает конец поиска. Если ты хочешь, чтобы пакет далее шёл по правилам, то тебе нужно sysctl net.inet.ip.fw.one_pass=0.
Этого не произойдёт в любом случае, потом что "заначивании" меняется source IP address, а при "разначивании" меняется destination IP address. Поэтому эти операции обе не могут быть произведены с одним и тем же пакетом. Бред.
всё, понял. разобрался. спасибо.
net.inet.ip.fw.one_pass=0.
это конечно,
там же видно, что они дальше идут в ipfw show
вообще, я конфиг сильно урезал(при этом он кочнечно стал нерабочим). реально он больше и там всё должно работать.
cейчас бошка болит. конфиг завтра выложу
в общем идея в том, что пакеты при check-state показываются в логах как
Jul 25 00:00:42 steel kernel: ipfw: 8022 UNKNOWN TCP 10.1.1.1:2371 123.180.204.17:80 out via xl0
при этом они почему-то не доходят до нужного хоста.
сейчас сделал тоже самое дома.
видимо проблема не с ng_nat, а где-то ещё. (ниже всё не работает без ng_nat)
теже косяки.
сервак интерфейс rl1: 1.1.1.1. гейт 1.1.1.0 .. прописан по-умолчанию
сервак интерфейс rl2: 2.2.2.2. гейт 2.2.2.0.
сервак интерфейс rl3: 192.168.0.1
клиент: 192.168.0.20
проблема, которая ниже появлялась и до этого при разных обстоятельствах.
конфиг, на котором она наблюдается:
ipfw:
...
add 10000 log tcp established
add 10100 check-state
add 10200 fwd 2.2.2.0 ip from 192.168.0.20 to any keep-state
pf.conf:
nat on rl1 from 192.168.0.20 to any -> 1.1.1.1
nat on rl2 from 192.168.0.20 to any -> 2.2.2.2
pass in all
pass out all
т.е. хотим, чтобы куда отправить пакет решал ipfw, натил pf.
при этом отправляем весь трафик от 192.168.0.20 через 2.2.2.0
пингуем с 192.168.0.20 какой-нибудь хост в инете:
tcpdump -i rl1
тишина
tcpdump -i rl2
при этом /var/log/security
он даже по два раза применят fwd, а они всё равно не хотят
т.е. занатились непрвильно (должно быть 2.2.2.2)
к сожалению, log для правил nat, я не нашёл, как посмотреть
не ругается на
nat pass on rl1 from 192.168.0.20 to any -> 1.1.1.1
но ругается на
nat pass log on rl1 from 192.168.0.20 to any -> 1.1.1.1
если же дописать в pf.conf
pass out log route-to 1.1.1.0 from 1.1.1.1 to any
pass out log route-to 2.2.2.0 from 2.2.2.2 to any
получаем:
tcpdump -i rl1
строки 5-6: тоже самое, но с 192.168.0.20
уходят,правда не туда, куда мы хотим, НО:
пакеты с одним и тем же адресом назначения и отправителя.
те, что с локальной тачки возвтращаются
те, что для клиентов - нет.
если я правильно понимаю, то tcpdump показывает пакеты, которые ещё не обработаны фаерволом, поэтому я просто не мог что-то там написать, что отбрасывает одни и не отбрасывает другие.
видимо, я просто не до конца понимаю, как это всё устроено.
видимо проблема не с ng_nat, а где-то ещё. (ниже всё не работает без ng_nat)
теже косяки.
сервак интерфейс rl1: 1.1.1.1. гейт 1.1.1.0 .. прописан по-умолчанию
сервак интерфейс rl2: 2.2.2.2. гейт 2.2.2.0.
сервак интерфейс rl3: 192.168.0.1
клиент: 192.168.0.20
проблема, которая ниже появлялась и до этого при разных обстоятельствах.
конфиг, на котором она наблюдается:
ipfw:
...
add 10000 log tcp established
add 10100 check-state
add 10200 fwd 2.2.2.0 ip from 192.168.0.20 to any keep-state
pf.conf:
nat on rl1 from 192.168.0.20 to any -> 1.1.1.1
nat on rl2 from 192.168.0.20 to any -> 2.2.2.2
pass in all
pass out all
т.е. хотим, чтобы куда отправить пакет решал ipfw, натил pf.
при этом отправляем весь трафик от 192.168.0.20 через 2.2.2.0
пингуем с 192.168.0.20 какой-нибудь хост в инете:
tcpdump -i rl1
тишина
tcpdump -i rl2
07:00:48.960872 IP 1.1.1.1 > 194.135.22.115: ICMP echo request, id 58218, seq 52739, length 40
07:00:54.412399 IP 1.1.1.1 > 194.135.22.115: ICMP echo request, id 58218, seq 52995, length 40
при этом /var/log/security
Jul 27 07:40:54 steel kernel: ipfw: 43500 Forward to 2.2.2.0 TCP 192.168.0.20:2622 64.233.183.147:80 in via ng11
Jul 27 07:40:54 steel kernel: ipfw: 43500 Forward to 2.2.2.0 TCP 192.168.0.20:2622 64.233.183.147:80 out via ng2
он даже по два раза применят fwd, а они всё равно не хотят
т.е. занатились непрвильно (должно быть 2.2.2.2)
к сожалению, log для правил nat, я не нашёл, как посмотреть
не ругается на
nat pass on rl1 from 192.168.0.20 to any -> 1.1.1.1
но ругается на
nat pass log on rl1 from 192.168.0.20 to any -> 1.1.1.1
если же дописать в pf.conf
pass out log route-to 1.1.1.0 from 1.1.1.1 to any
pass out log route-to 2.2.2.0 from 2.2.2.2 to any
получаем:
tcpdump -i rl1
07:00:23.508804 IP 1.1.1.1 > 194.135.22.115: ICMP echo request, id 57191, seq 6, length 64строки 1-4 : это я с сервака пропинговал 194.135.22.115,
07:00:23.511928 IP 194.135.22.115 > 1.1.1.1: ICMP echo reply, id 57191, seq 6, length 64
07:00:24.509827 IP 1.1.1.1 > 194.135.22.115: ICMP echo request, id 57191, seq 7, length 64
07:00:24.513685 IP 194.135.22.115 > 1.1.1.1: ICMP echo reply, id 57191, seq 7, length 64
07:00:48.960872 IP 1.1.1.1 > 194.135.22.115: ICMP echo request, id 58218, seq 52739, length 40
07:00:54.412399 IP 1.1.1.1 > 194.135.22.115: ICMP echo request, id 58218, seq 52995, length 40
строки 5-6: тоже самое, но с 192.168.0.20
уходят,правда не туда, куда мы хотим, НО:
пакеты с одним и тем же адресом назначения и отправителя.
те, что с локальной тачки возвтращаются
те, что для клиентов - нет.
если я правильно понимаю, то tcpdump показывает пакеты, которые ещё не обработаны фаерволом, поэтому я просто не мог что-то там написать, что отбрасывает одни и не отбрасывает другие.
видимо, я просто не до конца понимаю, как это всё устроено.
итак...
есть сервак с freebsd 6.2 mpd4.1.
nve0
есть клиент с win xp home.
соединение по локальной сети 1 (сокращённо clientif)
nve0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.32.1 netmask 0xfffffffc broadcast 192.168.32.3
ether 00:50:00:00:00:00
clientif: 192.168.32.2/30
испытание 1:
c сервака ping 192.168.32.2 - всё ок.
с сервака ping -f 192.168.32.2
испытание 2:
с клиента ping 192.168.32.1 - всё ок.
испытание 3:
подключаем pptp.
на серваке интерфейс ng0 192.168.0.1 <-> 192.168.0.2
делаем ping -t 192.168.0.1 c с клиента
(там ровно 124 строчки ) - т.е. все ответы ушли отправителю
ПОСЛЕ этого пинги вообще перестают ходить.
НО если подождать минут
есть сервак с freebsd 6.2 mpd4.1.
nve0
есть клиент с win xp home.
соединение по локальной сети 1 (сокращённо clientif)
nve0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.32.1 netmask 0xfffffffc broadcast 192.168.32.3
ether 00:50:00:00:00:00
clientif: 192.168.32.2/30
испытание 1:
c сервака ping 192.168.32.2 - всё ок.
с сервака ping -f 192.168.32.2
PING 192.168.32.2 (192.168.32.2): 56 data bytes
............^C.
--- 192.168.32.2 ping statistics ---
56663 packets transmitted, 56650 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.115/0.282/4.790/0.134 ms
испытание 2:
с клиента ping 192.168.32.1 - всё ок.
испытание 3:
подключаем pptp.
на серваке интерфейс ng0 192.168.0.1 <-> 192.168.0.2
делаем ping -t 192.168.0.1 c с клиента
Статистика Ping для 192.168.0.1:tcpdump -i ng0
Пакетов: отправлено = 62, получено = 31, потеряно = 31 (50% потерь
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Control-C
(там ровно 124 строчки ) - т.е. все ответы ушли отправителю
06:04:53.111160 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 29440, length 40начинаю пинговать с сервака.
06:04:58.611793 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 29696, length 40
06:04:58.611832 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 29696, length 40
06:04:59.611908 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 29952, length 40
06:04:59.611943 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 29952, length 40
06:05:05.112563 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 30208, length 40
06:05:05.112598 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 30208, length 40
06:05:06.112701 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 30464, length 40
06:05:06.112741 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 30464, length 40
06:05:11.613356 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 30720, length 40
06:05:11.613392 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 30720, length 40
06:05:12.613472 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 30976, length 40
06:05:12.613511 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 30976, length 40
06:05:18.114150 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 31232, length 40
06:05:18.114188 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 31232, length 40
06:05:19.114242 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 31488, length 40
06:05:19.114285 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 31488, length 40
06:05:24.614906 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 31744, length 40
06:05:24.614946 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 31744, length 40
06:05:25.615030 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 32000, length 40
06:05:25.615076 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 32000, length 40
06:05:31.115684 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 32256, length 40
06:05:31.115719 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 32256, length 40
06:05:32.115823 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 32512, length 40
06:05:32.115877 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 32512, length 40
06:05:37.616474 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 32768, length 40
06:05:37.616512 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 32768, length 40
06:05:38.616579 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 33024, length 40
06:05:38.616615 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 33024, length 40
06:05:44.117274 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 33280, length 40
06:05:44.117316 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 33280, length 40
06:05:45.117381 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 33536, length 40
06:05:45.117421 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 33536, length 40
06:05:50.618015 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 33792, length 40
06:05:50.618051 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 33792, length 40
06:05:51.618135 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 34048, length 40
06:05:51.618176 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 34048, length 40
06:05:57.118791 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 34304, length 40
06:05:57.118829 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 34304, length 40
06:05:58.118911 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 34560, length 40
06:05:58.118947 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 34560, length 40
06:06:03.619612 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 34816, length 40
06:06:03.619651 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 34816, length 40
06:06:04.619692 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 35072, length 40
06:06:04.619734 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 35072, length 40
06:06:10.120350 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 35328, length 40
06:06:10.120386 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 35328, length 40
06:06:11.120507 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 35584, length 40
06:06:11.120546 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 35584, length 40
06:06:16.621131 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 35840, length 40
06:06:16.621172 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 35840, length 40
06:06:17.621250 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 36096, length 40
06:06:17.621286 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 36096, length 40
06:06:23.121933 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 36352, length 40
06:06:23.121973 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 36352, length 40
06:06:24.122030 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 768, seq 36608, length 40
06:06:24.122068 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 768, seq 36608, length 40
32 steel ~(0/3)# ping 192.168.65.1
PING 192.168.65.1 (192.168.65.1): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ПОСЛЕ этого пинги вообще перестают ходить.
НО если подождать минут
ipfw:презервативы ты тоже всегда парами одеваешь?
...
pf.conf:
Оставить комментарий
Phoenix
судя по всему проблема где-то глубже.притащил ноут.
соединил напрямую... -
создаём ноду
mkpeer ipfw: nat out 20
name ipfw:out nattest
connect ipfw: nattest: 21 in
msg nattest: setaliasaddr 10.10.10.10
$9:42 steel ~(0/2)$ sudo ngctl show nattest:
Name: nattest Type: nat ID: 0000096e Num hooks: 2
Local hook Peer name Peer type Peer ID Peer hook
---------- --------- --------- ------- ---------
out ipfw ipfw 00000001 21
in ipfw ipfw 00000001 20
пишем в самом начале:
37 steel ~(0/3)# ipfw show 0-100
00089 925 102986 count ip from any to any
00090 924 102926 netgraph 21 ip from any to any
00091 924 102926 netgraph 20 ip from any to any
00092 924 102926 count ip from any to any
00100 3 185 allow ip from any to any via lo0
куда-то делся один пакет =) но это не суть. важно, что не работает
т.е. я хочу, чтобы все пакеты сначала занатились, потом разнатились. Если я правильно понимаю, то всё должно работать, как будто этих правил нет, но ничего не работает, например рвётся соединение с инетом.
Jul 25 09:40:06 steel kernel: ipfw: 89 Count ICMP:8.0 172.16.20.1 172.16.22.10 in via rl0
Jul 25 09:40:06 steel kernel: ipfw: 92 Count ICMP:8.0 10.0.0.10 172.16.22.10 in via rl0