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 без ответа - закралось подозрение что сапорт обьебался с роутером.
Уточнил - точно ли оно идет не через тестовый роутер, оказалось таки через него - вопиющий пример херовой диагностики😊
Ну и тут сразу стало понятно что хелперы не работают, и начались разборки:
предлагают использовать таргет 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
Я же вообще машину не перегружал, она же в работе, решил попробовать на лету - дал
echo 1 >/sys/module/nf_conntrack/parameters/nf_conntrack_helper
echo 1 >/proc/sys/net/netfilter/nf_conntrack_helper
и выгрузил и загрузил обратно модули хэлперов, после чего все заработало как надо.