[Bear_UA]

Попробовали вместо PF попользовать ipfw nat на одном из НАС.

Все красиво работает но столкнулись с одной проблемой.

Невозможно сделать traceroute с этого акцесника никуда.

Тупо рисует звездочки и все. Убираем ipfw nat - трейсроут начинает работать.

Кто сталкивался и как бороть?

[Ainy]

Как бы конфиги не плохо было бы приложить(релевантную к вопросу часть). И uname -a.

 

[Bear_UA]

#ipfw list
00100 nat 1 ip from table(1) to any out via vlan0
00200 nat 1 ip from any to x.x.x.x in via vlan0
65535 allow ip from any to any
#ipfw nat 1 show config
ipfw nat 1 config if vlan0 same_ports
#uname -a
FreeBSD x 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Fri Apr  9 11:45:36 EEST 2010     x@x:/usr/src/sys/i386/compile/x  i386

Изменено 21 октября, 2010 пользователем Bear_UA

[Ainy]

С uname -a типа норм, хотя обновить не помешало бы до 7.3-RELENG

И как тут может работать traceroute?

Если нат вокруг 1 интерфейса и в те же порты?

Если запустить traceroute -s whiteip destip то работает?

[Bear_UA]

Нат в белый айпишник делается. на влан0 висит белый айпишник.

[Ainy]

Белый и серый адреса оба на vlan0?

[Bear_UA]

На влан0 только белый адрес. Серые адреса выдаются на пппое подключениях. Да и какая разница где серый адрес если я трейсроут не могу с белого адреса сделать. Убираю нат - трейс работает. Включаю нат через PF - трейс тоже работает.

[st_re]

ipfw table 1 add x.x.x.x

где x.x.x.x берется из правила 200.

 

Просто нат приходящие ответы на трейс рут (ттл ексидед) пытается по вторичным половым признакам сопоставить со своей таблицей. Походу, если не может, он пакеты такие дропает. Наверное это не очень правильно, в случае если не стоит deny_in, наверное нуно написать send_pr.

 

Ну а пока не поправили, или добавить внешний IP в исходящий нат, чтобы он был в таблице, или забить на трейс рут (скорее всего вообще на все icmp со всеми ошибками с сторону внешнего IP), или, если количество IP позволяет, натить не в дефолтный адрес (разнести трафик, исходящий с сервера и трафик для ната на разные IP)

[Ainy]

На влан0 только белый адрес. Серые адреса выдаются на пппое подключениях. Да и какая разница где серый адрес если я трейсроут не могу с белого адреса сделать. Убираю нат - трейс работает. Включаю нат через PF - трейс тоже работает.

Дык я ж спросил - с соурсом белого адреса с этими правилами трейс ходит или нет - ответа не было.

Надо по каунтерам найти где матчатся ответы на трейс и в каком виде они уходят.

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

Недавно на тест выкладывали 3-й ipfw - до него руик пока не дошли.

прежде чем pr слать надо таки понять где именно баг. А то там таких pr из 400 с небольшим - половина.

 

[st_re]

со счетчиком там у него, как раз, все ясно. уходящий трейс (удп или icmp) уходит по 65535, входящие icmp ttl exc. попадают в 200 и оттуда далее не проваливаются. а, например при трейсе по icmp последний хост шлет icmp ответ и этот уже проходит через 200 правило, а потом, как и должен, сваливается в 65535.

 

Если сходящий с самого хоста добавить в таблицу, уходить будет по 100 правилу, и все ответы будут правильно отрабатывать по 200 правилу.

 

Берем восьмерку, пару дней давности. фаервол в ядре, ipfw_nat тоже (def to accept). Машина, пока, тестовая. трафик только паразитный

 

# ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:1b:21:75:ee:5e
        inet x.x.x.41 netmask 0xffffff00 broadcast x.x.x.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

#ipfw flush
Are you sure? [yn] y

Flushed all rules.

#ipfw nat 1 config ip x.x.x.41 same_ports
#ipfw add 1 pass ip from any to any via lo0

#ipfw add 00100 nat 1 ip from table\(1\) to any out via em0
#ipfw add 00200 nat 1 ip from any to x.x.x.41 in via em0

# traceroute www.ya.ru
traceroute: Warning: www.ya.ru has multiple addresses; using 77.88.21.3
traceroute to ya.ru (77.88.21.3), 64 hops max, 52 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13 ^C

# traceroute -P icmp  www.ya.ru
traceroute: Warning: www.ya.ru has multiple addresses; using 213.180.204.3
traceroute to ya.ru (213.180.204.3), 64 hops max, 72 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  www.yandex.ru (213.180.204.3)  5.462 ms  4.142 ms  4.912 ms

#ipfw table 1 add x.x.x.41

# traceroute -P icmp  www.ya.ru
traceroute: Warning: www.ya.ru has multiple addresses; using 93.158.134.3
traceroute to ya.ru (93.158.134.3), 64 hops max, 72 byte packets
1  ххх  2.633 ms  2.769 ms  2.742 ms
2  ххх  3.250 ms  3.596 ms  3.241 ms
3  ххх  4.909 ms  4.531 ms  3.256 ms
4  ххх  4.856 ms  4.655 ms  4.896 ms
5  popovich-vlan120.yandex.net (87.250.233.126)  4.829 ms  4.821 ms  3.300 ms
6  l3-s900-s400.yandex.net (213.180.213.57)  3.197 ms  4.314 ms  4.846 ms
7  www.yandex.ru (93.158.134.3)  3.291 ms  3.326 ms  4.881 ms

# traceroute www.ya.ru
traceroute: Warning: www.ya.ru has multiple addresses; using 77.88.21.3
traceroute to ya.ru (77.88.21.3), 64 hops max, 52 byte packets
1  xxx  3.000 ms  3.238 ms  1.623 ms
2  xxx  4.833 ms  4.742 ms  4.865 ms
3  xxx  3.270 ms  4.767 ms  4.832 ms
4  xxx  4.817 ms  4.749 ms  3.925 ms
5  grechko-vlan120.yandex.net (87.250.233.125)  4.200 ms  3.494 ms  4.849 ms
6  l3-s550-s450.yandex.net (213.180.213.23)  4.877 ms  3.655 ms  3.240 ms
7  l3-s650-s550.yandex.net (213.180.213.29)  4.817 ms  3.499 ms  4.773 ms
8  www.yandex.ru (77.88.21.3)  4.872 ms  4.284 ms  3.266 ms

 

Кстати, если тут убрать .41 из таблицы, оно все равно работает. Походу в nat таблицах что то остается.

 

[Ainy]

забавно. это можно и оформить в PR