[freebsd] Есть ли особенности проброса порта в туннель?
Nick Kostirya via freebsd
У меня вопрос: есть ли особенности проброса порта в туннель?
У сервера X (12.3-RELEASE-p5)
${fwcmd} nat 1 config if vmx0 redirect_port tcp 192.168.12.111:80 8080
${fwcmd} add nat 1 ip from any to any 8080
(упростил уже до такого)
Делаю для проверки
echo hello | nc X.X.X.X 8080
На сервере Y с IP 192.168.12.111 в туннеле (13.1-RELEASE)
Вижу только входящий пакет и все.
# tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
06:07:03.106586 IP X.X.X.X.62673 > 192.168.12.111.80: Flags [S], seq 1358968744, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3568935363 ecr 0], length 0
Когда на сервере X делаю запрос напрямую по туннелю без redirect_port
echo hello | nc 192.168.12.111 80
То на сервере Y вижу сразу и ответ
# tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
06:28:41.232011 IP 192.168.12.1.49774 > 192.168.12.111.80: Flags [S], seq 1477405936, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 878248554 ecr 0], length 0
06:28:41.232045 IP 192.168.12.111.80 > 192.168.12.1.49774: Flags [S.], seq 3253001398, ack 1477405937, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 2263718684 ecr 878248554], length 0
Может что-то есть такое, что я не знаю?
И там и там net.inet.ip.forwarding=1
_______________________________________________
freebsd mailing list
fre...@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Eugene Grosbein
> Привет.
>
> У меня вопрос: есть ли особенности проброса порта в туннель?
Только размер пакета: часто на туннеле меньше MTU и если у пакета выставлен DF-бит
и пакет больше next-hop MTU, он не пролезет. Ещё FreeBSD пока не умеет роутить
комбинированные LRO пакеты в IPSec, если суммарный размер "чанка" больше MTU IPSec-туннеля,
но это не твой случай. Если же всё пролазит, то проблем не должно быть
при условии следования документации.
> У сервера X (12.3-RELEASE-p5)
>
> ${fwcmd} nat 1 config if vmx0 redirect_port tcp 192.168.12.111:80 8080
> ${fwcmd} add nat 1 ip from any to any 8080
> (упростил уже до такого)
>
> Делаю для проверки
> echo hello | nc X.X.X.X 8080
>
> На сервере Y с IP 192.168.12.111 в туннеле (13.1-RELEASE)
> Вижу только входящий пакет и все.
> # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
> 06:07:03.106586 IP X.X.X.X.62673 > 192.168.12.111.80: Flags [S], seq 1358968744, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3568935363 ecr 0], length 0
Ты увидел успешно расшированный пакет на приёмной стороне,
а это значит, что к серверу X вопросов никаких быть не может,
он всё правильно отфорвардил и даже не налажал с шифрованием.
> Когда на сервере X делаю запрос напрямую по туннелю без redirect_port
>
> echo hello | nc 192.168.12.111 80
>
> То на сервере Y вижу сразу и ответ
>
> # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
> 06:28:41.232011 IP 192.168.12.1.49774 > 192.168.12.111.80: Flags [S], seq 1477405936, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 878248554 ecr 0], length 0
> 06:28:41.232045 IP 192.168.12.111.80 > 192.168.12.1.49774: Flags [S.], seq 3253001398, ack 1477405937, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 2263718684 ecr 878248554], length 0
>
> Может что-то есть такое, что я не знаю?
>
> И там и там net.inet.ip.forwarding=1
Разница в том, что в первом случае адрес источника был X.X.X.X, а во втором 192.168.12.1.
Либо входящий пакет был убит файрволом на приёмной стороне, либо ответ не находит роута в туннель
и уходит в другой интерфейс или вообще никуда.
Nick Kostirya via freebsd
Eugene Grosbein <eu...@grosbein.net> wrote:
> > На сервере Y с IP 192.168.12.111 в туннеле (13.1-RELEASE)
> > Вижу только входящий пакет и все.
> > # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
> > 06:07:03.106586 IP X.X.X.X.62673 > 192.168.12.111.80: Flags [S], seq 1358968744, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3568935363 ecr 0], length 0
>
>
> Разница в том, что в первом случае адрес источника был X.X.X.X, а во втором 192.168.12.1.
> Либо входящий пакет был убит файрволом на приёмной стороне, либо ответ не находит роута в туннель
> и уходит в другой интерфейс или вообще никуда.
В ipfw разрешено для tcp все.
Таблица роутинга вот такая:
Destination Gateway Flags Netif Expire
default X.X.X.X UGS rl0
127.0.0.1 link#2 UH lo0
192.168.0.0/24 link#1 U rl0
192.168.0.111 link#1 UHS lo0
192.168.12.1 link#5 UH ipsec0
192.168.12.111 link#5 UHS lo0
Получается ответы, на запроси от X.X.X.X, хоть и пришли через тунель, уходят на X.X.X.X, а не в тунель 192.168.12.1.
Но их почему-то не видно tcpdump -i rl0 'port 8080 or port 80'.
Пробовал добавить.
ipfw add 200 fwd 192.168.12.1 tcp from 192.168.12.111 80 to any
не помогло.
А почему на сервере Y в tcpdump видны запросы
12:50:08.219710 IP X.X.X.X.41173 > 192.168.12.111.http: Flags [S], seq 3645315935, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 1553419922 ecr 0], length 0
Но в ipfw нет?
# ipfw show
00100 0 0 deny icmp from any to any in icmptypes 5
00101 0 0 count ip from any to any 80
00102 0 0 count ip from any to any 8080
00103 0 0 count ip from any to any 80 via rl0
00104 0 0 count ip from any to any 8080 via rl0
00105 0 0 count ip from any to any 80 via ipsec0
00106 0 0 count ip from any to any 8080 via ipsec0
65000 4547 905487 allow ip from any to any
И что означает ip в nat config ?
Описание "Define an ip address to use for aliasing." на понятно.
Пробовал использовать его, в надежде, что вместо пакета
IP X.X.X.X.41173 > 192.168.12.111.http
прийдет
IP 192.168.12.1.41173 > 192.168.12.111.http
и соответственно ответ уйдет в туннель на 192.168.12.1, но не сработало.
Valentin Nechayev
Fri, Jun 24, 2022 at 14:30:01, eugen wrote about "Re: [freebsd] Есть ли особенности проброса порта в туннель?":
> Только размер пакета: часто на туннеле меньше MTU и если у пакета выставлен DF-бит
> и пакет больше next-hop MTU, он не пролезет.
А needfrag оно вернёт назад в этом случае?
-netch-
Eugene Grosbein
> hi,
>
> Fri, Jun 24, 2022 at 14:30:01, eugen wrote about "Re: [freebsd] Есть ли особенности проброса порта в туннель?":
>
>> Только размер пакета: часто на туннеле меньше MTU и если у пакета выставлен DF-бит
>> и пакет больше next-hop MTU, он не пролезет.
>
> А needfrag оно вернёт назад в этом случае?
Вернет.
Eugene Grosbein
> On Fri, 24 Jun 2022 14:30:01 +0700
> Eugene Grosbein <eu...@grosbein.net> wrote:
>
>>> На сервере Y с IP 192.168.12.111 в туннеле (13.1-RELEASE)
>>> Вижу только входящий пакет и все.
>>> # tcpdump -n -i ipsec0 -a 'port 8080 or port 80'
>>> 06:07:03.106586 IP X.X.X.X.62673 > 192.168.12.111.80: Flags [S], seq 1358968744, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3568935363 ecr 0], length 0
>>
>> Разница в том, что в первом случае адрес источника был X.X.X.X, а во втором 192.168.12.1.
>> Либо входящий пакет был убит файрволом на приёмной стороне, либо ответ не находит роута в туннель
>> и уходит в другой интерфейс или вообще никуда.
>
> В ipfw разрешено для tcp все.
>
> Таблица роутинга вот такая:
>
> Destination Gateway Flags Netif Expire
> default X.X.X.X UGS rl0
> 127.0.0.1 link#2 UH lo0
> 192.168.0.0/24 link#1 U rl0
> 192.168.0.111 link#1 UHS lo0
> 192.168.12.1 link#5 UH ipsec0
> 192.168.12.111 link#5 UHS lo0
>
>
> Получается ответы, на запроси от X.X.X.X, хоть и пришли через тунель, уходят на X.X.X.X, а не в тунель 192.168.12.1.
>
> Но их почему-то не видно tcpdump -i rl0 'port 8080 or port 80'.
Тогда они не уходят в этот интерфейс. Вероятно, они не уходят никуда, потому что убиваются
уже после расшифровки в ядре.
> А почему на сервере Y в tcpdump видны запросы
>
> 12:50:08.219710 IP X.X.X.X.41173 > 192.168.12.111.http: Flags [S], seq 3645315935, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 1553419922 ecr 0], length 0
>
> Но в ipfw нет?
Вероятно, до прохода по ipfw после расшифровки пакеты не доходят.
Нужен вывод netstat -sp ipsec и netstat -sp esp
> И что означает ip в nat config ?
> Описание "Define an ip address to use for aliasing." на понятно.
Вместо if можно использовать ip.
Если использовать if, то ipfw nat берет с указанного интерфейса два параметра:
IP в качестве aliasing address (то есть, "внешнего) и MTU для PMTUD,
для отправки ICMP need-frag при необходимости.
Если же вместо if указать ip, то он будет его использовать, но ICMP need-frag отправлять не будет.
Что касается исходной проблемы: пора в деталях описывать, каким образом устанавливается IPSec-туннель:
используется ли IKE-агент? Используется ли NAT-T? Что в выводе упомянутых выше команд
netstat -sp ipsec и netstat -sp esp и какие счетчики растут, когда проблема воспроизводится повторно?
Nick Kostirya via freebsd
Eugene Grosbein <eu...@grosbein.net> wrote:
> > А почему на сервере Y в tcpdump видны запросы
> >
> > 12:50:08.219710 IP X.X.X.X.41173 > 192.168.12.111.http: Flags [S], seq 3645315935, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 1553419922 ecr 0], length 0
> >
> > Но в ipfw нет?
>
> Вероятно, до прохода по ipfw после расшифровки пакеты не доходят.
То есть, не все пакеты проходят ipfw. Спасибо за информацию.
> Нужен вывод netstat -sp ipsec и netstat -sp esp
>
> > И что означает ip в nat config ?
> > Описание "Define an ip address to use for aliasing." на понятно.
>
> Вместо if можно использовать ip.
> Если использовать if, то ipfw nat берет с указанного интерфейса два параметра:
> IP в качестве aliasing address (то есть, "внешнего) и MTU для PMTUD,
> для отправки ICMP need-frag при необходимости.
Спасибо.
>
> Если же вместо if указать ip, то он будет его использовать, но ICMP need-frag отправлять не будет.
>
> Что касается исходной проблемы: пора в деталях описывать, каким образом устанавливается IPSec-туннель:
> используется ли IKE-агент? Используется ли NAT-T? Что в выводе упомянутых выше команд
> netstat -sp ipsec и netstat -sp esp и какие счетчики растут, когда проблема воспроизводится повторно?
Это не зависит от туннеля. Пробовал l2tp (чистый, без ipsec), ipsec (ручное создание, без IKE), openvpn и, кажется, gif.
Для UDP заработало.
На внешнем сервере.
${fwcmd} nat 1 config if vmx0 same_ports reset redirect_port udp 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
${fwcmd} add nat 1 ip from any to me 8080 in via vmx0
${fwcmd} add nat 1 ip from any 8080 to any
(192.168.10.111 - адресс другой сторону туннеля, 192.168.10.1 - это сторона туннеля)
На внутреннем нужно было добавить.
${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
Так как ответы уходили от 192.168.1.111 через rl0 (ip на внешнем интерфейсе)
А вот ответы по TCP уходят от 192.168.10.111 через rl0 (ip туннеля)
Но правило
${fwcmd} add fwd 192.168.10.1 all from 192.168.10.111 8080 to any out via rl0
хоть и улавливает пакет, не хочет перенаправлять пакет в туннель (наверное из-за того, что пакет уже имеет в качестве отправителя адрес туннеля).
Поэтому возник вопрос почему у UDP и TCP разные отправители и как все таки завернуть TCP назад в туннель.