12-STABLE+racoon

Eugene Grosbein написал(а) к Sergey Anohin в Jan 19 23:02:31 по местному времени:

28 янв. 2019, понедельник, в 17:20 NOVT, Sergey Anohin написал(а):

SA> Что-то тут не чисто:

Во-первых, нельзя использовать ядро, собранное после креша
и надо очень тщательно проверять, что для отладки ты используешь
именно то ядро, что скрешилось - особенно если у тебя в системе
есть софтовое зеркало, которое могло рассинхронизироваться
и ты инсталлируешь одно ядро в /boot, а loader может при этом
грузить более старое ядро с другого диска, используя функции BIOS.

Либо ядро пишет крешдамп на ту часть зеркала, из которой потом
savecore извлекает крешдамп после ребута (не настроены приоритеты gmirror).

Все подобные возможности нужно перепроверить.

Во-вторых, даже без использования kgdb backtrace во время паники
на экран выдаётся KDB_TRACE и он же попадает в msgbuf,
который kgdb показывает сразу при старте ещё до того
как запрашивает у тебя первую команду.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.3 (FreeBSD)

Sergey Anohin написал(а) к Eugene Grosbein в Jan 19 20:02:17 по местному времени:

Нello, Eugene!

EG> Во-первых, нельзя использовать ядро, собранное после креша
EG> и надо очень тщательно проверять, что для отладки ты используешь
EG> именно то ядро, что скрешилось - особенно если у тебя в системе
EG> есть софтовое зеркало, которое могло рассинхронизироваться

ок, надо заинсталлить свежесобранное, изменений в сорцах не было
выкачивал через svn

EG> и ты инсталлируешь одно ядро в /boot, а loader может при этом
EG> грузить более старое ядро с другого диска, используя функции BIOS.

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

EG> Либо ядро пишет крешдамп на ту часть зеркала, из которой потом
EG> savecore извлекает крешдамп после ребута (не настроены приоритеты gmirror).

Нет, зеркал нет, обычный хард.

EG> Все подобные возможности нужно перепроверить.

EG> Во-вторых, даже без использования kgdb backtrace во время паники
EG> на экран выдаётся KDB_TRACE и он же попадает в msgbuf,
EG> который kgdb показывает сразу при старте ещё до того
EG> как запрашивает у тебя первую команду.

Ну да, там на экран писало кучу всего, но не заснять никак было.
Пока известно точно что вызывал краш старт racoon, я его пока выпилил из автозагрузки.
Буду пробовать инсталлить еще раз ядро, потом стартовать racoon onestart, потом после ребута смотреть корки, так?

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Eugene Grosbein написал(а) к Sergey Anohin в Jan 19 08:20:26 по местному времени:

28 янв. 2019, понедельник, в 20:02 NOVT, Sergey Anohin написал(а):

SA> Ну да, там на экран писало кучу всего, но не заснять никак было.
SA> Пока известно точно что вызывал краш старт racoon, я его пока выпилил из
SA> автозагрузки.
SA> Буду пробовать инсталлить еще раз ядро, потом стартовать racoon onestart, потом
SA> после ребута смотреть корки, так?

Так.

Eugene
--
Сердце - малочувствительный, мускулистый, грубый и жесткий орган.
--- slrn/1.0.3 (FreeBSD)

Sergey Anohin написал(а) к Eugene Grosbein в Feb 19 02:31:23 по местному времени:

Нello, Eugene!

Таки что-то оказалось сломано, но не racoon. Туннель подымается, пакеты доходят от клиента до сервера,
но обратно на клиенте походу их нет. На Андроиде тоже не фурычит. Вроде ничего не менялось годами в конфигах.
Туннельная сетка 10.1.1.0/24 клиент 10.1.1.100

