Linux Conntrack automatic helper assignment Docs

nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. вот что выдало мне ядро 4.14 на нате, вобщем то предупреждали уже давно, на 4.4 как минимум точно. Ну, я подгрузил модули хелперов принудительно, и думал что этого достаточно, но не тут то было.

Позвонили из саппорта, говорят pptp не хочет у когото соединяца, правда ошиблись и назвали не тот роутер на котором у меня тестируется 4.14, я забил сказав что со мной сие никак не связано😊 Тем не менее мне прислали дамп:

root@nwmsk-46-gw:~# tcpdump -ni eth1.189 host 37.29.74.109
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.189, link-type EN10MB (Ethernet), capture size 262144 bytes
13:15:18.411162 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [S], seq 3051623381, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
13:15:18.454187 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [S.], seq 1229404315, ack 3051623382, win 5600, options [mss
1400,nop,nop,sackOK,nop,wscale 5], length 0
13:15:18.455865 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [.], ack 1, win 257, length 0
13:15:18.455873 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 1:157, ack 1, win 257, length 156: pptp CTRL_MSGTYPE=SCCRQ
PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(0) HOSTNAME() VENDOR(Microsoft)
13:15:18.498863 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 157, win 209, length 0
13:15:18.511886 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [P.], seq 1:157, ack 157, win 209, length 156: pptp CTRL_MSGTYPE=SCCRP
PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP() BEARER_CAP() MAX_CHAN(1) FIRM_REV(1) HOSTNAME(local) VENDOR(linux)
13:15:18.512947 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 157:325, ack 157, win 256, length 168: pptp CTRL_MSGTYPE=OCRQ
CALL_ID(49223) CALL_SER_NUM(23) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0)
PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
13:15:18.567638 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [P.], seq 157:189, ack 325, win 242, length 32: pptp CTRL_MSGTYPE=OCRP
CALL_ID(63232) PEER_CALL_ID(49223) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(100000000) RECV_WIN(64) PROC_DELAY(0)
PHY_CHAN_ID(0)
13:15:18.575569 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [P.], seq 325:349, ack 189, win 256, length 24: pptp CTRL_MSGTYPE=SLI
PEER_CALL_ID(63232) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
13:15:18.577786 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 0, length 64: LCP, Conf-Request (0x01), id 0, length 50
13:15:18.657114 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 349, win 242, length 0
13:15:20.577458 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 1, length 64: LCP, Conf-Request (0x01), id 1, length 50
13:15:23.577748 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 2, length 64: LCP, Conf-Request (0x01), id 2, length 50
13:15:27.578069 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 3, length 64: LCP, Conf-Request (0x01), id 3, length 50
13:15:31.578450 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 4, length 64: LCP, Conf-Request (0x01), id 4, length 50
13:15:35.578286 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 5, length 64: LCP, Conf-Request (0x01), id 5, length 50
13:15:39.579232 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 6, length 64: LCP, Conf-Request (0x01), id 6, length 50
13:15:43.580117 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 7, length 64: LCP, Conf-Request (0x01), id 7, length 50
13:15:47.580822 IP 10.32.60.245 > 37.29.74.109: GREv1, call 63232, seq 8, length 64: LCP, Conf-Request (0x01), id 8, length 50
13:15:48.632986 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [F.], seq 189, ack 349, win 242, length 0
13:15:48.633575 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [.], ack 190, win 256, length 0
13:15:48.641130 IP 10.32.60.245.49223 > 37.29.74.109.1723: Flags [F.], seq 349, ack 190, win 256, length 0
13:15:48.684009 IP 37.29.74.109.1723 > 10.32.60.245.49223: Flags [.], ack 350, win 242, length 0

GRE в одну сторону - типичный случай для pptp без хелпера потому что оно не натица без него а идет с серого адреса а дальше его тупо дропнет и до сервера оно вообще не дойдет, потому и LCP без ответа - закралось подозрение что сапорт обьебался с роутером.

Уточнил - точно ли оно идет не через тестовый роутер, оказалось таки через него - вопиющий пример херовой диагностики😊

Ну и тут сразу стало понятно что хелперы не работают, и начались разборки:

default automatic helper assignment has been turned off или как вернуть все взад

предлагают использовать таргет CT, типа вот такого:

iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \\
       --helper ftp -o $OUT_IFACE -p tcp \\
       --dport 1024: -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED -m helper \\
       --helper ftp -i $OUT_IFACE -p tcp \\
       --dport 1024: -j ACCEPT

для ftp к примеру. Это означает переписать фаервол, что блять нихуя не быстро.

Есть путь быстрее - дать модулю nf_conntrack параметр nf_conntrack_helper=1 и перегрузить, после этого все начнет работать как раньше, еще есть sysctl - /proc/sys/net/netfilter/nf_conntrack_helper

Я же вообще машину не перегружал, она же в работе, решил попробовать на лету - дал

и выгрузил и загрузил обратно модули хэлперов, после чего все заработало как надо.