Висит соединение на пакетах с fwmark

0

1

Всем доброго дня. Пытаюсь сделать выборочный роутинг по инструкции https://keenetic-gi.ga/2018/01/16/selective-routing.html , но почему-то соединение просто висит. Не уверен что это поможет, но вот tcpdump с попыткой открыть https://linkedin.com


~ # tcpdump -i ovpn_br0 -vv
tcpdump: listening on ovpn_br0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:48:57.536119 IP (tos 0x0, ttl 127, id 12958, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.255.6.52157 > 13.107.42.14.https: Flags [S], cksum 0xdfa7 (correct), seq 925931686, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
08:48:57.691822 IP (tos 0x0, ttl 116, id 44032, offset 0, flags [DF], proto TCP (6), length 52)
    13.107.42.14.https > 192.168.255.6.52157: Flags [S.], cksum 0x362e (correct), seq 3198608920, ack 925931687, win 65535, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
08:48:57.695452 IP (tos 0x0, ttl 127, id 12959, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.255.6.52157 > 13.107.42.14.https: Flags [.], cksum 0x7499 (correct), seq 1, ack 1, win 514, length 0
08:48:57.698313 IP (tos 0x0, ttl 127, id 12960, offset 0, flags [DF], proto TCP (6), length 432)
    192.168.255.6.52157 > 13.107.42.14.https: Flags [P.], cksum 0xace8 (correct), seq 1:393, ack 1, win 514, length 392
08:48:57.853623 IP (tos 0x0, ttl 117, id 44033, offset 0, flags [DF], proto TCP (6), length 40)
    13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0x6d10 (correct), seq 1, ack 393, win 2051, length 0
08:48:57.854726 IP (tos 0x0, ttl 117, id 44034, offset 0, flags [DF], proto TCP (6), length 1398)
    13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0xcfcc (correct), seq 1:1359, ack 393, win 2051, length 1358
08:48:57.855144 IP (tos 0x0, ttl 117, id 44035, offset 0, flags [DF], proto TCP (6), length 1398)
    13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0xe2c1 (correct), seq 1359:2717, ack 393, win 2051, length 1358
08:48:57.855485 IP (tos 0x0, ttl 117, id 44036, offset 0, flags [DF], proto TCP (6), length 1038)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xcdf8 (correct), seq 2717:3715, ack 393, win 2051, length 998
08:48:57.858017 IP (tos 0x0, ttl 127, id 12961, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.255.6.52157 > 13.107.42.14.https: Flags [.], cksum 0x6880 (correct), seq 393, ack 2717, win 503, length 0
08:48:57.858097 IP (tos 0x0, ttl 127, id 12962, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.255.6.52157 > 13.107.42.14.https: Flags [.], cksum 0x6875 (correct), seq 393, ack 2717, win 514, length 0
08:48:57.875542 IP (tos 0x0, ttl 127, id 12963, offset 0, flags [DF], proto TCP (6), length 198)
    192.168.255.6.52157 > 13.107.42.14.https: Flags [P.], cksum 0xc2c3 (correct), seq 393:551, ack 3715, win 510, length 158
08:48:58.030963 IP (tos 0x0, ttl 117, id 44037, offset 0, flags [DF], proto TCP (6), length 40)
    13.107.42.14.https > 192.168.255.6.52157: Flags [.], cksum 0x5df1 (correct), seq 3715, ack 551, win 2050, length 0
08:48:58.032235 IP (tos 0x0, ttl 117, id 44038, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:48:58.380668 IP (tos 0x0, ttl 116, id 44039, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:48:58.740483 IP (tos 0x0, ttl 117, id 44040, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:48:59.439163 IP (tos 0x0, ttl 117, id 44041, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:49:00.835664 IP (tos 0x0, ttl 117, id 44042, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:49:02.765293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 13.107.42.14 tell 192.168.255.6, length 28
08:49:02.765332 ARP, Ethernet (len 6), IPv4 (len 4), Reply 13.107.42.14 is-at de:72:0d:a2:a8:0e (oui Unknown), length 28
08:49:03.628367 IP (tos 0x0, ttl 117, id 44043, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51
08:49:09.212746 IP (tos 0x0, ttl 117, id 44044, offset 0, flags [DF], proto TCP (6), length 91)
    13.107.42.14.https > 192.168.255.6.52157: Flags [P.], cksum 0xa6bc (correct), seq 3715:3766, ack 551, win 2050, length 51

Если задать прямой маршрут ip route add 13.107.42.14 dev ovpn_br0, то всё работает, но через ipset ни в какую не хочет. Подскажите, куда можно подсмотреть чтобы понять в чём проблема?

PS dnsmasq пока не поднимал, пытаюсь просто завести со статичными ip в ipset

Ссылка

←	openconnect: как изменить иконку в трее?

GRE-туннель без отключения файрволла не пингуется

→

Инструкция хреновая.

Этот вопрос обсуждался здесь очень много раз.

PS дамп даже не смотрел.

vel ★★★★★
(17.12.20 09:51:47 MSK)

Ответ на: комментарий от vel 17.12.20 09:51:47 MSK

Я видел похожие темы тут, но явного ответа на свой вопрос к сожалению найти не смог. Максимум что находил это выставление rp_filter в 0, но у он у меня и так стоит 0. Ткните пожалуйста носом в нужный топик, если не сложно.

helcoder
(17.12.20 10:00:30 MSK) автор топика

Ответ на: комментарий от helcoder 17.12.20 10:00:30 MSK

У тебя оба канала работают одновременно?

Вся проблема в том, что вы вставляете специфические правила ДО просмотра таблицы main, в которой находятся все прямые маршруты. А должно быть наоборот.

как только ты стал счастливым владельцем более одного канала наружу, так сразу нужно забыть про dgw в main.

Правила должны быть в следующем порядке

0:   from all lookup local
128: from all lookup main
1024: специфические правила
......
2048: from <ip1> lookup 11
2052: from <ip2> lookup 12
.....
4096: lookup 11

dgw для каждого канала нужно положить в отдельную таблицу (11,12,...)

В правиле 4096 нужно указать таблицу с dgw дефолтного канала.

Если у тебя современная версия ipset, то маркировать пакеты можно через "-j SET --map-set route src --map-mark". Только набор нужно не забыть создать с флагом skbinfo.

vel ★★★★★
(17.12.20 10:30:59 MSK)

Ответ на: комментарий от vel 17.12.20 10:30:59 MSK

Извиняюсь, но я не совсем понял вопрос про оба канала. Это роутер KN-1010, у него один интерфейс для выхода в интернет ppp0 + поднят openvpn client с интерфейсом ovpn_br0.

Правила сейчас выглядят вот так:

~ # ip rule show
0:      from all lookup local
32765:  from all fwmark 0x1 lookup 1
32766:  from all lookup main
32767:  from all lookup default

Мне получается нужно переместить fwmark после main и создать ещё одно дополнительное правило в самом конце с ещё одной таблицей у которой дефолтный канал ppp0? Ещё раз извиняюсь если сильно туплю, для меня эти вещи вновинку, но разобраться интересно.

helcoder
(17.12.20 10:56:33 MSK) автор топика

Ответ на: комментарий от helcoder 17.12.20 10:56:33 MSK

Попробовал я эту «хреновую» инструкцию на двух виртуальных машинах и как ни странно там всё работает как часы без дополнительных танцев с бубном, поэтому мне не совсем понятно откуда тут могут быть какие-то проблемы со специфичными правилами до просмотра таблицы main. По итогам удалось узнать что это проблема самого keenetic’а, не все пакеты маркируются из-за fastnat, если его отключить, то всё работает - https://forum.keenetic.net/topic/5968-fwmark-%D0%BC%D0%B0%D1%80%D0%BA%D0%B8%D1%80%D1%83%D0%B5%D1%82-%D0%BD%D0%B5-%D0%B2%D1%81%D0%B5-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D1%8B

helcoder
(24.12.20 07:53:32 MSK) автор топика