# netstat -nr
Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 213.59.207.73 UGS ng0
10.0.0.0/24 link#2 U sk0
10.0.0.1 link#2 UНS lo0
10.1.1.0/24 10.1.1.1 UGS lo0
10.1.1.1 link#11 UНS lo0
10.1.1.100 link#11 UН ng1
10.1.200.0/24 10.1.200.2 UGS tun1
10.1.200.1 link#10 UНS lo0
10.1.200.2 link#10 UН tun1
10.15.10.0/24 10.1.200.2 UGS tun1
85.113.221.175 link#9 UНS lo0
127.0.0.1 link#3 UН lo0
192.168.1.0/24 link#1 U rl0
192.168.1.1 link#1 UНS lo0
192.168.42.0/24 10.1.200.3 UGS tun1
192.168.45.0/24 10.1.200.9 UGS tun1
192.168.46.0/24 10.1.200.10 UGS tun1
213.59.207.73 link#9 UН ng0
224.0.0.0/4 10.0.0.1 UGS sk0

Internet6:
Destination Gateway Flags Netif Expire
::/96 ::1 UGRS lo0
::1 link#3 UН lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
fe80::/10 ::1 UGRS lo0
fe80::%lo0/64 link#3 U lo0
fe80::1%lo0 link#3 UНS lo0
fe80::%tun1/64 link#10 U tun1
fe80::21b:fcff:fe09:fb60%tun1 link#10 UНS lo0
ff02::/16 ::1 UGRS lo0

пытаюсь пинговать сервер с клиента

root@server:/usr/local/etc/mpd5# tcpdump -n -i ng1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng1, link-type NULL (BSD loopback), capture size 262144 bytes
02:17:36.313415 IP 10.1.1.100 > 10.1.1.1: ICMP echo request, id 1, seq 82, length 40
02:17:36.313463 IP 10.1.1.1 > 10.1.1.100: ICMP echo reply, id 1, seq 82, length 40
02:17:40.835844 IP 10.1.1.100 > 10.1.1.1: ICMP echo request, id 1, seq 83, length 40
02:17:40.835877 IP 10.1.1.1 > 10.1.1.100: ICMP echo reply, id 1, seq 83, length 40

уходит в туннель и там гибнет :)

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Eugene Grosbein написал(а) к Sergey Anohin в Feb 19 11:08:06 по местному времени:

14 февр. 2019, четверг, в 02:31 NOVT, Sergey Anohin написал(а):

SA> уходит в туннель и там гибнет :)

Подгрузи if_enc.ko, если в ядре нету device enc

Сделай:

sysctl net.enc.in.ipsecfiltermask=0
sysctl net.enc.out.ipsecfiltermask=0

Затем ifconfig enc0 up и смотри tcpdump -npi enc0,
проходят ли исходящие пакеты через IPSEC на самом деле.
Если увидишь - смотри одновременно tpcdump-ом на физическом интерфейсе
шифрованные пакеты в сторону клиента - уходят ли?
Если уходят, то кто-то по трассе их фильтрует (такое бывает с ESP-протоколом).

Eugene
--
И кого не любишь, в лицо не знать, и смотреть на звезды и жить спокойно.
--- slrn/1.0.3 (FreeBSD)

Sergey Anohin написал(а) к Eugene Grosbein в Feb 19 11:39:15 по местному времени:

Нello, Eugene!
SA>> уходит в туннель и там гибнет :)
EG> Подгрузи if_enc.ko, если в ядре нету device enc

(pts/1)[root@server:~]# cat /usr/src/sys/amd64/conf/SERVER | grep enc
options EKCD # Support for encrypted kernel dumps
# CPU frequency control
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le')
# Be aware of the administrative consequences of enabling this!
device enc
(pts/1)[root@server:~]# ls /boot/kernel | grep enc
if_enc.ko
(pts/1)[root@server:~]# kldload if_enc.ko
kldload: an error occurred while loading module if_enc.ko. Please check dmesg(8) for more details.
(pts/1)[root@server:~]#

dmesg сообщил
interface if_enc.1 already present in the KLD 'kernel'!
linkerload_file: /boot/kernel/ifenc.ko - unsupported file type


EG> Сделай:
EG> sysctl net.enc.in.ipsecfiltermask=0
EG> sysctl net.enc.out.ipsecfiltermask=0
EG> Затем ifconfig enc0 up и смотри tcpdump -npi enc0,
EG> проходят ли исходящие пакеты через IPSEC на самом деле.
EG> Если увидишь - смотри одновременно tpcdump-ом на физическом интерфейсе
EG> шифрованные пакеты в сторону клиента - уходят ли?
EG> Если уходят, то кто-то по трассе их фильтрует (такое бывает с ESP-протоколом).

