[freebsd] Re: [freebsd] natd не натит
Мне нужно, дабы пакеты из сети 172.17.5.0/24 натились на адрес
172.31.249.1 и отправлялись дальше в сеть 192.168.137.0/24. Т.е.
приходит из tun1, натится на один из адресов lo1, идёт дальше по
таблице маршрутизации.
2014-12-08 15:07 GMT+02:00 Anton Sayetsky :
> Приветствую, коллеги.
>
> Имеется сабж с natd. Выхлоп демона и конфиги:
> root@vpnc:~# natd -f /etc/natd.conf -v
> natd[5339]: Aliasing to 172.31.249.1, mtu 16384 bytes
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>
> 00010 1856 661896 allow ip from any to any via lo0 // allow local traffic
> 00020 0 0 deny ip from any to 127.0.0.0/8
> 00030 0 0 deny ip from 127.0.0.0/8 to any
> 00040 0 0 deny ip from any to ::1
> 00050 0 0 deny ip from ::1 to any
> 00060 0 0 deny ip from table(1) to any // fail2ban
> 00070 0 0 deny ip from any to table(1)
> 00080 0 0 deny ip from table(2) to any // blocked clients
> 00090 0 0 deny ip from any to table(2)
> 00100 0 0 deny ip from any to 0.0.0.0/8 // block source net
> 00110 0 0 deny ip from 0.0.0.0/8 to any
> 00120 0 0 deny ip from table(3) to any // block reserved networks
> 00130 0 0 deny ip from any to table(3)
> 00140 30318 3971601 reass ip4 from any to any in
> 00150 0 0 deny log ip4 from any to any frag in
> 00155 1008400 divert ip from any to any via tun1
> 65534 54914 7634273 allow log ip from any to any
> 65535 0 0 deny ip from any to any
>
> lo1: flags=8049 metric 0 mtu 16384
> options=63
> inet 172.31.249.1 netmask 0xff00
> inet 172.31.249.2 netmask 0x
> inet 172.31.249.3 netmask 0x
> nd6 options=29
>
> root@vpnc:~# cat /etc/natd.conf
> #
>
> log
> #deny_incoming
> log_denied
> same_ports
>
> instance default
> port
> interface lo1
>
> ЧЯДНТ?
[freebsd] Re: [freebsd] natd не натит
Тем более, оно [natd] говорит:
natd[5339]: Aliasing to 172.31.249.1, mtu 16384 bytes
То, что и нужно. Но почему-то нет фактической трансляции.
8 декабря 2014 г., 15:17 пользователь Anton Sayetsky
написал:
> Мне нужно, дабы пакеты из сети 172.17.5.0/24 натились на адрес
> 172.31.249.1 и отправлялись дальше в сеть 192.168.137.0/24. Т.е.
> приходит из tun1, натится на один из адресов lo1, идёт дальше по
> таблице маршрутизации.
>
> 2014-12-08 15:07 GMT+02:00 Anton Sayetsky :
>> Приветствую, коллеги.
>>
>> Имеется сабж с natd. Выхлоп демона и конфиги:
>> root@vpnc:~# natd -f /etc/natd.conf -v
>> natd[5339]: Aliasing to 172.31.249.1, mtu 16384 bytes
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>> In {default}[ICMP] [ICMP] 172.17.5.4 -> 192.168.137.51 8(0) aliased to
>>[ICMP] 172.17.5.4 -> 192.168.137.51 8(0)
>>
>> 00010 1856 661896 allow ip from any to any via lo0 // allow local traffic
>> 00020 0 0 deny ip from any to 127.0.0.0/8
>> 00030 0 0 deny ip from 127.0.0.0/8 to any
>> 00040 0 0 deny ip from any to ::1
>> 00050 0 0 deny ip from ::1 to any
>> 00060 0 0 deny ip from table(1) to any // fail2ban
>> 00070 0 0 deny ip from any to table(1)
>> 00080 0 0 deny ip from table(2) to any // blocked clients
>> 00090 0 0 deny ip from any to table(2)
>> 00100 0 0 deny ip from any to 0.0.0.0/8 // block source net
>> 00110 0 0 deny ip from 0.0.0.0/8 to any
>> 00120 0 0 deny ip from table(3) to any // block reserved networks
>> 00130 0 0 deny ip from any to table(3)
>> 00140 30318 3971601 reass ip4 from any to any in
>> 00150 0 0 deny log ip4 from any to any frag in
>> 00155 1008400 divert ip from any to any via tun1
>> 65534 54914 7634273 allow log ip from any to any
>> 65535 0 0 deny ip from any to any
>>
>> lo1: flags=8049 metric 0 mtu 16384
>> options=63
>> inet 172.31.249.1 netmask 0xff00
>> inet 172.31.249.2 netmask 0x
>> inet 172.31.249.3 netmask 0x
>> nd6 options=29
>>
>> root@vpnc:~# cat /etc/natd.conf
>> #
>>
>> log
>> #deny_incoming
>> log_denied
>> same_ports
>>
>> instance default
>> port
>> interface lo1
>>
>> ЧЯДНТ?
Re: [freebsd] Re: [freebsd] natd не натит
On 08.12.2014 20:17, Anton Sayetsky wrote: Ради бога, не надо топ-квотинга, жутко неудобно отвечать на конкретные строчки. По сути см. ниже. >> lo1: flags=8049 metric 0 mtu 16384 >> options=63 >> inet 172.31.249.1 netmask 0xff00 >> inet 172.31.249.2 netmask 0x >> inet 172.31.249.3 netmask 0x >> nd6 options=29 >> >> root@vpnc:~# cat /etc/natd.conf >> # >> >> log >> #deny_incoming >> log_denied >> same_ports >> >> instance default >> port >> interface lo1 >> >> ЧЯДНТ? > Мне нужно, дабы пакеты из сети 172.17.5.0/24 натились на адрес > 172.31.249.1 и отправлялись дальше в сеть 192.168.137.0/24. Т.е. > приходит из tun1, натится на один из адресов lo1, идёт дальше по > таблице маршрутизации. Замени строку interface lo1 на строку alias_address 172.31.249.1
[freebsd] Re: [freebsd] Re: [freebsd] natd не натит
По поводу "топ-квотинга":
https://groups.google.com/forum/#!msg/uafug/PnUizookwUo/MJz7sLmDbyMJ
Когда надо отвечать на конкретные строки - то вставляю ответ в нужное
место, конечно же.
alias_address не помогает (делал изначально через него) - source не меняется
root@vpnc:~# ifconfig lo1
lo1: flags=8049 metric 0 mtu 16384
options=63
inet 172.31.249.1 netmask 0xff00
inet 172.31.249.2 netmask 0x
inet 172.31.249.3 netmask 0x
nd6 options=29
root@vpnc:~# natd -f /etc/natd.conf -v
In {default}[ICMP] [ICMP] 172.17.5.6 -> 192.168.137.13 8(0) aliased to
[ICMP] 172.17.5.6 -> 192.168.137.13 8(0)
In {default}[ICMP] [ICMP] 172.17.5.6 -> 192.168.137.13 8(0) aliased to
[ICMP] 172.17.5.6 -> 192.168.137.13 8(0)
In {default}[ICMP] [ICMP] 172.17.5.6 -> 192.168.137.13 8(0) aliased to
[ICMP] 172.17.5.6 -> 192.168.137.13 8(0)
^C
root@vpnc:~# cat /etc/natd.conf
#
log
#deny_incoming
log_denied
same_ports
instance default
port
alias_address 172.31.249.1
root@vpnc:~# uname -a
FreeBSD vpnc.dt.local 10.1-RELEASE FreeBSD 10.1-RELEASE #0: Mon Dec 8
09:34:03 UTC 2014 r...@vpnc.dt.local:/tmp/obj/
usr/src/sys/VPNC
amd64
root@vpnc:~# cat /sys/amd64/conf/VPNC
#
include GENERIC
ident VPNC
options IPSEC
device crypto
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=0
options IPDIVERT
root@vpnc:~#
8 декабря 2014 г., 15:34 пользователь Eugene Grosbein
написал:
> On 08.12.2014 20:17, Anton Sayetsky wrote:
>
> Ради бога, не надо топ-квотинга, жутко неудобно отвечать
> на конкретные строчки. По сути см. ниже.
>
>>> lo1: flags=8049 metric 0 mtu 16384
>>> options=63
>>> inet 172.31.249.1 netmask 0xff00
>>> inet 172.31.249.2 netmask 0x
>>> inet 172.31.249.3 netmask 0x
>>> nd6 options=29
>>>
>>> root@vpnc:~# cat /etc/natd.conf
>>> #
>>>
>>> log
>>> #deny_incoming
>>> log_denied
>>> same_ports
>>>
>>> instance default
>>> port
>>> interface lo1
>>>
>>> ЧЯДНТ?
>
>> Мне нужно, дабы пакеты из сети 172.17.5.0/24 натились на адрес
>> 172.31.249.1 и отправлялись дальше в сеть 192.168.137.0/24. Т.е.
>> приходит из tun1, натится на один из адресов lo1, идёт дальше по
>> таблице маршрутизации.
>
> Замени строку interface lo1 на строку alias_address 172.31.249.1
>
Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
Hello, Anton Sayetsky! > >>> root@vpnc:~# cat /etc/natd.conf > >>> # > >>> > >>> log > >>> #deny_incoming > >>> log_denied > >>> same_ports > >>> > >>> instance default > >>> port > >>> interface lo1 > >>> > >>> ЧЯДНТ? А можно вопрос: почему user-nat ? Почему не ipfw nat ? > >> Мне нужно, дабы пакеты из сети 172.17.5.0/24 натились на адрес > >> 172.31.249.1 и отправлялись дальше в сеть 192.168.137.0/24. Т.е. > >> приходит из tun1, натится на один из адресов lo1, идёт дальше по > >> таблице маршрутизации. > > > > Замени строку interface lo1 на строку alias_address 172.31.249.1 > > -- Lystopad Aleksandr
Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On Mon, Dec 08, 2014 at 05:49:12PM +0200, Anton Sayetsky wrote: > >> Т.е.приходит из tun1, натится на один из адресов lo1, идёт дальше по > >> таблице маршрутизации. Без схемы было сложно понять, что транслировать трафик нужно на входе, а не традиционно на выходе. В этом случае нужно использовать не один divert-сокет , а два разных, указывая их через in_port и out_port и заворачивая out_port трафик, приходящий через tun1 - для подмены src IP. А в in_port заворачивать трафик, уходящий в tun1 - для трансляции ответов. В каждом новом письме треда была существенная информация для понимания. Без квоты сохранять историю обсуждения сложно, при топ-квотинге её вообще невозможно сохранять линейной, если вручную не переносить твой текст вниз при ответе, так что в следующий раз могу и плюнуть и не помогать. Уже в этот раз было такое желание.
Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On Dec 8, 2014 4:49 PM, Anton Sayetsky wrote: > > По поводу "топ-квотинга": > https://groups.google.com/forum/#!msg/uafug/PnUizookwUo/MJz7sLmDbyMJ > Когда надо отвечать на конкретные строки - то вставляю ответ в нужное > место, конечно же. Только отвечать топ постингом на письмо, в котором _уже_ есть inline posting, это сознательно превращать письмо в нечитаемую кашу. Но дело Ваше, конечно - тут топ постинг не считается нарушением, а попытки объяснить людям почему так не стоит делать наталкиваются на такое вот невосприятее. Лично я уже просто игнорирую письма, которые мне неудобно читать: с кашей из inline & top posting, или HTML only. Так что просто имейте ввиду, что если Вам лень делать удобно для других, то другим может быть просто лень такое читать.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
Вообще задача следующая: Есть сервак, на внешнем интерфейсе которого поднят IPSec (cryptomap 172.31.249.0/24=>192.168.137.0/24). Есть несколько tun/tap, с которых приходят различные сети. (192.168.90.0/24, 172.17.5.0/24 и т.п.) Вот и нужно из всех tun/tap отнатить в 172.31.249.0/24, чтобы дальше трафик ушёл на 192.168.137.0/24 ipfw nat не работает, трафик натится правильно, но не заходит в SPD IPSec. Правила вида: ipfw nat 1 config ip 172.31.249.1 ipfw add nat 1 ip from any to any via tun1 Дают мне траф вида 172.31.249.1=>192.168.137.2 на re0, а должно паковаться в ESP. Сам IPSec работает отлично: root@vpnc:~# ping -c 3 -S 172.31.249.1 192.168.137.2 PING 192.168.137.2 (192.168.137.2) from 172.31.249.1: 56 data bytes 64 bytes from 192.168.137.2: icmp_seq=0 ttl=63 time=40.191 ms 64 bytes from 192.168.137.2: icmp_seq=1 ttl=63 time=32.563 ms 64 bytes from 192.168.137.2: icmp_seq=2 ttl=63 time=34.543 ms --- 192.168.137.2 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 32.563/35.766/40.191/3.232 ms root@vpnc:~# 8 декабря 2014 г., 17:56 пользователь Lystopad Aleksandr написал: > Hello, Anton Sayetsky! > >> >>> root@vpnc:~# cat /etc/natd.conf >> >>> # >> >>> >> >>> log >> >>> #deny_incoming >> >>> log_denied >> >>> same_ports >> >>> >> >>> instance default >> >>> port >> >>> interface lo1 >> >>> >> >>> ЧЯДНТ? > > А можно вопрос: почему user-nat ? Почему не ipfw nat ? > >> >> Мне нужно, дабы пакеты из сети 172.17.5.0/24 натились на адрес >> >> 172.31.249.1 и отправлялись дальше в сеть 192.168.137.0/24. Т.е. >> >> приходит из tun1, натится на один из адресов lo1, идёт дальше по >> >> таблице маршрутизации. >> > >> > Замени строку interface lo1 на строку alias_address 172.31.249.1 >> > > > -- > Lystopad Aleksandr
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
8 декабря 2014 г., 22:06 пользователь Mykola Dzham написал: > > On Dec 8, 2014 4:49 PM, Anton Sayetsky wrote: >> >> По поводу "топ-квотинга": >> https://groups.google.com/forum/#!msg/uafug/PnUizookwUo/MJz7sLmDbyMJ >> Когда надо отвечать на конкретные строки - то вставляю ответ в нужное >> место, конечно же. > > Только отвечать топ постингом на письмо, в котором _уже_ есть inline posting, > это сознательно превращать письмо в нечитаемую кашу. > Но дело Ваше, конечно - тут топ постинг не считается нарушением, а попытки > объяснить людям почему так не стоит делать наталкиваются на такое вот > невосприятее. > Лично я уже просто игнорирую письма, которые мне неудобно читать: с кашей из > inline & top posting, или HTML only. > Так что просто имейте ввиду, что если Вам лень делать удобно для других, то > другим может быть просто лень такое читать. Ребят я очень извиняюсь что влезаю ещё и оффтопом, но как в gmail не топквотить? он же по умолчанию засовывает предыдущее письмо вниз и настроить это нельзя. Получается только вручную, открывая цитату письма и перенося курсор вниз?
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On 08.12.2014 23:52, Eugene Grosbein wrote: > On Mon, Dec 08, 2014 at 05:49:12PM +0200, Anton Sayetsky wrote: > Т.е.приходит из tun1, натится на один из адресов lo1, идёт дальше по таблице маршрутизации. > > Без схемы было сложно понять, что транслировать трафик нужно на входе, > а не традиционно на выходе. В этом случае нужно использовать не один > divert-сокет , а два разных, указывая их через in_port и out_port > и заворачивая out_port трафик, приходящий через tun1 - для подмены src IP. > А в in_port заворачивать трафик, уходящий в tun1 - для трансляции > ответов. Поправка: в in_port нужно заворачивать трафик, приходящий через внешний интерфейс, иначе у него не будет шансов уйти по роутингу - дропнется как незапрошенный входящий локальный.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On Mon, Dec 08, 2014 at 06:03:36PM +0200, Anton Sayetsky wrote: > Вообще задача следующая: > Есть сервак, на внешнем интерфейсе которого поднят IPSec (cryptomap > 172.31.249.0/24=>192.168.137.0/24). > Есть несколько tun/tap, с которых приходят различные сети. > (192.168.90.0/24, 172.17.5.0/24 и т.п.) > Вот и нужно из всех tun/tap отнатить в 172.31.249.0/24, чтобы дальше > трафик ушёл на 192.168.137.0/24 > ipfw nat не работает, трафик натится правильно, но не заходит в SPD IPSec. > > Правила вида: > ipfw nat 1 config ip 172.31.249.1 > ipfw add nat 1 ip from any to any via tun1 > Дают мне траф вида 172.31.249.1=>192.168.137.2 на re0, а должно > паковаться в ESP. Неплохо бы о применении IPSEC в схеме упоминать в первом письме, а не к концу обсуждения. Потому как пакет на выходе из роутера сначала поступает на обработку в IPSEC, а только потом идёт через пакетные фильтры (ipfw) и выйдя из NAT, уже в IPSEC не направляется. И неважно, ipfw nat это, natd или pf.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On Mon, Dec 08, 2014 at 11:20:29PM +0300, Владимир Супраненок wrote: > 8 декабря 2014 г., 22:06 пользователь Mykola Dzham написал: > > > > On Dec 8, 2014 4:49 PM, Anton Sayetsky wrote: > >> > >> По поводу "топ-квотинга": > >> https://groups.google.com/forum/#!msg/uafug/PnUizookwUo/MJz7sLmDbyMJ > >> Когда надо отвечать на конкретные строки - то вставляю ответ в нужное > >> место, конечно же. > > > > Только отвечать топ постингом на письмо, в котором _уже_ есть inline > > posting, это сознательно превращать письмо в нечитаемую кашу. > > Но дело Ваше, конечно - тут топ постинг не считается нарушением, а попытки > > объяснить людям почему так не стоит делать наталкиваются на такое вот > > невосприятее. > > Лично я уже просто игнорирую письма, которые мне неудобно читать: с кашей > > из inline & top posting, или HTML only. > > Так что просто имейте ввиду, что если Вам лень делать удобно для других, то > > другим может быть просто лень такое читать. > > Ребят я очень извиняюсь что влезаю ещё и оффтопом, но как в gmail не > топквотить? он же по умолчанию засовывает предыдущее письмо вниз и > настроить это нельзя. Получается только вручную, открывая цитату > письма и перенося курсор вниз? не знаю про гмыло, но есть универсальное правило: усилия прикладывает тот, кому больше надо.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On Dec 8, 2014 9:20 PM, Владимир Супраненок wrote: > > 8 декабря 2014 г., 22:06 пользователь Mykola Dzham написал: > > > > On Dec 8, 2014 4:49 PM, Anton Sayetsky wrote: > >> > >> По поводу "топ-квотинга": > >> https://groups.google.com/forum/#!msg/uafug/PnUizookwUo/MJz7sLmDbyMJ > >> Когда надо отвечать на конкретные строки - то вставляю ответ в нужное > >> место, конечно же. > > > > Только отвечать топ постингом на письмо, в котором _уже_ есть inline > > posting, это сознательно превращать письмо в нечитаемую кашу. > > Но дело Ваше, конечно - тут топ постинг не считается нарушением, а попытки > > объяснить людям почему так не стоит делать наталкиваются на такое вот > > невосприятее. > > Лично я уже просто игнорирую письма, которые мне неудобно читать: с кашей > > из inline & top posting, или HTML only. > > Так что просто имейте ввиду, что если Вам лень делать удобно для других, то > > другим может быть просто лень такое читать. > > Ребят я очень извиняюсь что влезаю ещё и оффтопом, но как в gmail не > топквотить? он же по умолчанию засовывает предыдущее письмо вниз и > настроить это нельзя. Получается только вручную, открывая цитату > письма и перенося курсор вниз? Это так сложно, переместить курсор вниз? Я вот сейчас вообще отвечаю с мобилки с gmail app, и ничего, вполне можно отвечать inline. Да и предыдущее письмо так же писал.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On 08.12.2014 19:03, Anton Sayetsky wrote: > Вообще задача следующая: > Есть сервак, на внешнем интерфейсе которого поднят IPSec (cryptomap > 172.31.249.0/24=>192.168.137.0/24). > Есть несколько tun/tap, с которых приходят различные сети. > (192.168.90.0/24, 172.17.5.0/24 и т.п.) > Вот и нужно из всех tun/tap отнатить в 172.31.249.0/24, чтобы дальше > трафик ушёл на 192.168.137.0/24 > ipfw nat не работает, трафик натится правильно, но не заходит в SPD IPSec. > > Правила вида: > ipfw nat 1 config ip 172.31.249.1 > ipfw add nat 1 ip from any to any via tun1 > Дают мне траф вида 172.31.249.1=>192.168.137.2 на re0, а должно > паковаться в ESP. А что при этом говорит setkey -D и setkey -DP? > Сам IPSec работает отлично: > root@vpnc:~# ping -c 3 -S 172.31.249.1 192.168.137.2 > PING 192.168.137.2 (192.168.137.2) from 172.31.249.1: 56 data bytes > 64 bytes from 192.168.137.2: icmp_seq=0 ttl=63 time=40.191 ms > 64 bytes from 192.168.137.2: icmp_seq=1 ttl=63 time=32.563 ms > 64 bytes from 192.168.137.2: icmp_seq=2 ttl=63 time=34.543 ms -- WBR, Andrey V. Elsukov
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
8 декабря 2014 г., 18:43 пользователь Eugene Grosbein написал: > On Mon, Dec 08, 2014 at 06:03:36PM +0200, Anton Sayetsky wrote: >> Вообще задача следующая: >> Есть сервак, на внешнем интерфейсе которого поднят IPSec (cryptomap >> 172.31.249.0/24=>192.168.137.0/24). >> Есть несколько tun/tap, с которых приходят различные сети. >> (192.168.90.0/24, 172.17.5.0/24 и т.п.) >> Вот и нужно из всех tun/tap отнатить в 172.31.249.0/24, чтобы дальше >> трафик ушёл на 192.168.137.0/24 >> ipfw nat не работает, трафик натится правильно, но не заходит в SPD IPSec. >> >> Правила вида: >> ipfw nat 1 config ip 172.31.249.1 >> ipfw add nat 1 ip from any to any via tun1 >> Дают мне траф вида 172.31.249.1=>192.168.137.2 на re0, а должно >> паковаться в ESP. > > Неплохо бы о применении IPSEC в схеме упоминать в первом письме, > а не к концу обсуждения. Потому как пакет на выходе из роутера > сначала поступает на обработку в IPSEC, а только потом идёт > через пакетные фильтры (ipfw) и выйдя из NAT, уже в IPSEC > не направляется. И неважно, ipfw nat это, natd или pf. Т.е. ipfw nat работать не будет принципиально? ipsec.filtertunnel может помочь?
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On 09.12.2014 15:39, Anton Sayetsky wrote: > 8 декабря 2014 г., 18:43 пользователь Eugene Grosbein > написал: >> On Mon, Dec 08, 2014 at 06:03:36PM +0200, Anton Sayetsky wrote: >>> Вообще задача следующая: >>> Есть сервак, на внешнем интерфейсе которого поднят IPSec (cryptomap >>> 172.31.249.0/24=>192.168.137.0/24). >>> Есть несколько tun/tap, с которых приходят различные сети. >>> (192.168.90.0/24, 172.17.5.0/24 и т.п.) >>> Вот и нужно из всех tun/tap отнатить в 172.31.249.0/24, чтобы дальше >>> трафик ушёл на 192.168.137.0/24 >>> ipfw nat не работает, трафик натится правильно, но не заходит в SPD IPSec. >>> >>> Правила вида: >>> ipfw nat 1 config ip 172.31.249.1 >>> ipfw add nat 1 ip from any to any via tun1 >>> Дают мне траф вида 172.31.249.1=>192.168.137.2 на re0, а должно >>> паковаться в ESP. >> >> Неплохо бы о применении IPSEC в схеме упоминать в первом письме, >> а не к концу обсуждения. Потому как пакет на выходе из роутера >> сначала поступает на обработку в IPSEC, а только потом идёт >> через пакетные фильтры (ipfw) и выйдя из NAT, уже в IPSEC >> не направляется. И неважно, ipfw nat это, natd или pf. > Т.е. ipfw nat работать не будет принципиально? ipsec.filtertunnel может > помочь? filtertunnel может помочь в трансляции входящих пакетов, но его недостаточно для трансляции исходящих. Сделал патч на ядерную часть ipfw nat для того, чтобы он поддерживал эту функциональность, что была в natd: позволяет явно задавать направление трансляции пакетов (in->out или out->in). Сейчас ipfw nat определяет это направление только автоматически: если пакет проходит по списку правил ipfw первый раз, на входе в маршрутизатор, он считается входящим и транслируется только как out->in. Если пакет проходит по правилам ipfw повторно и после выполнения routing lookup (на выходе и уже имеет атрибут xmit interface), то он транслирцется только как in->out. Патч http://www.grosbein.net/freebsd/patches/ip_fw_nat.c.diff не меняет это поведение по умолчанию: патченная система работает так же. Однако, патч вводит два новых sysctl с дефолтными нулевыми значениям: net.inet.ip.fw.nat_tag_in net.inet.ip.fw.nat_tag_out Если пакет, попавший в правило ipfw nat, имеет прикрепленный тег с номером, равным ненулевому значению sysctl net.inet.ip.fw.nat_tag_out, он безусловно транслируется по схеме in->out, даже если обрабатывается на входе в маршрутизатор. Аналогично, если пакет имеет тег, равный ненулевому net.inet.ip.fw.nat_tag_in, он транслируется как входящий снаружи по схеме out->in. Трансляция для пакетов, не имеющих таких тегов, выполняется как на непатченной системе. Для пакетов, имеющих теги, эти теги при трансляции снимаются. Теперь для решения исходной задачи можно задать sysctl net.inet.ip.fw.nat_tag_out=10 и заменить одно правило ipfw add nat 1 ip from any to any via tun1 на три: tag_out=$(sysctl -n net.inet.ip.fw.nat_tag_out) # Трансляция трафика из мира в локалку ipfw add 1000 nat 1 ip from any to any in recv $ext_if # Тегирование пакетов для трансляции из локалки в мир ipfw add 1010 count tag $tag_out ip from $LAN to not $LAN in recv 'ng*' # Трансляция тегированных пакетов на ВХОДЕ в маршрутизатор ipfw add 1020 nat 1 ip from any to any tagged $tag_out in Таким образом добиваемся необходимого эффекта: сначала трансляция исходящего трафика, затем обработка IPSEC на выходе (между ними routing lookup). Не забываем, что при sysctl net.inet.ip.fw.one_pass=1 оттранслированные на входе пакеты не идут дальше по правилам ipfw. Прикладывать патч: cd /usr/src && patch < /path/to/patch Затем пересобрать ядро либо только модуль ipfw_nat.ko (модуль ipfw.ko не требуется пересобирать), если используется модуль, а не кастомное ядро с FIREWALL_NAT. Модуль можно выгрузить/загрузить на лету, только после этого обязательно сделать service ipfw start, иначе трансляция не заработает. Патч сделан и проверен на 9.3. Вариант для 8.4: http://www.grosbein.net/freebsd/patches/ip_fw_nat.c.8.diff Для других версий, возможно, потребуется незначительная правка.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
9 декабря 2014 г., 22:20 пользователь Eugene Grosbein написал: > On 09.12.2014 15:39, Anton Sayetsky wrote: >> 8 декабря 2014 г., 18:43 пользователь Eugene Grosbein >> написал: >>> On Mon, Dec 08, 2014 at 06:03:36PM +0200, Anton Sayetsky wrote: Вообще задача следующая: Есть сервак, на внешнем интерфейсе которого поднят IPSec (cryptomap 172.31.249.0/24=>192.168.137.0/24). Есть несколько tun/tap, с которых приходят различные сети. (192.168.90.0/24, 172.17.5.0/24 и т.п.) Вот и нужно из всех tun/tap отнатить в 172.31.249.0/24, чтобы дальше трафик ушёл на 192.168.137.0/24 ipfw nat не работает, трафик натится правильно, но не заходит в SPD IPSec. Правила вида: ipfw nat 1 config ip 172.31.249.1 ipfw add nat 1 ip from any to any via tun1 Дают мне траф вида 172.31.249.1=>192.168.137.2 на re0, а должно паковаться в ESP. >>> >>> Неплохо бы о применении IPSEC в схеме упоминать в первом письме, >>> а не к концу обсуждения. Потому как пакет на выходе из роутера >>> сначала поступает на обработку в IPSEC, а только потом идёт >>> через пакетные фильтры (ipfw) и выйдя из NAT, уже в IPSEC >>> не направляется. И неважно, ipfw nat это, natd или pf. >> Т.е. ipfw nat работать не будет принципиально? ipsec.filtertunnel может >> помочь? > > filtertunnel может помочь в трансляции входящих пакетов, но его недостаточно > для трансляции исходящих. После долгих извращений я сегодня к этому выводу и пришёл... > Сделал патч на ядерную часть ipfw nat для того, чтобы он поддерживал > эту функциональность, что была в natd: позволяет явно задавать направление > трансляции пакетов (in->out или out->in). > > Сейчас ipfw nat определяет это направление только автоматически: если пакет > проходит по списку правил ipfw первый раз, на входе в маршрутизатор, > он считается входящим и транслируется только как out->in. Если пакет проходит > по правилам ipfw повторно и после выполнения routing lookup (на выходе > и уже имеет атрибут xmit interface), то он транслирцется только как in->out. > > Патч http://www.grosbein.net/freebsd/patches/ip_fw_nat.c.diff > не меняет это поведение по умолчанию: патченная система работает так же. > Однако, патч вводит два новых sysctl с дефолтными нулевыми значениям: > net.inet.ip.fw.nat_tag_in > net.inet.ip.fw.nat_tag_out > > Если пакет, попавший в правило ipfw nat, имеет прикрепленный тег с номером, > равным ненулевому значению sysctl net.inet.ip.fw.nat_tag_out, он безусловно > транслируется > по схеме in->out, даже если обрабатывается на входе в маршрутизатор. > > Аналогично, если пакет имеет тег, равный ненулевому net.inet.ip.fw.nat_tag_in, > он транслируется как входящий снаружи по схеме out->in. > > Трансляция для пакетов, не имеющих таких тегов, выполняется как на непатченной > системе. Для пакетов, имеющих теги, эти теги при трансляции снимаются. > > Теперь для решения исходной задачи можно задать sysctl > net.inet.ip.fw.nat_tag_out=10 > и заменить одно правило ipfw add nat 1 ip from any to any via tun1 на три: > > tag_out=$(sysctl -n net.inet.ip.fw.nat_tag_out) > # Трансляция трафика из мира в локалку > ipfw add 1000 nat 1 ip from any to any in recv $ext_if > # Тегирование пакетов для трансляции из локалки в мир > ipfw add 1010 count tag $tag_out ip from $LAN to not $LAN in recv 'ng*' > # Трансляция тегированных пакетов на ВХОДЕ в маршрутизатор > ipfw add 1020 nat 1 ip from any to any tagged $tag_out in > > Таким образом добиваемся необходимого эффекта: сначала трансляция исходящего > трафика, затем обработка IPSEC на выходе (между ними routing lookup). > > Не забываем, что при sysctl net.inet.ip.fw.one_pass=1 оттранслированные > на входе пакеты не идут дальше по правилам ipfw. > > Прикладывать патч: > > cd /usr/src && patch < /path/to/patch > > Затем пересобрать ядро либо только модуль ipfw_nat.ko (модуль ipfw.ko не > требуется пересобирать), > если используется модуль, а не кастомное ядро с FIREWALL_NAT. Модуль можно > выгрузить/загрузить > на лету, только после этого обязательно сделать service ipfw start, иначе > трансляция не заработает. > > Патч сделан и проверен на 9.3. Вариант для 8.4: > http://www.grosbein.net/freebsd/patches/ip_fw_nat.c.8.diff > Для других версий, возможно, потребуется незначительная правка. У меня сейчас 10.1. Пожалуй, где-нибудь рядом подниму ещё одну машину, тестовую, да попробую накатить. Пока сделал так: root@vpnc:~# cat /etc/natd.conf # log deny_incoming log_denied unregistered_only instance default alias_address 172.31.249.1 in_port 7020 out_port 7021 root@vpnc:~# ipfw -d show | grep divert 00260 194446 3036896712 divert 7021 ip from 172.17.5.0/24 to 192.168.137.0/24 in via tun1 00270 194284 3036900457 divert 7020 ip from 192.168.137.0/24 to 172.31.249.1 in via re0 root@vpnc:~# sysctl net.inet.ipsec.filtertunnel net.inet.ipsec.filtertunnel: 1 root@vpnc:~# ifconfig lo1 lo1: flags=8049 metric 0 mtu 16384 options=63 inet 172.31.249.1 netmask 0xff00 nd6 options=29
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On 10.12.2014 03:20, Eugene Grosbein wrote: > Не забываем, что при sysctl net.inet.ip.fw.one_pass=1 оттранслированные > на входе пакеты не идут дальше по правилам ipfw. Уточнение: не идут дальше по правилам ipfw на этом проходе. На втором проходе пойдут, конечно.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On 10.12.2014 04:14, Anton Sayetsky wrote: > Причём natd жрёт меньше проца, чем openvpn, netisr и irq taskq (при > тупом тесте: ping -f -s 16384, да и с другими размерами пакетов тоже). Непосредственно процесс natd начинает жрать CPU только если создаётся очень много потоков трафика. Но основная проблема с natd не в этом, а в том, что даже на одном потоке, но при большом трафике (pps) на каждый пакет получается до шести (afair) переключений контекста - огромные накладные расходы для ядра и шедулера. Они на natd не записываются, они на system time идут.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
10 декабря 2014 г., 6:39 пользователь Eugene Grosbein написал: > On 10.12.2014 04:14, Anton Sayetsky wrote: > >> Причём natd жрёт меньше проца, чем openvpn, netisr и irq taskq (при >> тупом тесте: ping -f -s 16384, да и с другими размерами пакетов тоже). > > Непосредственно процесс natd начинает жрать CPU только если создаётся > очень много потоков трафика. Но основная проблема с natd не в этом, > а в том, что даже на одном потоке, но при большом трафике (pps) > на каждый пакет получается до шести (afair) переключений контекста - > огромные накладные расходы для ядра и шедулера. Они на natd не записываются, > они на system time идут. Случаем не в тот самый netisr?
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
On 10.12.2014 14:19, Anton Sayetsky wrote: >>> Причём natd жрёт меньше проца, чем openvpn, netisr и irq taskq (при >>> тупом тесте: ping -f -s 16384, да и с другими размерами пакетов тоже). >> >> Непосредственно процесс natd начинает жрать CPU только если создаётся >> очень много потоков трафика. Но основная проблема с natd не в этом, >> а в том, что даже на одном потоке, но при большом трафике (pps) >> на каждый пакет получается до шести (afair) переключений контекста - >> огромные накладные расходы для ядра и шедулера. Они на natd не записываются, >> они на system time идут. > > Случаем не в тот самый netisr? Нет, netisr это другое.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] natd не натит
10 декабря 2014 г., 9:21 пользователь Eugene Grosbein написал: > On 10.12.2014 14:19, Anton Sayetsky wrote: > Причём natd жрёт меньше проца, чем openvpn, netisr и irq taskq (при тупом тесте: ping -f -s 16384, да и с другими размерами пакетов тоже). >>> >>> Непосредственно процесс natd начинает жрать CPU только если создаётся >>> очень много потоков трафика. Но основная проблема с natd не в этом, >>> а в том, что даже на одном потоке, но при большом трафике (pps) >>> на каждый пакет получается до шести (afair) переключений контекста - >>> огромные накладные расходы для ядра и шедулера. Они на natd не записываются, >>> они на system time идут. >> >> Случаем не в тот самый netisr? > > Нет, netisr это другое. Ладно, пока будем посмотреть. Ну а как будет свободное время - буду пробовать патч.
