Re: [freebsd] TCP vs UDP в контексте туннеля.
On Tue, 28 Jun 2022 03:03:35 +0700
Eugene Grosbein wrote:
> On 27.06.2022 10:11, Nick Kostirya via freebsd wrote:
> > On Mon, 27 Jun 2022 01:36:39 +0700
> > Eugene Grosbein wrote:
> >
> >> 25.06.2022 13:47, Nick Kostirya via freebsd пишет:
> >>> Привет.
> >>>
> >>> В туннель заворачивается на сервере X (192.168.10.1) вот так
> >>>
> >>> ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp
> >>> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
> >>>
> >>>
> >>> На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на
> >>> 192.168.10.111, но вот ответы...
> >>>
> >>> UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
> >>> а
> >>> TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему
> >>> интерфейсу rl0
> >>>
> >>>
> >>> Почему так?
> >>>
> >>>
> >>> Для UDP заворачиваю в туннель вот так
> >>> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
> >>>
> >>> И все работает. Сервер видит ответ X и пересылает дальше.
> >>>
> >>> А вот с TCP forward не работает.
> >>
> >> Нужен полный вывод ipfw show без каких-либо редактирований, разве что
> >> можешь заменить публичные адреса.
> >
> > На W.W.W.W делаю запрос, который X.X.X.X перенаправляет в тeннель
> > 192.168.10.1 -> 192.168.10.111
> > # echo hello | nc -w 1 X.X.X.X 8080
> >
> >
> >
> > Ответ на дальнем конце туннеля (192.168.10.111), где стоит TCP сервер
> >
> >
> > # tcpdump -A -i rl0 'port 8080'
>
> Я просил вывод ipfw show, а не tcpdump.
Прошу прошение.
UDP
Начало туннеля.
# ipfw show
001001 34 nat 1 ip from any to me 8080 in via vmx0
002002 62 nat 1 ip from any 8080 to any
65000 563352 allow ip from any to any
65535 8928 1279978 deny ip from any to any
${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
Сервер в конце туннеля
# ipfw show
00100 0 0 fwd 192.168.10.1 ip from 192.168.10.111 8080 to any via rl0
00200 131 fwd 192.168.10.1 ip from me 8080 to any out via rl0
65000 120 11064 allow ip from any to any
65535 122 10052 allow ip from any to any
${fwcmd} add fwd 192.168.10.1 all from 192.168.10.111 8080 to any via rl0
${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
TCP
Начало туннеля.
# ipfw show
001001 60 nat 1 ip from any to me 8080 in via vmx0
002000 0 nat 1 ip from any 8080 to any
65000 1047636 allow ip from any to any
65535 8928 1279978 deny ip from any to any
Сервер в конце туннеля
# ipfw show
00100 4 240 fwd 192.168.10.1 ip from 192.168.10.111 8080 to any via rl0
00200 0 0 fwd 192.168.10.1 ip from me 8080 to any out via rl0
65000 63 4599 allow ip from any to any
65535 122 10052 allow ip from any to any
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] TCP vs UDP в контексте туннеля.
On Mon, 27 Jun 2022 01:36:39 +0700
Eugene Grosbein wrote:
> 25.06.2022 13:47, Nick Kostirya via freebsd пишет:
> > Привет.
> >
> > В туннель заворачивается на сервере X (192.168.10.1) вот так
> >
> > ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp
> > 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
> >
> >
> > На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на
> > 192.168.10.111, но вот ответы...
> >
> > UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
> > а
> > TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему
> > интерфейсу rl0
> >
> >
> > Почему так?
> >
> >
> > Для UDP заворачиваю в туннель вот так
> > ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
> >
> > И все работает. Сервер видит ответ X и пересылает дальше.
> >
> > А вот с TCP forward не работает.
>
> Нужен полный вывод ipfw show без каких-либо редактирований, разве что можешь
> заменить публичные адреса.
На W.W.W.W делаю запрос, который X.X.X.X перенаправляет в тeннель 192.168.10.1
-> 192.168.10.111
# echo hello | nc -w 1 X.X.X.X 8080
Ответ на дальнем конце туннеля (192.168.10.111), где стоит TCP сервер
# tcpdump -A -i rl0 'port 8080'
06:03:48.740345 IP 192.168.10.111.http-alt > W.W.W.W.35922: Flags [S.], seq
1829934935, ack 3960482503, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS
val 3660567064 ecr 2622412667], length 0
E..<..@.@..c..
oak.Rm..W..*..`.
./...N.{
06:03:49.740412 IP 192.168.10.111.http-alt > W.W.W.W.35922: Flags [S.], seq
1829934935, ack 3960482503, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS
val 3660568064 ecr 2622412667], length 0
E..<..@.@..c..
oak.Rm..W..*..x.
./...N.{
06:03:51.976288 IP 192.168.10.111.http-alt > W.W.W.W.35922: Flags [S.], seq
1829934935, ack 3960482503, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS
val 3660570300 ecr 2622412667], length 0
E..<..@.@..c..
oak.Rm..W..*
./...N.{
06:03:56.266309 IP 192.168.10.111.http-alt > W.W.W.W.35922: Flags [S.], seq
1829934935, ack 3960482503, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS
val 3660574590 ecr 2622412667], length 0
E..<..@.@..c..
oak.Rm..W..*
./.~.N.{
Выше - это ответ на вот это запрос, который пришел по ng0 тунелю:
# tcpdump -A -i ng0 'port 8080'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes
06:06:39.524166 IP W.W.W.W.35924 > 192.168.10.111.http-alt: Flags [S], seq
1945733787, win 64240, options [mss 1178,sackOK,TS val 2622583445 ecr
0,nop,wscale 7], length 0
E..<..@.3...ak
o.T..so.
.Qr.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] Есть ли особенности проброса порта в туннель?
On Mon, 27 Jun 2022 01:35:12 +0700
Eugene Grosbein 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 назад в туннель.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] TCP vs UDP в контексте туннеля.
On Sat, 25 Jun 2022 09:47:00 +0300
Nick Kostirya via freebsd wrote:
> Привет.
>
> В туннель заворачивается на сервере X (192.168.10.1) вот так
>
> ${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp
> 192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
>
>
> На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на
> 192.168.10.111, но вот ответы...
>
> UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
> а
> TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему
> интерфейсу rl0
>
>
> Почему так?
Проверил на NetBSD - аналогично. Но почему так?
>
>
> Для UDP заворачиваю в туннель вот так
> ${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
>
> И все работает. Сервер видит ответ X и пересылает дальше.
>
> А вот с TCP forward не работает.
А это еще не пробовал. Нужно читать про npf...
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
[freebsd] TCP vs UDP в контексте туннеля.
Привет.
В туннель заворачивается на сервере X (192.168.10.1) вот так
${fwcmd} nat 2 config if vmx0 same_ports reset redirect_port udp
192.168.10.111:8080 8080 redirect_port tcp 192.168.10.111:8080 8080
На сервере Y (192.168.10.111) запросы tcpdump показывает приходят на
192.168.10.111, но вот ответы...
UDP ответ идет с 192.168.0.111 (вне туннеля) по внешнему интерфейсу rl0
а
TCP ответ идет с 192.168.10.111 (адрес туннеля), но тоже по внешнему интерфейсу
rl0
Почему так?
Для UDP заворачиваю в туннель вот так
${fwcmd} add fwd 192.168.10.1 all from me 8080 to any out via rl0
И все работает. Сервер видит ответ X и пересылает дальше.
А вот с TCP forward не работает.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] Есть ли особенности проброса порта в туннель?
On Fri, 24 Jun 2022 14:30:01 +0700 Eugene Grosbein 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 все. Таблица роутинга вот такая: DestinationGatewayFlags Netif Expire defaultX.X.X.XUGS 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 001000 0 deny icmp from any to any in icmptypes 5 001010 0 count ip from any to any 80 001020 0 count ip from any to any 8080 001030 0 count ip from any to any 80 via rl0 001040 0 count ip from any to any 8080 via rl0 001050 0 count ip from any to any 80 via ipsec0 001060 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, но не сработало. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
[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
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] Туннель с клиентом за натом
On Wed, 22 Jun 2022 16:12:51 +0700 Eugene Grosbein wrote: > Первый подозреваемый - роутер Tenda. Проверить это легко, нужно повторить > тест с пингом > и tcpdump смотреть параллельно как на gif, так и на физическом интерфейсе, > чтобы видеть, > а сколько реально пакетов приходит со стороны Tenda? Нашел. Это не в туннеле дело. :-) И без туннеля дубликаты. Пропинговал все IP, что показал traceroute, и увидел, что дубликаты делает один из маршрутизаторов на пути от клиента к серверу. Спасибо. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] Туннель с клиентом за натом
On Wed, 22 Jun 2022 10:38:36 +0700 Eugene Grosbein wrote: > 22.06.2022 9:34, Nick Kostirya via freebsd пишет: > > Привет. > > > > Вопрос про туннель с клиентом за натом. > > > > > > Сервер: X.X.X.X 192.168.12.1 (FreeBSD 12.3) > > NAT:Y.Y.Y.Y 192.168.0.1 > > Слиент: 192.168.0.5 192.168.12.5 (FreeBSD 12.3) > > > > > > На сервере (X.X.X.X): > > > > ifconfig gif0 create > > ifconfig gif0 inet tunnel X.X.X.X Y.Y.Y.Y > > ifconfig gif0 inet 192.168.12.1/24 192.168.12.5 > > > > > > На клиенте (192.168.0.5): > > > > ifconfig gif0 create > > ifconfig gif0 inet tunnel 192.168.0.5 X.X.X.X > > ifconfig gif0 inet 192.168.12.5/24 192.168.12.1 > > > > > > TCP - работает, а вот UDP и ICMP дают дубликати. > > > > При этом tcpdump показывает, что UDP уже на gif0 интерфейсе сервера, а ICMP > > echo дает дубликати ответа, видные tcpdump на клиенте, если пинговать с > > клиента и наоборот. > > > > Аналогичная картина наблюдается для ipsec. > > > > Как это объяснить и исправить? > > > > Спасибо. > > не надо художественно излагать показания tcpdump. Их надо показывать. > И ещё очень важно, что за роутер делает NAT. Потому что не любой NAT отроутит > инкапсуляцию gif/IPIP, > а если она дополнительно обёрнута ещё во что-то типа UDP (как это делает > IPSec NAT-T), > то это надо тоже явным образом описывать. > > Потому что как сейчас описано - ничо не понятно. UDP На клиенте # echo hello | nc -u 192.168.12.1 # tcpdump -i gif0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes 08:42:41.200475 IP 192.168.12.5.14623 > 192.168.12.1.: UDP, length 6 На сервере получаю # nc -u -l hello hello # tcpdump -i gif0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes 07:42:40.938382 IP 192.168.12.5.14623 > 192.168.12.1.: UDP, length 6 07:42:40.939678 IP 192.168.12.5.14623 > 192.168.12.1.: UDP, length 6 --- Ping На клиенте. # ping -c 3 192.168.12.1 PING 192.168.12.1 (192.168.12.1): 56 data bytes 64 bytes from 192.168.12.1: icmp_seq=0 ttl=64 time=112.012 ms 64 bytes from 192.168.12.1: icmp_seq=0 ttl=64 time=113.694 ms (DUP!) 64 bytes from 192.168.12.1: icmp_seq=1 ttl=64 time=112.483 ms 64 bytes from 192.168.12.1: icmp_seq=1 ttl=64 time=113.131 ms (DUP!) 64 bytes from 192.168.12.1: icmp_seq=2 ttl=64 time=114.567 ms --- 192.168.12.1 ping statistics --- 3 packets transmitted, 3 packets received, +2 duplicates, 0.0% packet loss round-trip min/avg/max/stddev = 112.012/113.177/114.567/0.899 ms # tcpdump -i gif0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes 08:22:30.774131 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 0, length 64 08:22:30.886033 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 0, length 64 08:22:30.887670 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 0, length 64 08:22:31.798535 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 1, length 64 08:22:31.910871 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 1, length 64 08:22:31.911573 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 1, length 64 08:22:32.807997 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 2, length 64 08:22:32.922373 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 2, length 64 08:22:32.923572 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 2, length 64 На сервере # tcpdump -i gif0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif0, link-type NULL (BSD loopback), capture size 262144 bytes 07:22:30.566485 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 0, length 64 07:22:30.566501 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 0, length 64 07:22:30.567795 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 0, length 64 07:22:30.567807 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 0, length 64 07:22:31.590655 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 1, length 64 07:22:31.590669 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 1, length 64 07:22:31.591988 IP 192.168.12.5 > 192.168.12.1: ICMP echo request, id 39435, seq 1, length 64 07:22:31.591996 IP 192.168.12.1 > 192.168.12.5: ICMP echo reply, id 39435, seq 1, length 64 07:22:32.602660 IP 192.168.12
[freebsd] Туннель с клиентом за натом
Привет. Вопрос про туннель с клиентом за натом. Сервер: X.X.X.X 192.168.12.1 (FreeBSD 12.3) NAT:Y.Y.Y.Y 192.168.0.1 Слиент: 192.168.0.5 192.168.12.5 (FreeBSD 12.3) На сервере (X.X.X.X): ifconfig gif0 create ifconfig gif0 inet tunnel X.X.X.X Y.Y.Y.Y ifconfig gif0 inet 192.168.12.1/24 192.168.12.5 На клиенте (192.168.0.5): ifconfig gif0 create ifconfig gif0 inet tunnel 192.168.0.5 X.X.X.X ifconfig gif0 inet 192.168.12.5/24 192.168.12.1 TCP - работает, а вот UDP и ICMP дают дубликати. При этом tcpdump показывает, что UDP уже на gif0 интерфейсе сервера, а ICMP echo дает дубликати ответа, видные tcpdump на клиенте, если пинговать с клиента и наоборот. Аналогичная картина наблюдается для ipsec. Как это объяснить и исправить? Спасибо. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] zfs import
On Tue, 14 Jun 2022 01:44:22 +0700 Eugene Grosbein wrote: > 13.06.2022 22:57, Nick Kostirya via freebsd пишет: > > On Mon, 13 Jun 2022 18:39:41 +0300 > > Владимир Друзенко via freebsd wrote: > >> Nick Kostirya via freebsd писал(а) 2022-06-13 17:52: > >>> > >>> Вопрос про zfs. FreeBSD 13.1 > >>> Есть диск с zfs (созданный bsdinstall). > >>> Затем добавили еще диск с целью перенести на нее систему, а второй > >>> оставить для разных больших файлов. > >>> Загрузился с флешки и bsdinstall создал на весь диск zfs и установил. > >>> В биосе сказал грузиться с нового диско, но FreeBSD все равно > >>> грузиться со старого диска. > > Не надо было так делать. Есть гораздо более простой и быстрый путь: > добавить второй диск в существующий пул командой zpool attach poolname > old_device new_device > > Это делает пул зеркалом. Надо дождаться окончания зеркалирования данных, > проверяя прогресс командой zpool status. Затем можно удалить старый диск из > пула > командой zpool detach. > > Предварительно почитать man zpool-attach и man zpool-detach. > Важно не спутать с командой zpool add, которая тоже добавляет диск в пул, > но делает из пула не зеркало, а аналог gconcat, когда объём пула становится > суммарным объёмом двух дисков, данные распределяются по всему объёму и такой > пул уже невозможно разобрать потом, только через спасение данных и > уничтожение пула целиком. > > >>> Что еще нужно подкрутить? > >> > >> Название рутового пула случайно не одинаковое? > > > > Ой, оба из под bsdinstall, значит одинаковые. А как выкрутиться в этой > > ситуации? > > > > Читаю про ZFS: все про зеркала рассказывают... > > А как же поступают в такой ситуации: вставил диск с другой компьютера > > что-бы данные скопировать? > > У пулов кроме имени есть уникальные ID, импортировать пул с тем же именем > можно вручную по ID. > man zpool-import. Импортировать по ID получилось, если загрузиться с install флешки. А при загрузке с диска один пулл, наверное, ложиться поверх второго. Когда их назвал разными именами, то при загрузке импортировался только пулл с диска, с которого шла загрузка. Почему, если имена совпадаю, загрузчик лезет в другой диск - не понятно. Далее возник вопрос, как добраться до данных второго диска. Некоторые каталоги оказываются пустые, например /usr/local/ # zpool import -N tank # zfs list tank743M 107G 96K /zroot tank/ROOT 740M 107G 96K none tank/ROOT/default 740M 107G 740M / tank/tmp120K 107G 120K /tmp tank/usr484K 107G 96K /usr tank/usr/home 196K 107G 196K /usr/home tank/usr/ports 96K 107G 96K /usr/ports tank/usr/src 96K 107G 96K /usr/src tank/var648K 107G 96K /var tank/var/audit 96K 107G 96K /var/audit tank/var/crash 96K 107G 96K /var/crash tank/var/log160K 107G 160K /var/log tank/var/mail 104K 107G 104K /var/mail tank/var/tmp 96K 107G 96K /var/tmp # mount -t zfs tank/ROOT/default /mnt # ll /mnt/usr/local/ total 0 # umount /mnt # mount -t zfs tank/usr /mnt # ll /mnt/ total 0 Почем так не понятно. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] zfs
On Mon, 13 Jun 2022 18:39:41 +0300 Владимир Друзенко via freebsd wrote: > Nick Kostirya via freebsd писал(а) 2022-06-13 17:52: > > > Привет. > > > > Вопрос про zfs. FreeBSD 13.1 > > Есть диск с zfs (созданный bsdinstall). > > Затем добавили еще диск с целью перенести на нее систему, а второй > > оставить для разных больших файлов. > > Загрузился с флешки и bsdinstall создал на весь диск zfs и установил. > > В биосе сказал грузиться с нового диско, но FreeBSD все равно > > грузиться со старого диска. > > > > Что еще нужно подкрутить? > > Название рутового пула случайно не одинаковое? Ой, оба из под bsdinstall, значит одинаковые. А как выкрутиться в этой ситуации? Читаю про ZFS: все про зеркала рассказывают... А как же поступают в такой ситуации: вставил диск с другой компьютера что-бы данные скопировать? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
[freebsd] zfs
Привет. Вопрос про zfs. FreeBSD 13.1 Есть диск с zfs (созданный bsdinstall). Затем добавили еще диск с целью перенести на нее систему, а второй оставить для разных больших файлов. Загрузился с флешки и bsdinstall создал на весь диск zfs и установил. В биосе сказал грузиться с нового диско, но FreeBSD все равно грузиться со старого диска. Что еще нужно подкрутить? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
[freebsd] Ryzen 5 5500U and bhyve
Привет. Прочитал, что для использования bhyve нужны POPCNT и NRIPS. В dmess вижу POPCNT, но вместо NRIPS вижу только SVM: NP,NRIP Это оно? Будет или работать bhyve на Ryzen 5 5500U? CPU: AMD Ryzen 5 5500U with Radeon Graphics (2096.11-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x860f81 Family=0x17 Model=0x68 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x75c237ff> Structured Extended Features=0x219c91a9 Structured Extended Features2=0x44 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x90cf757 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 6007091200 (5728 MB) ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] PPPoE и PPTP, GRE, IPSEC
Когда-то у меня был дома интернет через pppoe. Использовал l2tp (mpd5) и ipsec. Выставил mtu 1400. Работало нормально. On Thu, 11 Nov 2021 09:25:55 +0200 (EET) Yaroslav Shvets wrote: > Hello All. > > Провайдер предоставляет интернет через pppoe. > Данный сервер должен также выступать как множественным > pptp-клиентом, так и pptp-сервером (mpd5). > Предполагается также подключение по IPSEC. > Не исключены в будущем другие туннели. > Конфигурация давно отлажена и успешно работает > через классический сетевой интерфейс. > > Будет ли это все нормально работать через PPPoE? > Есть ли смысл связываться или стоит выбрать > классическое подключение к провайдеру? > > -- > Yaroslav Shvets > ___ > freebsd mailing list > freebsd@uafug.org.ua > http://mailman.uafug.org.ua/mailman/listinfo/freebsd ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] socket
On Wed, 21 Apr 2021 19:39:14 +0300 Nick Kostirya via freebsd wrote: > Привет. > > Вопрос по сокетам. > > Забыл открыть сокет в неблокирующем режиме. > После select записывалось столько данных, сколько влезало, и операция записи > не блокировалась. > > А вот при запуске под Линуксом обнаружил эту ошибку, так как там запись > блокируется. > > Это такая особенность FreeBSD или всех BSD? > А как под Солярисом? Ой. Сокеты наследуют неблокирующий режим от accept. Так что они работают в неблокирующем режиме. А вот под Linux не наследуется. Порылся в своих записях: оказывается давным давно уже сталкивался с этим. :-) Спасибо. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
[freebsd] socket
Привет. Вопрос по сокетам. Забыл открыть сокет в неблокирующем режиме. После select записывалось столько данных, сколько влезало, и операция записи не блокировалась. А вот при запуске под Линуксом обнаружил эту ошибку, так как там запись блокируется. Это такая особенность FreeBSD или всех BSD? А как под Солярисом? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] dts
On Wed, 14 Apr 2021 17:18:11 +0300 "George L. Yermulnik" wrote: > Hello! > > On Wed, 14 Apr 2021 at 16:24:22 (+0300), Nick Kostirya via freebsd wrote: > > > > Вот редиски. Повторюсь -- анонса для широкого круга лиц не было. > > > :-( > > Теперь, чтобы dts скопилировать, все исходника скачивать нужно. > > А раньше можно было просто: > > В git такое тоже можно сделать. С чуть большим кол-вом телодвижений, правда. > Придётся просто привыкнуть :shrug: Как? Разве git позволяет скачать часть? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] dts
On Wed, 14 Apr 2021 15:54:07 +0300 Anton Saietskii wrote: > Вот редиски. Повторюсь -- анонса для широкого круга лиц не было. :-( Теперь, чтобы dts скопилировать, все исходника скачивать нужно. А раньше можно было просто: set S=/tmp/src set URL=http://svn.freebsd.org/base/stable/12 svnlite co $URL/sys/gnu/dts $S/gnu/dts svnlite co $URL/sys/dts $S/dts fetch -o $S/make_dtbo.sh $URL/sys/tools/fdt/make_dtbo.sh ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] netgraph
On Mon, 5 Apr 2021 12:10:00 +0700 Eugene Grosbein wrote: > Если цель это получить данные именно из UART на другой машине, то конкрето > эта задача, > разумеется, давным давно решена и много раз. В /usr/ports/comms хватает > разного софта для этого: > comserv, remserial. Или, если вместо этого хочется "экспортировать" локальный > /dev/cuau0 так, > чтобы удаленный хост мог подключиться по TCP и получить поток данных, > там же serialoverip, sredird, tits, и тот же comserv, который умеет и так. Большое спасибо. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] netgraph
On Mon, 5 Apr 2021 00:04:50 +0700 Eugene Grosbein wrote: > 02.04.2021 14:43, Nick Kostirya via freebsd пишет: > > Привет. > > > > У меня наивный вопрос про netgraph. > > > > Я правильно понял, что при помощи ng_socket можно соединить два компьютера > > в одну сеть через, например, UART проводами или при помощи радио? > > Для этого лишь достаточно написать демона, который будет просто > > перекладывать байты из socket в UART сразу или передавать радиочипу? > > Не этой нодой. > > ng_socket это "переходник" между BSD-сокетами стека TCP/IP и внутренностями > NETGRAPH и не более того. > То есть, если у нас есть некая абстрактная нода или сеть нод внутри NETGRAPH > и их надо кормить > данными, приходящими из TCP/IP (или в обратную сторону, или в обе), для этого > можно использовать ng_socket. А в случае UART можно использовать ng_tty(4)? Общение с железкой осуществляется через gpio и uart. Сначала она настраивается через uart, потом при помощи gpio переключается в режим, когда через uart (/dev/cuaU* или /dev/ttyU*) идут только данные, которые прямо без обработки можно заворачивать в TCP/IP. Получится, после настрой железки, при помощи ng_tty создать netgraph ноду и ее при помощи ng_ksocket соединить ее к стеку TCP/IP? > > Для передачи данных (соединения в сеть) через UART штатный драйвер uart(4) > уже создаёт файлы устройств > в /dev, плюс драйвер этот реализует абстракцию termios(4) line discipline и > уже написаны демоны, > которые перекладывают байты в девайс и обратно: ppp, mpd5 и раньше ещё был > slattach, но протокол SLIP > для работы поверх UART выпилили давно из FreeBSD (во время FreeBSD 4 он ещё > работал). > > Если вам интересно использование именно NETGRAPH через некое железо, то > плясать надо от драйвера > этого железа, в какой форме драйвер принимает данные для отправки или выдаёт > принятые от железа данные? Драйверов пока нет. Другие железки работают через spi протокол. Но что-то они не хочет дружить с микрокомпьютером под управление FreeBSD, так что скорее всего сделаю через промежуточный микропроцессор, который spi будет преобразовывать в uart. Тем более, что упомянутая выше так сама делает. > > Если вы сами пишете такой драйвер - вполне возможно реализовать новую ноду > NETGRAPH, > которая с одной стороны будет частью драйвера, общающейся с железом > "напрямую", > а с другой стороны посредством нетграфовых хуков может быть соединена с > ng_iface или ng_eiface > или ng_device. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
[freebsd] netgraph
Привет. У меня наивный вопрос про netgraph. Я правильно понял, что при помощи ng_socket можно соединить два компьютера в одну сеть через, например, UART проводами или при помощи радио? Для этого лишь достаточно написать демона, который будет просто перекладывать байты из socket в UART сразу или передавать радиочипу? ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