Да бывает такое, сейчас испробую отпишусь

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Sergey Anohin написал(а) к Eugene Grosbein в Feb 19 21:34:13 по местному времени:

Нello, Eugene!

EG> Подгрузи if_enc.ko, если в ядре нету device enc

это есть

EG> Сделай:
EG> sysctl net.enc.in.ipsecfiltermask=0
EG> sysctl net.enc.out.ipsecfiltermask=0

готово

EG> Затем ifconfig enc0 up и смотри tcpdump -npi enc0,
EG> проходят ли исходящие пакеты через IPSEC на самом деле.

# tcpdump -npi enc0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
21:13:26.766540 (authentic,confidential): SPI 0x683b1cc7: IP 85.113.221.175.1701 > 2.94.173.77.1701: l2tp:[S](1/1)Ns=264,Nr=0 {compressed PPP data}
21:13:26.766546 (authentic,confidential): SPI 0x683b1cc7: IP 85.113.221.175.1701 > 2.94.173.77.1701: l2tp:[S](1/1)Ns=264,Nr=0 {compressed PPP data}
21:13:26.766802 (authentic,confidential): SPI 0x683b1cc7: IP 85.113.221.175.1701 > 2.94.173.77.1701: l2tp:[S](1/1)Ns=265,Nr=0 {compressed PPP data}
21:13:26.766804 (authentic,confidential): SPI 0x683b1cc7: IP 85.113.221.175.1701 > 2.94.173.77.1701: l2tp:[S](1/1)Ns=265,Nr=0 {compressed PPP data}
21:13:26.933688 (authentic,confidential): SPI 0x0d109165: IP 2.94.173.77.1701 > 85.113.221.175.1701: l2tp:[L](57845/33665) {compressed PPP data}
21:13:27.033313 (authentic,confidential): SPI 0x0d109165: IP 2.94.173.77.1701 > 85.113.221.175.1701: l2tp:[L](57845/33665) {compressed PPP data}
21:13:27.233440 (authentic,confidential): SPI 0x0d109165: IP 2.94.173.77.1701 > 85.113.221.175.1701: l2tp:[L](57845/33665) {compressed PPP data}


EG> Если увидишь - смотри одновременно tpcdump-ом на физическом интерфейсе
EG> шифрованные пакеты в сторону клиента - уходят ли?
EG> Если уходят, то кто-то по трассе их фильтрует (такое бывает с ESP-протоколом).

ng1 это l2tp который подымается для клиентского подключения

# tcpdump -npi ng1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng1, link-type NULL (BSD loopback), capture size 262144 bytes
21:14:54.043882 IP 173.194.222.102.443 > 10.1.1.100.60980: Flags [S.], seq 2867786710, ack 1148236217, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.055114 IP 173.194.222.102.443 > 10.1.1.100.60981: Flags [S.], seq 737597283, ack 1504792336, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.395354 IP 10.1.1.100.60974 > 64.233.162.194.443: Flags [S], seq 1674004602, win 8192, options [mss 1356,nop,nop,sackOK], length 0
21:14:54.423257 IP 10.1.1.100.60975 > 64.233.165.189.443: Flags [S], seq 1339375093, win 8192, options [mss 1356,nop,nop,sackOK], length 0
21:14:54.423840 IP 10.1.1.100.60982 > 173.194.222.101.443: Flags [S], seq 3989086476, win 8192, options [mss 1356,nop,wscale 2,nop,nop,sackOK], length 0
21:14:54.425403 IP 64.233.162.194.443 > 10.1.1.100.60974: Flags [S.], seq 3449125806, ack 1674004603, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.453676 IP 64.233.165.189.443 > 10.1.1.100.60975: Flags [S.], seq 618917054, ack 1339375094, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.499800 IP 173.194.222.101.443 > 10.1.1.100.60982: Flags [S.], seq 3873552144, ack 3989086477, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.639332 IP 50.18.218.31.443 > 10.1.1.100.60977: Flags [S.], seq 3504818721, ack 975279992, win 26883, options [mss 1422,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.673619 IP 10.1.1.100.60983 > 173.194.222.101.443: Flags [S], seq 2003214627, win 8192, options [mss 1356,nop,wscale 2,nop,nop,sackOK], length 0
21:14:54.703990 IP 173.194.222.101.443 > 10.1.1.100.60983: Flags [S.], seq 4119810066, ack 2003214628, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.713131 IP 10.1.1.100.60980 > 173.194.222.102.443: Flags [S], seq 1148236216, win 8192, options [mss 1356,nop,wscale 2,nop,nop,sackOK], length 0
21:14:54.724456 IP 173.194.44.82.443 > 10.1.1.100.60939: Flags [S.], seq 4161488721, ack 1636181588, win 65535, options [mss 1422,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.743729 IP 173.194.222.102.443 > 10.1.1.100.60980: Flags [S.], seq 2867786710, ack 1148236217, win 60720, options [mss 1380,nop,nop,sackOK,nop,wscale 8], length 0
21:14:54.761606 IP 173.194.44.81.443 > 10.1.1.100.60940: Flags [S.], seq 2378236819, ack 87566213, win 65535, options [mss 1422,nop,nop,sackOK,nop,wscale 8], length 0

Это тот который в инет смотрит

# tcpdump -npi ng0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes
21:16:06.778280 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 2395580255:2395580463, ack 703865981, win 1035, length 208
21:16:06.778601 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 208:400, ack 1, win 1035, length 192
21:16:06.778647 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 400:576, ack 1, win 1035, length 176
21:16:06.778690 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 576:752, ack 1, win 1035, length 176
21:16:06.778743 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 752:928, ack 1, win 1035, length 176
21:16:06.778807 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 928:1104, ack 1, win 1035, length 176
21:16:06.778866 IP 85.113.221.175.22 > 2.94.173.77.60776: Flags [P.], seq 1104:1280, ack 1, win 1035, length 176

Есть ли способ на винде чем смотреть пакеты? Wireshark не умеет VPN интерфейсы смотреть
Он видит пакеты ESP ходят...

http://pics.rsh.ru/img/Screenshot127l0equei.jpg

Яндекс пингую с клиента:

# tcpdump -npi ng1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng1, link-type NULL (BSD loopback), capture size 262144 bytes
21:19:59.089873 IP 10.1.1.100 > 87.250.250.242: ICMP echo request, id 1, seq 420, length 40
21:19:59.108562 IP 87.250.250.242 > 10.1.1.100: ICMP echo reply, id 1, seq 420, length 40

# tcpdump -npi ng0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng0, link-type NULL (BSD loopback), capture size 262144 bytes
21:20:52.865052 IP 85.113.221.175 > 87.250.250.242: ICMP echo request, id 61358, seq 421, length 40
21:20:52.883743 IP 87.250.250.242 > 85.113.221.175: ICMP echo reply, id 61358, seq 421, length 40

Пинг с сервера на клиент:

# tcpdump -npi ng1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ng1, link-type NULL (BSD loopback), capture size 262144 bytes
21:22:03.351474 IP 10.1.1.1 > 10.1.1.100: ICMP echo request, id 64313, seq 42, length 64
21:22:04.353408 IP 10.1.1.1 > 10.1.1.100: ICMP echo request, id 64313, seq 43, length 64
21:22:05.356678 IP 10.1.1.1 > 10.1.1.100: ICMP echo request, id 64313, seq 44, length 64

Выглядит так как будто на стороне сервера все ок, может и так, но пробовал с разных ноутов,
в одной сети правда, и с мобильника через 4G. И там и там билайн, может стали резать? :)
Я за ними давно заметил что pptp режется



С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Eugene Grosbein написал(а) к Sergey Anohin в Feb 19 03:07:28 по местному времени:

14 февр. 2019, четверг, в 21:34 NOVT, Sergey Anohin написал(а):

SA> # tcpdump -npi enc0
SA> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
SA> listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144
SA> bytes
SA> 21:13:26.766540 (authentic,confidential): SPI 0x683b1cc7: IP
SA> 85.113.221.175.1701> 2.94.173.77.1701: l2tp:[S](1/1)Ns=264,Nr=0 {compressed

Для меня эти дампы бесполезны, потому что я не знаю,
с какой стороны какие реальные IP у тебя, так что смотри сам.

Но уже подозрительно, что через внешний интерфейс с реальными IP
на сервере у тебя трафик идёт только в одну сторону
и если это только входящие пакеты, то виноват сервер,
раз оно только что зашифрованные пакеты сам же и не отправляет -
может быть, твой файрвол на сервере их гробит.

Второй подозрительный момент - в виндовом скриншоте Wireshark,
почему там серый адрес 192.168.42.134? Если клиентский трафик
проходит через NAT, то ESP-пакетов быть не должно вообще,
а на этапе согласования IPSEC должна включаться UDP-инкапсуляция
и вместо ESP-пакетов туннельный трафик должен ходить в UDP-пакетах,
а если при наличии NAT он не детектируется, то есть не срабатывает
NAT-T, то в этом вся и проблема.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.3 (FreeBSD)

Sergey Anohin написал(а) к Eugene Grosbein в Feb 19 00:20:51 по местному времени:

Нello, Eugene!

SA>> # tcpdump -npi enc0
SA>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
SA>> listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144
SA>> bytes
SA>> 21:13:26.766540 (authentic,confidential): SPI 0x683b1cc7: IP
SA>> 85.113.221.175.1701> 2.94.173.77.1701: l2tp:[S](1/1)Ns=264,Nr=0 {compressed
EG> Для меня эти дампы бесполезны, потому что я не знаю,
EG> с какой стороны какие реальные IP у тебя, так что смотри сам.

85.113.221.175 внешний ip сервера
2.94.173.77 внешний ip клиента
192.168.42.134 внутренний ip клиента за натом
10.1.1.0/24 подсеть для l2tp где .1 это сервер.

EG> Но уже подозрительно, что через внешний интерфейс с реальными IP
EG> на сервере у тебя трафик идёт только в одну сторону
EG> и если это только входящие пакеты, то виноват сервер,
EG> раз оно только что зашифрованные пакеты сам же и не отправляет -
EG> может быть, твой файрвол на сервере их гробит.

на сервере все байпас на клиентах тоже

EG> Второй подозрительный момент - в виндовом скриншоте Wireshark,
EG> почему там серый адрес 192.168.42.134? Если клиентский трафик

wireshark не умеет VPN интерфейсы смотреть, я посмотрел что на сетевом интерфейсе
ноутбука происходит так ради интереса

EG> проходит через NAT, то ESP-пакетов быть не должно вообще,
EG> а на этапе согласования IPSEC должна включаться UDP-инкапсуляция
EG> и вместо ESP-пакетов туннельный трафик должен ходить в UDP-пакетах,
EG> а если при наличии NAT он не детектируется, то есть не срабатывает
EG> NAT-T, то в этом вся и проблема.

вопрос где, в винде-то бог с ней, могли сломать, но ведроид работал, хотя и винда работала,

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Sergey Anohin написал(а) к Eugene Grosbein в Feb 19 00:32:21 по местному времени:

Нello, Eugene!

EG> Но уже подозрительно, что через внешний интерфейс с реальными IP
EG> на сервере у тебя трафик идёт только в одну сторону

пример просто неудачный попался, там ссш

EG> Второй подозрительный момент - в виндовом скриншоте Wireshark,
EG> почему там серый адрес 192.168.42.134? Если клиентский трафик
EG> проходит через NAT, то ESP-пакетов быть не должно вообще,
EG> а на этапе согласования IPSEC должна включаться UDP-инкапсуляция
EG> и вместо ESP-пакетов туннельный трафик должен ходить в UDP-пакетах,
EG> а если при наличии NAT он не детектируется, то есть не срабатывает
EG> NAT-T, то в этом вся и проблема.

да только как отдебажить...

С наилучшими пожеланиями, Sergey Anohin.

--- wfido